Thanks Guarav, I was thinking, it's all a bit complicated.
But I can now see that if there are many simultaneous streams, then the approach in RFC3264 is essential in mapping the streams to eachother. Thanks for helping my understanding. Regards, Attila -----Original Message----- From: Gaurav Kheterpal [mailto:[EMAIL PROTECTED] Sent: 08 May 2007 12:19 To: Attila Sipos; 'Kannaiyan'; [email protected] Subject: RE: [Sip-implementors] Multiple 'm' lines in SDP and thereinvitebehaviour Attila, The seed to RFC 3264 (draft-rosenberg-mmusic-sdp-offer-answer-00.txt) used to directly mention in Section 4:- ' The offer in a re-INVITE MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. If an SDP is offered which is different from the previous SDP, the new SDP MUST have a matching media section for each media section in the previous SDP. In other words, if the previous SDP had N media lines, the new SDP MUST have at least N media lines. The ith media stream in the previous SDP, counting from the top, matches the ith 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 only increases. Deleted media streams from a previous SDP MUST NOT be removed from a new SDP. ===> THERE IT IS!!!!!!!!!! It is needed by the answerer to map media streams from old SDP to media streams in new SDP. FWIW, for the same reason, new media streams must always be added at the end. Further, looking at RFC 4317 examples makes me believe that you can't put whatever you want in the offer of a RE-INVITE. I hope this clarifies. Regards, Gaurav P.S - I wonder why the explanations for such things tends to get discarded from RFC texts when such docs move from drafts to RFC status! :( > -----Original Message----- > From: Attila Sipos [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 08, 2007 3:53 PM > To: Gaurav Kheterpal; Kannaiyan; [email protected] > Subject: RE: [Sip-implementors] Multiple 'm' lines in SDP and > thereinvitebehaviour > > > Hi Gaurav, > > >>The reason for this is that we need to ensure that it is always possible > to > >>match media sessions (i.e., "m=" lines) in requests and responses. > Consider > >>an INVITE with the following SDP: > >> > >>... > >>c=IN IP4 1.2.3.4 > >>m=audio 54678 RTP/AVP 0 1 3 > >>m=video 7346 RTP/AVP 28 31 (face) > >>m=video 7880 RTP/AVP 26 28 (presentation) > >> > >> > >>If the response contained something like > >> > >> > >>... > >>c=IN IP4 3.4.5.6 > >>m=audio 6540 RTP/AVP 0 1 > >>m=video 6578 RTP/AVP 28 > > > I agree, that the above would not be legal since you are > talking about an offer and its corresponding answer. > > However, the question asked by Kannaiyan was regarding > the SDP of a re-INVITE. Now, I'm pretty sure you > can put whatever you want in the offer of a re-INVITE. > > If not, why not? > > Regards, > > Attila > > > > -----Original Message----- > From: Gaurav Kheterpal [mailto:[EMAIL PROTECTED] > Sent: 08 May 2007 10:49 > To: Attila Sipos; 'Kannaiyan'; [email protected] > Subject: RE: [Sip-implementors] Multiple 'm' lines in SDP and > thereinvitebehaviour > > > Attila, > > I don't think that's true. See inline. > > Regards, > Gaurav > > >1. Is the reinvite of the missing third line is a Violation? > > >No. > >You can specify whatever you like. You can have different > >codecs, ports or even media IP addresses. > > GK>> Yes it is. The RE-INVITE is a violation of RFC 3264 - Section 8.2 > which > mentions > > "Existing media streams are removed by creating a new SDP with the port > number for that stream set to zero." > > A "m=" line which is a part of SDP for a request or a response can't be > removed until the call is terminated. Refer to RFC 4317 Example 4.3/ Page > 17 > on how to do this (setting port=0). Media types associated with streams > can > be changed but m= lines corresponding to media streams can't be removed > from > SDP. > > The reason for this is that we need to ensure that it is always possible > to > match media sessions (i.e., "m=" lines) in requests and responses. > Consider > an INVITE with the following SDP: > > ... > c=IN IP4 1.2.3.4 > m=audio 54678 RTP/AVP 0 1 3 > m=video 7346 RTP/AVP 28 31 (face) > m=video 7880 RTP/AVP 26 28 (presentation) > > > If the response contained something like > > > ... > c=IN IP4 3.4.5.6 > m=audio 6540 RTP/AVP 0 1 > m=video 6578 RTP/AVP 28 > > the caller would not be able to tell which of the two offered video > streams > was accepted. > > >2. What response should I send for this? > > I'm not sure what to say except that it's all in RFC3264. I think the > most > >important point is that for all m= lines in the offer, there must be a > >corresponding m= line in the answer. > > GK>> I believe it should respond with a 488 - Not Acceptable and Warning > header set to 304. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
