As Attila says, RFC 3264 is quite clear that the unused media lines must
not be dropped, so the answer shown is invalid. You should never make
such an offer. If you receive such an offer, you could choose to accept
it rather than rejecting it. This would be prudent, since in some cases
the answer comes in a response and so can't be rejected.
If the answer came in a request, and you choose to reject it, I think
possible responses are 400, 488, 606.
Paul
Attila Sipos wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
