Rajnish Jain wrote:
> *Can answerer add new codecs which were not present in offer to answer SDP?*
>
> Yes.
>
> *OR *
> *Should answerer select codecs only in offer and list formats in the same
> relative order they were present in the offer?*
>
> Not necessarily. It will be answerer's discretion to add whatever media
> formats it wants and list them in whatever order it wants as long as
> there is atleast one common media format between offer and answer.
I agree with this. I believe this has been discussed before, though I
don't remember when or where.
Paul
> Here is a quote from section 6.1 of RFC 3264:
>
>
> For streams marked as recvonly in the answer, the "m=" line MUST
> contain at least one media format the answerer is willing to receive
> with from amongst those listed in the offer. The stream MAY indicate
> additional media formats, not listed in the corresponding stream in
> the offer, that the answerer is willing to receive. For streams
> marked as sendonly in the answer, the "m=" line MUST contain at least
> one media format the answerer is willing to send from amongst those
> listed in the offer. For streams marked as sendrecv in the answer,
> the "m=" line MUST contain at least one codec the answerer is willing
> to both send and receive, from amongst those listed in the offer.
> The stream MAY indicate additional media formats, not listed in the
> corresponding stream in the offer, that the answerer is willing to
> send or receive (of course, it will not be able to send them at this
> time, since it was not listed in the offer).
>
>
> Rajnish
>
>
>
>
>> On 3/11/07, Sumin Seo <[EMAIL PROTECTED]> wrote:
>>> Hi All,
>>>
>>> I have a question regarding on SDP offer and answer.
>>> One of our engineers interprets rfc 3264 like below.
>>> "rfc 3264 doesn't say that answer MUST not include more codecs which are
>>> not in offer.
>>> rfc 3264 also says that the answerer MAY list the formats in their
>> desired
>>> order of preference.
>>> It is RECOMMENDS that the answerer list formats in the same relative
>> order
>>> they were present in the offer.
>>> So, Session MUST be established as long as there is one common codec in
>>> answer regardless of order of preference or existence of codecs not in
>>> answer. "
>>>
>>> Based on his interpretation, following negotiations should work.
>>> Offer Answer Offer Answer
>>> ----------> --------------->
>>> (a, b, c) (a, b ,c)
>>> <---------- <----------------
>>> (d, b, c, e, f) (b, c, d, e, f)
>>> I did some interop tests with several carriers. As long as first codec
>> in
>>> answer is one of codecs in offer, calls are successfully connected.
>>>
>>> *Can answerer add more codecs which were present in offer?*
>>> *OR *
>>> *Should answerer select codecs only in offer and list formats in the
>> same
>>> relative order they were present in the offer?*
>>>
>>>
>>> Thanks in advance.
>>> -Sumin.
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
