|
List Info
Thread: Re: SIPit 21 : Topics that attendees argued about
|
|
| Re: SIPit 21 : Topics that attendees
argued about |
 
United States |
2007-11-26 11:34:27 |
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
|
|
| Summary of "what answerer can
send" thread (was Re: SIPit 21 :
Topics that attendees argued |
United States |
2007-11-26 14:17:15 |
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.Worleycomcast.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
|
|
[1-2]
|
|