OKUMURA Shinji wrote:
> Hi Mr. Kyzivat,
Please, lets not be formal. Call me Paul. :-)
> If the direction of the answer is "recvonly" or "inactive", it is
> no problem that the answerer adds new codec. But if the direction
> is "sendrecv" ("sendonly" is certainly not allowed), the added
> codec is "implicit-recvonly".
I guess that is a good way to think of it.
> The offerer MAY send the added codec to the answerer.
I guess you mean the offerer may send media encoded using the added
codec to the answerer. I agree.
> But this
> negotiated state is very brittle. IMO it will not be able to
> endure reINVITE. Because the answerer can not indicate the added
> codec in new offer, unless it determine the change.
I don't understand you here.
A reinvite may result in an o/a with the offerer and answerer being the
same as before, or it may result in them being reversed from before. But
either way, the new codec may be included in either the offer or answer.
If in the new reinvite, the o2 is by the same offerer as o1, then it may
include the added codec. The presence of the codec in a1 may have
suggested that it would be useful to include it in o2. Of course o2 may
also *not* include the codec. That can set up a replay of the earlier
o/a exchange.
If in the new reinvite, the o2 is by the earlier answerer, then of
course it may include the added codec. This isn't required, but it would
be a natural thing to do. In that case the other end will have the
opportunity to refuse at codec.
> I think this is a problem for RFC3264.
> What do you think about this reINVITE ?
I'm not seeing what the problem is.
Thanks,
Paul
> Regards,
> Shinji
>
> Paul Kyzivat <pkyzi...@cisco.com>
>> Rockson Li (zhengyli) wrote:
>>> Paul,
>>>
>>> If I catch you clearly, do you mean this is a real bug in RFC3264?
>> IMO this is unclear. It might be that what is written is not exactly
>> what the original authors intended. Or maybe it is as intended but isn't
>> what people now wish had been written.
>>
>> Either way it isn't necessarily a bug if what is written can be
>> implemented, which seems to be the case.
>>
>>> Do we have some formal doc/draft to clarify usage here?
>> I don't think so.
>>
>> At this point any change in the specs is likely to disrupt somebody's
>> implementation, so things must be done carefully.
>>
>> If it is considered that there is ambiguity about how this should be
>> implemented, then a clarification would be a good thing. But it will
>> then take some work to decide which of the possible interpretations
>> should be blessed.
>>
>> I'd be interested to hear what is implemented in practice - perhaps
>> stats from SipIt.
>>
>> Thanks,
>> Paul
>>
>>> Thanks
>>> Regards,
>>> -Rockson
>>> -----Original Message-----
>>> From: Paul Kyzivat (pkyzivat)
>>> Sent: Saturday, August 15, 2009 7:54 AM
>>> To: Dale Worley
>>> Cc: Rockson Li (zhengyli); sip-implementors@lists.cs.columbia.edu
>>> Subject: Re: [Sip-implementors] Can EP send media only peer supports
>>>
>>> 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
