Hi Gaurav, Your are correct. A para from "Modifying the Session" section clearly mentioned this.
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. Btw, how Device 2 is reacting to such SDP? -- Best Regards, Atul Thosar On 21 February 2013 20:07, Gaurav Kumar <[email protected]> wrote: > Hi, > > While interop with third party vendor sip device, we have got the > following message exchange (Only SDP message shown for sake of clarity) > > Device 1 Device 2 > > INVITE (no SDP) --------------------------> > > <---------------------------- 200 OK (SDP shown below) > v=0 > o=11701 0 0 IN IP4 172.26.29.33 > s=- > c=IN IP4 172.26.29.33 > t=0 0 > m=audio 50000 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-11,16 > m=video 50002 RTP/AVP 96 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42801f; max-mbps=108000; max-fs=3600; > max-br=5125 > > ACK (SDP shown below) -------------------------> > v=0 > o=- 4865 4865 IN IP4 172.26.29.5 > s=- > c=IN IP4 172.26.29.5 > t=0 0 > m=audio 30250 RTP/AVP 0 101 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > m=video 0 RTP/AVP 96 > > REINVITE (SDP shown below) -------------------------> > v=0 > o=- 4865 4866 IN IP4 172.26.29.5 > s=- > c=IN IP4 172.26.29.5 > t=0 0 > m=audio 30250 RTP/AVP 0 8 18 102 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendonly > a=rtpmap:102 G7221/8000 > m=audio 30250 RTP/SAVP 0 8 18 102 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendonly > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:YmJhYjY4YWM1MzRlYzFkNTZmZTg2Mzc5OGFmNDM1 > a=rtpmap:102 G7221/8000 > > According to the RFC 3264 standard, REINVITE SDP should be like below. As > the negotiated streams were two in the initial offer answer. The new stream > should be added below the existing streams. Please correct me If I am wrong. > > v=0 > o=- 4865 4866 IN IP4 172.26.29.5 > s=- > c=IN IP4 172.26.29.5 > t=0 0 > m=audio 30250 RTP/AVP 0 8 18 102 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendonly > a=rtpmap:102 G7221/8000 > m=video 0 RTP/AVP 96 > m=audio 30250 RTP/SAVP 0 8 18 102 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendonly > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:YmJhYjY4YWM1MzRlYzFkNTZmZTg2Mzc5OGFmNDM1 > a=rtpmap:102 G7221/8000 > > Thanks, > Gaurav > > > > This is confidential Ittiam property. > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
