Hi Attila, I agree with your point that in order to maximize interoperability the UA should try to process the message. However, it becomes complicated when we start looking at the SDP and try to figure out which of the media streams is gone. In the example, we cannot be sure as to which of the two streams corresponds to which; and which one is missing. I guess that was the main reason behind keeping the 1:1 correspondance for media streams in all subsequent OFFERs.
regards Rayees -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Tuesday, May 08, 2007 12:17 PM To: Gaurav Kheterpal; Kannaiyan; [email protected] Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and the reinvitebehaviour 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 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ---------------------------------------------------------------------------------- IMPORTANT The information contained in this e-mail any attachments is intended only for the named recipient and may be privileged or confidential. If you are not the intended recipient, please notify us immediately on +44 (0)1908 425000 and do not disclose, copy, distribute or take any action based on the contents of this e-mail. You should understand and accept that, when communicating with us by e-mail, it is not a totally secure communication medium. We accept no liability for any direct, indirect or consequential loss arising from any action taken in reliance on the information contained in this e-mail and give no warranty or representation as to its accuracy or reliability. DIGITALK has the facility to monitor and read both incoming and outgoing communications by e-mail. In line with industry efforts to reduce the proliferation of Un-Solicited SPAM messages, DIGITALK uses various methods including Reverse-DNS lookups and ban-lists to prevent malicious content reaching our users. This message and any attachments has been scanned for known viruses. However, we would advise you to ensure the content is indeed virus free. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or breach of confidentiality in relation to transmissions sent by e-mail. VAT No: GB 876 3287 81. Reg No: 3080801 Place of Registration: England Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes ----------------------------------------------------------------------------------" _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
