I think this would fit nicely as a new section of
draft-ietf-sipping-sip-offeranswer-xx. (Probably between the
existing
sections 5 and 6.) But that has already completed wglc, so
adding an
entirely new section may be problematic.
Paul
Robert Sparks wrote:
> Ok - I think we've found the necessary chunks of text
needed to put this
> part of the thread down.
>
> My introduction of the thread had a wrong conclusion in
it (per 3254 6.1).
>
> To re-summarize:
>
> If an m-line in the offer offers codecs A, B, and C
then until all
> possible answers are received (think forking),
> the offerer must be prepared to receive RTP containing
A, B, or C. After
> each answer (again remember forking),
> that answerer MUST only send RTP packets using the
codecs that are in
> the intersection of the offer and the answer
> for that m-line. So, for instance, if that m-line in
the answer
> contained only B, the answerer can only send B. Once
it's
> received the answer, the offerer can decide to only
render B, but due to
> race conditions it should anticipate seeing some
> A or C coded packets, but nobody should expect it to do
anything useful
> with them.
>
> Now we need to find where to put pointers to this so
that it isn't so
> hard for implementers in the future to find.
>
> RjS
>
> On Nov 26, 2007, at 11:34 AM, Paul Kyzivat wrote:
>
>>
>>
>> Robert Sparks wrote:
>>> Dale -
>>> What you quoted talks about what the offer can
_send_.
>>
>> The second sentence says what format the offerer
MUST use when
>> sending. A corollary of that is that it MUST NOT
use some other
>> format. And a corollary of *that* is that the
answerer MUST be
>> prepared to receive any of the formats listed in
the answer, and MAY
>> NOT be prepared to receive any other format.
>>
>> Note that this apparently includes formats listed
in the answer but
>> not in the offer! So if the offerer is capable of
using any of the
>> "extra" formats listed in the answer
(which the answerer has no way of
>> knowing) then it may go ahead and use those.
>>
>>> It doesn't talk about what the offerer must be
willing to receive
>>> (nor does it constrain what the answerer can
send).
>>
>> Yes, you are right - it doesn't.
>>
>> Section 5.1 says:
>>
>> ... If multiple formats are listed, it
>> means that the offerer is capable of making use
of any of those
>> formats during the session. In other words, the
answerer MAY change
>> formats in the middle of the session, making use
of any of the
>> formats listed, without sending a new offer.
...
>>
>> That certainly at least *implies* that the offerer
MUST initially be
>> capable of receiving any format listed in the
offer.
>>
>> Then Section 6.1 says:
>>
>> Once the answerer has sent the answer, it MUST
be prepared to receive
>> media for any recvonly streams described by that
answer. It MUST be
>> prepared to send and receive media for any
sendrecv streams in the
>> answer, and it MAY send media immediately. The
answerer MUST be
>> prepared to receive media for recvonly or
sendrecv streams using any
>> media formats listed for those streams in the
answer, and it MAY send
>> media immediately. When sending media, it
SHOULD use a packetization
>> interval equal to the value of the ptime
attribute in the offer, if
>> any was present. It SHOULD send media using a
bandwidth no higher
>> than the value of the bandwidth attribute in the
offer, if any was
>> present. The answerer MUST send using a media
format in the offer
>> that is also listed in the answer, and SHOULD
send using the most
>> preferred media format in the offer that is also
listed in the
>> answer. In the case of RTP, it MUST use the
payload type numbers
>> from the offer, even if they differ from those
in the answer.
>>
>> *This* says that the answerer is constrained to
send on a format in
>> the intersection of the offer and the answer. So
the offerer must be
>> prepared to receive everything it offers initially,
and then it can
>> *reduce* what it expects and is capable of
receiving once it receives
>> the answer.
>>
>> Thanks,
>> Paul
>>
>>
>>> RjS
>>> On Nov 23, 2007, at 11:31 AM, Dale.Worley comcast.net wrote:
>>>> From: Robert Sparks <rjsparksnostrum.com>
>>>>
>>>> On Nov 23, 2007, at 5:12 AM, Christer
Holmberg wrote:
>>>>> AFTER he has received the answer he may
accept only what both
>>>>> parties have indicated support for.
>>>>
>>>> I don't think that's right. Can you show
me the text that supports
>>>> that claim?
>>>>
>>>> Here's section 7 of RFC 3264 (found by
Ernst Horvath):
>>>>
>>>> 7 Offerer Processing of the Answer
>>>>
>>>> When the offerer receives the answer, it
MAY send media on the
>>>> accepted stream(s) (assuming it is
listed as sendrecv or recvonly in
>>>> the answer). 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.
>>>>
>>>> The reason this is a SHOULD, and not
a MUST (its also a SHOULD,
>>>> and not a MUST, for the answerer), is
because there will
>>>> oftentimes be a need to change codecs
on the fly. For example,
>>>> during silence periods, an agent
might like to switch to a
>>>> comfort
>>>> noise codec. Or, if the user presses
a number on the keypad, the
>>>> agent might like to send that using
RFC 2833 [9]. Congestion
>>>> control might necessitate changing to
a lower rate codec based on
>>>> feedback.
>>>>
>>>> The offerer SHOULD send media according
to the value of any ptime
>>>> and
>>>> bandwidth attribute in the answer.
>>>>
>>>> The offerer MAY immediately cease
listening for media formats that
>>>> were listed in the initial offer, but
not present in the answer.
>>>>
>>>> I skimmed
draft-ietf-sipping-sip-offeranswer-04 and I see nothing in
>>>> it that would alter the interpretation of
this section.
>>>>
>>>> Dale
>>>>
>>>>
>>>>
_______________________________________________
>>>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the
core SIP Protocol
>>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>>> Use sippingietf.org for new
developments on the application of sip
>>>
_______________________________________________
>>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol
>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org for new
developments on the application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
