comment at end.
Dale Worley wrote:
> On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
>> I think answerer can add additional codec G729 here per sec 6.1 of
>> rfc3264
>>
>> <snip>
>> 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
>> </snip>
>>
>> However, here comes the inconsistency.
>>
>> When answerer send media, it cannot send G723 packets to offerer per sec
>> 6.1 of RFC3264
>>
>> <snip>
>> The answerer MUST send using a media format in the offer
>> that is also listed in the answer,
>> </snip>
>>
>> Whereas RFC3264 does not forbid offerer to send G729 packets to answerer
>> per sec 7
>>
>> <snip>
>> It MUST send using a media format listed in the answer,
>> and it ***SHOULD*** use the first media format listed in the answer when
>> it
>> does send.
>> </snip>
>
> I think you've found a mistake in the wording of the RFC. The writers
> assumed that if the offerer was willing to send G729, then it would have
> offered to do so. Clearly, the intention is that both the offerer and
> answerer must use only codecs that have been listed in both the offer
> and the answer.
I think there was some inconsistency in thinking about whether this is a
*negotiation* or a *declaration*.
Note that the answerer is permitted to begin sending media to the
offerer as soon as the offer is received. So at that point this is being
considered a declaration, not a negotiation. While the answerer is
obligated to list the codecs it is sending to in the answer, the offerer
doesn't necessarily have the answer when packets arrive.
But requiring the answer to list the packets the answerer will send to
does turn it into an after-the-fact negotiation.
Allowing the answer to have new codecs, and the offerer to send to them
is simply symmetry with the answerer being able to use any of the codecs
in the offer.
My impression is that when this was first done there was a lot of
concern in reducing round trips, so it was only a 2-way handshake rather
than 3-way. In retrospect, it seems that few implement the way it was
apparently intended. Many apparently can't support multiple concurrent
codecs and so need a negotiation to settle on one before media can flow.
Others have different kinds of restrictions. So it seems a *negotiation*
is really needed, even if it takes more round trips.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
