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
