It isn't entirely clear what the fundamental question is.
The original question seems to be concerned with whether it is allowed
to go back to audio after having previously switched to fax. But this is
mixed up with details of the SDP involved.
IIUC, the scenario involves *3* O/A exchanges:
(1) to initiate the call as audio only
(2) to switch to T.38
(3) to switch back to audio
IIUC, what has been shown is the offer and answer from (2), and the
offer from (3). If so, then the offer in (3) is clearly wrong. As others
have noted, a subsequent offer in a session must always have at least as
many m-lines as the previous offer, and this one does not.
The reason for the error has nothing to do with switching to/from T.38.
There are very few rules for changing the attributes of media streams in
subsequent offers, as long as you retain enough m-lines. If signaled
correctly it is quite reasonable to switch back to audio. (In general,
what is not explicitly forbidden is allowed.)
This doesn't mean the answerer must accept everything that is offered.
If your device is incapable of switching back to audio you can either
respond with a 488 response or refuse the problematic m-lines by setting
the port to zero in the answer. While 488 is a technically valid
approach, it is unlikely to be very successful in this case. You are
probably better off just rejecting the m-line. Of course, if that leaves
you with no active media it isn't likely to be very successful either.
Somebody is probably going to end up sending a BYE.
Thanks,
Paul
Thanks,
Paul
On 7/31/15 3:32 AM, OKUMURA Shinji wrote:
Hi,
The 3rd SDP is illegal.
RFC3264
8 Modifying the Session
If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP. In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines. The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top. This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP. Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases. Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.
Hi Puneet,
Below is the SDP for Fax Re-invite from Vendor (UAS) after audio call
established with initial offer.
*T.38 RE INVITE SDP*
v=0
o=HuaweiSoftX3000 32970986 32970988 IN IP4 1.1.1.1
s=Sip Call
c=IN IP4 1.1.1.1
t=0 0
m=image 41046 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 41128 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=fax
a=fmtp:101 0-15
*200 OK SDP for T.38 Re invite*
v=0
o=Sonus_UAC 10922 10626 IN IP4 1.1.1.1
s=-
c=IN IP4 1.1.1.1
t=0 0
m=image 6334 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:90
a=sendrecv
m=audio 0 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
*This is the Re-invite SDP after T38 Invite*
v=0
o=HuaweiSoftX3000 32970986 32970989 IN IP4 1.1.1.1
s=Sip Call
c=IN IP4 1.1.1.1
t=0 0
m=audio 41046 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=fmtp:18 annexb=no
Regards,
Nitin Kapoor
On Fri, Jul 31, 2015 at 2:48 AM, Kumar, Puneet (Puneet) <pune...@avaya.com>
wrote:
Hi Nitin,
For reINVITE for fax, is far-end converting "m=audio" line to "m=image" ?
Can you share the SDP in both reINVITE's.
Thanks,
Puneet
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of NK
Sent: Friday, July 31, 2015 11:32 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SIP Reinvite after T38 Negotitaion
Dear All,
It is legal to send re-invite after sending T.38 when negotiation is
already done.
Below is the scenario.
UA ---------> INVITE
UA <------100 Trying
UA <------- 180 w/SDP
UA <------- 200 OK
UA ----------> (Re-invite for fax with T.38) UA <------100 Trying UA
<-----------200 OK *UA <---------- RE-INVITE wSDP G.729* *UA ---------> 488
*
Now after this another re-invite is coming (in green) with G.729 Codec and
i am rejecting this with SIP 488.
Anyone observed this kind of scenario earlier?
Can you please advise and help on this.
Thank you in advance.
Regards
Nitin Kapoor
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
