Hi Gaurav, Yes, I can see you are right now.
RFC3264, Section "8 Modifying the Session" is quite clear about it when it refers to the "previous SDP". However in practice, refusing an SDP like this: >>c=IN IP4 3.4.5.6 >>m=audio 6540 RTP/AVP 0 1 >>m=video 6578 RTP/AVP 28 is a bit too strict, in my opinion. Even though the number of m= lines is less than the "previous SDP", it is still obvious what the offerer wants and the syntax of the SDP is still ok. For me, it would be better if the receiving UA tried to process the SDP as best as it could. This would maximise interoperability. Regards, Attila -----Original Message----- From: Attila Sipos Sent: 08 May 2007 11:23 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
