Hi Paul, Thanks for the correction.
Regards, -Praveen. On Sat, Jan 11, 2014 at 12:27 AM, Paul Kyzivat <pkyzi...@alum.mit.edu>wrote: > On 1/10/14 3:40 AM, Praveena Ss wrote: > > Hi Isshed, > > > > in your example, second offer from A is correct as long as session > version > > id is changed in same session. > > I disagree. The operable issue is in section 8 of 3264: > > 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. > > I think the confusion here may be around the word "session", which has > two possible meanings in this context: > - an SDP session > - a signaling (e.g., SIP) session > > This isn't entirely clear in the text, but it is widely understood that > for SIP this is to be a SIP session. (Specifically, an INVITE dialog > usage.) > > > w.r.t m= line, the second answer sent from B > > is wrong because it does not contain the same number of m= lines as in > > second offer from A. > > This is probably true. But since the 2nd offer was in error there is no > good way to define what the proper behavior should be. > > Thanks, > Paul > > > Hope this helps to you. > > > > snippet from RFC 3264, > > > > 6 Generating the Answer > > > > . > > . > > For each "m=" line in the offer, there MUST be a corresponding "m=" > > line in the answer. The answer MUST contain exactly the same number > > of "m=" lines as the offer. This allows for streams to be matched up > > based on their order. This implies that if the offer contained zero > > "m=" lines, the answer MUST contain zero "m=" lines. > > > > . > > . > > . > > > > Thanks and regards, > > -Praveen > > > > > > > > On Fri, Jan 10, 2014 at 12:11 PM, isshed <isshed....@gmail.com> wrote: > > > >> Hi All, > >> > >> Below is offer answer model between UA A and B. > >> > >> > >> [Offer From A] > >> > >> v=0 > >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com > >> s= > >> c=IN IP4 host.atlanta.example.com > >> t=0 0 > >> m=audio 49170 RTP/AVP 0 8 97 > >> a=rtpmap:0 PCMU/8000 > >> a=rtpmap:8 PCMA/8000 > >> a=rtpmap:97 iLBC/8000 > >> m=video 51372 RTP/AVP 31 32 > >> a=rtpmap:31 H261/90000 > >> a=rtpmap:32 MPV/90000 > >> > >> > >> [Answer From B] > >> > >> v=0 > >> o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com > >> s= > >> c=IN IP4 host.biloxi.example.com > >> t=0 0 > >> m=audio 49172 RTP/AVP 0 8 > >> a=rtpmap:0 PCMU/8000 > >> a=rtpmap:8 PCMA/8000 > >> m=video 0 RTP/AVP 31 > >> a=rtpmap:31 H261/90000 > >> > >> [Second-Offer From B] > >> > >> v=0 > >> o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com > >> s= > >> c=IN IP4 host.atlanta.example.com > >> t=0 0 > >> m=audio 51372 RTP/AVP 0 > >> a=rtpmap:0 PCMU/8000 > >> > >> [Second-Answer From A] > >> > >> v=0 > >> o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com > >> s= > >> c=IN IP4 host.biloxi.example.com > >> t=0 0 > >> m=audio 49172 RTP/AVP 0 > >> a=rtpmap:0 PCMU/8000 > >> m=video 0 RTP/AVP 31 > >> a=rtpmap:31 H261/90000 > >> > >> > >> Is it a valid offer answer model, as [Second-Offer From B] removes > >> one of the m line? > >> > >> Thanks. > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@lists.cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- ------------------------------ Thanks and Regards, Praveen _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
