RE: SIPit 21 : Topics that attendees argued about

Hi,
The offerer need to be able to receive any codec that he
declared in the offer regardless of answer.
The offerer may send a re-invite after the answer to fix the
set of codecs to a smaller set.
Roni Even 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com]
> Sent: Friday, November 23, 2007 12:48 PM
> To: Dean Willis
> Cc: sipietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees
argued about
> 
> Hi,
> 
> >> I agree with Ravi.
> >>
> >> Eventhough you in theory is supposed to be
able to receive what you
> >> offer - no matter what you get in the answer -
I think that in real
> >> life the only codecs that participants will be
prepared to send/receive
> are
> >> the ones sent both in the offer and the
answer. That is also the
> >> reason
> >> why the answer normally doesn't contain
additional codecs - it mostly
> >> contains a subset of the codecs in the offer.
> >So how do you deal with asymmetric encoding?
> 
> You may use different codecs in each direction
(eventhough I don't think
> it happens very often), as long as all codecs have been
present in both
> the offer and the answer.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> _______________________________________________
> 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

Hi,

>The offerer need to be able to receive any codec that he
declared in the offer regardless of answer.

Before or after he has received the answer?

BEFORE he has received the answer he may accept anything
that was in the offer (eventhough in many cases he will not
accept - or even receive (due to gates etc) - anything until
he has received the answer).

AFTER he has received the answer he may accept only what
both parties have indicated support for.


>The offerer may send a re-invite after the answer to fix
the set of codecs to a smaller set.

That is normally done when both the offer and the answer
have contained multiple codecs which both support.

But, if I offer you A, B and C, and you send back C, I am
not necessarily going to send a re-INVITE to
"remove" A and B - I may assume that we will only
use C (based on the text from 3264 we've seen cited in this
thread).

Regards,

Christer

 

 


Roni Even

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com]
> Sent: Friday, November 23, 2007 12:48 PM
> To: Dean Willis
> Cc: sipietf.org
> Subject: RE: [Sip] SIPit 21 : Topics that attendees
argued about
>
> Hi,
>
> >> I agree with Ravi.
> >>
> >> Eventhough you in theory is supposed to be
able to receive what you
> >> offer - no matter what you get in the answer -
I think that in real
> >> life the only codecs that participants will be
prepared to send/receive
> are
> >> the ones sent both in the offer and the
answer. That is also the
> >> reason
> >> why the answer normally doesn't contain
additional codecs - it mostly
> >> contains a subset of the codecs in the offer.
> >So how do you deal with asymmetric encoding?
>
> You may use different codecs in each direction
(eventhough I don't think
> it happens very often), as long as all codecs have been
present in both
> the offer and the answer.
>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> 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

On Nov 23, 2007, at 5:12 AM, Christer Holmberg wrote:

> Hi,
>
>> The offerer need to be able to receive any codec
that he declared  
>> in the offer regardless of answer.
>
> Before or after he has received the answer?
>
> BEFORE he has received the answer he may accept
anything that was  
> in the offer (eventhough in many cases he will not
accept - or even  
> receive (due to gates etc) - anything until he has
received the  
> answer).
>
> 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?

I'm pretty sure the answer event has no effect on what he
needs to  
receive.

>
>
>> The offerer may send a re-invite after the answer
to fix the set  
>> of codecs to a smaller set.
>
> That is normally done when both the offer and the
answer have  
> contained multiple codecs which both support.
>
> But, if I offer you A, B and C, and you send back C, I
am not  
> necessarily going to send a re-INVITE to
"remove" A and B - I may  
> assume that we will only use C (based on the text from
3264 we've  
> seen cited in this thread).
>
> Regards,
>
> Christer
>
>
>
>
>
>
> Roni Even
>
>> -----Original Message-----
>> From: Christer Holmberg
[mailto:christer.holmbergericsson.com]
>> Sent: Friday, November 23, 2007 12:48 PM
>> To: Dean Willis
>> Cc: sipietf.org
>> Subject: RE: [Sip] SIPit 21 : Topics that attendees
argued about
>>
>> Hi,
>>
>>>> I agree with Ravi.
>>>>
>>>> Eventhough you in theory is supposed to be
able to receive what you
>>>> offer - no matter what you get in the
answer - I think that in real
>>>> life the only codecs that participants will
be prepared to send/ 
>>>> receive
>> are
>>>> the ones sent both in the offer and the
answer. That is also the
>>>> reason
>>>> why the answer normally doesn't contain
additional codecs - it  
>>>> mostly
>>>> contains a subset of the codecs in the
offer.
>>> So how do you deal with asymmetric encoding?
>>
>> You may use different codecs in each direction
(eventhough I don't  
>> think
>> it happens very often), as long as all codecs have
been present in  
>> both
>> the offer and the answer.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

   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

Dale -

What you quoted talks about what the offer can _send_.
It doesn't talk about what the offerer must be willing to
receive  
(nor does it constrain what the answerer can send).

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

   From: Robert Sparks <rjsparksnostrum.com>

   What you quoted talks about what the offer can _send_.
   It doesn't talk about what the offerer must be willing to
receive  
   (nor does it constrain what the answerer can send).

Perhaps I'm misunderstanding you, but in regard to what the
offerer
must be willing to receive, this seems unambiguous:

   > Here's section 7 of RFC 3264 (found by Ernst
Horvath):
   > [...]
   >    The offerer MAY immediately cease listening for
media formats that
   >    were listed in the initial offer, but not present
in the answer.

In regard to what the answerer can send, RFC 3264 section
6.1 is
clear:

   The answerer MUST send using a media format in the offer
that is
   also listed in the answer [...].


   From: Robert Sparks <rjsparksnostrum.com>

   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.

I don't want to sound snarky, but isn't "Read RFC
3264." implicit in
regard to SIP implementation?

I'm willing to have it pointed out to me that it's easier to
overlook
this information than I'm allowing for, but it seems to me
that the
answers to these questions are both what one would naively
expect, and
also are documented in the sections of the document that one
would
expect to find them in.  The only gotcha that I can see is
the
consequences of forking, if the offer is contained in a
dialog-forming
request, in that until the transaction of the dialog-forming
request
is terminated, the UAC must behave as if there are unknown
un-answered
offers in flight.  But that is implicit in the RFC 3264
model once one
thinks about it.

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