Subject: [Sip] SIPit 21 : Topics that attendees argued about

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:07:52 -0600

Digging through my notes:

Here are some of the topics where people were arguing. I'm capturing  
the smaller topics here. Larger arguments will get their own message.

* There were arguments about the dynamic payload map from numbers to  
codecs (identified in the SDP and sent in the RTP) being the same in  
the offer and the answer . The spec says they SHOULD. Some  
implementations were insisting they MUST.
* There were arguments around preserving the relative order of codecs  
on an m-line between the offer and the answer. The specs say SHOULD.
* There were implementations that offered an m-line with codecs A, B,  
and C, got an answer with C, then got upset when they got RTP with A  
(which is quite legal).
* There were arguments about deleting rejected m-lines on re-invites  
(which you cannot do), and on reusing the slot they occupy in re- 
invites (which you can do).
* There were implementations that didn't add the refresher tag in a  
session-refresh message when they were the refresher and there were  
arguments about whether that meant the other side could take the role.
* Several implementations handled a=sendonly as a session attribute,  
but not a media attribute - it can appear in either place.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 15:54:58 +0530

I was surprised to find 

> and C, got an answer with C, then got upset when they got RTP with A

On the list (like others who argued about it I think).

I had some offline discussions with some of the members on this.
While I agree this seems legal, this seems very counter-intuitive and
may result in wasted resources, would it not?

For example, if the offerer is a conference bridge or a transcoder, and
has a limited number of codecs of each type he offers, why should it
hold on to one codec of each type for the duration of the session, even
though the answerer has not supported it?

Any particular reason why this should be continued as a legal scenario?
Would it not be possible change it to say that the Offerer needs to
expect only those codecs which answerer has explicitly supported in the
answer?

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2007 2:38 AM
> To: sip List
> Subject: [Sip] SIPit 21 : Topics that attendees argued about
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Nov 2007 11:33:53 +0100

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.

Regards,

Christer

>While I agree this seems legal, this seems very 
>counter-intuitive and may result in wasted resources, would it not?
> 
>For example, if the offerer is a conference bridge or a 
>transcoder, and has a limited number of codecs of each type 
>he offers, why should it hold on to one codec of each type 
>for the duration of the session, even though the answerer has 
>not supported it?
> 
>Would it not be possible change it to say that the Offerer 
>needs to expect only those codecs which answerer has 
>explicitly supported in the answer?
> 
>Regards,
>Ravi.
> 
> --
>  
> Ravishankar. G. Shiroor
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Raj Jain" <[email-masked]>
Date: Thu, 22 Nov 2007 05:50:20 -0500

You can always lock down a codec by updating the initial offer. Take a look
at section 10.2 of RFC 3264.

Raj

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Thursday, November 22, 2007 5:34 AM
> To: [email-masked]; [email-masked]; [email-masked]
> 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 
> counter-intuitive and 
> transcoder, and

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 22 Nov 2007 11:57:52 +0100

I am surprised that this caused any confusion. RFC 3264 seems pretty
clear to me.

Citing from section 6.1:
  "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."

and from section 7:
  "The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer."

So, why should the offerer be expected to deal with formats not present
in the answer? (Of course, the offerer must be prepared to receive ALL
offered formats BEFORE the answer arrives)

Regards,
Ernst Horvath

> Sent: Thursday, November 22, 2007 11:34 AM

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 17:53:27 +0530

Comments inline...

Regards,
Nataraju A B
 
> From: Horvath, Ernst [mailto:[email-masked]] 
> Sent: Thursday, November 22, 2007 4:28 PM
> To: Christer Holmberg; RaviShankar Shiroor (WT01 - Telecom 
> Applications and Solutions); [email-masked]; [email-masked]
> I am surprised that this caused any confusion. RFC 3264 seems 
> pretty clear to me.
> 
> Citing from section 6.1:
>    preferred media format in the offer that is also listed in 
> the answer."
> 
> and from section 7:
> So, why should the offerer be expected to deal with formats 
> not present in the answer? (Of course, the offerer must be 
> prepared to receive ALL offered formats BEFORE the answer arrives)
> 
[ABN] this looks to me that, UAC upon reception of answer is not
expected to listen for any codec's not listed in the answer. But
accepting even the other codec's published in offer but not in answer
makes it lineant in accepting the packets from the other peer. But this
clearly outside the scope of standards. 

But if we turn off the accepting other codec's not listed in answer
would yield better hardware resource utilization.
Just for instance, 

Offer: g711u, g711a, g729
Answer: g711u, g711a

In this case after the o/a negotiation completes, then if we tune the
hardware resources @ UAC for g711 codec handling only, then the
bandwidth/resource utilization @ UAC would be optimal. The same
resources could be utilized for other calls which need g729 packet
handling capability.

Hope this makes sense to turn off particular codec handling (@UAC) not
listed in answer, but published in offer.

> > offer - no matter what you get in the answer - I think that in real 
> > life the only codec's 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 
> > codec's - it mostly contains a subset of the codec's in the offer.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > >I was surprised to find
> > > 
> > >>* There were implementations that offered an m-line with
> > codec's A, B,
> transcoder, 
> > >and has a limited number of codec's of each type he offers, 
> why should 
> > >it hold on to one codec of each type for the duration of 
> the session, 
> > >even though the answerer has not supported it?
> > > 
> needs to 
> > >expect only those codec's which answerer has explicitly 
> supported in 
> > >the answer?
> > > 
> > >Regards,
> > >Ravi.
> > > 
> > > --
> > >  
> > > Ravishankar. G. Shiroor
> > > > codec's (identified in the SDP and sent in the RTP) being
> > > the same in
> > > > * There were arguments around preserving the relative order
> > > of codec's
> > > > * There were implementations that offered an m-line with
> > > codec's A, B,

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Nov 2007 15:11:24 +0100

Hi, 

>   preferred media format in the offer that is also listed in 

The question is not what the offerer is supposed to send, but what he
should be able to receive.

>    were listed in the initial offer, but not present in the answer."

Yes. The problem with the "MAY" is that the other party doesn't know
whether the offerer will listen or not, so therefor I think it's more
saft to only use codecs which BOTH entities include in the SDP.

>prepared to receive ALL offered formats BEFORE the answer arrives)

In many cases the offerer will not - due to different kind of reasons -
accept anything before he receives the answer (yes, yes, I know what
RFC3261 says...).

Regards,

Christer

> > life the only codecs that participants will be prepared to 
> > codecs - it mostly contains a subset of the codecs in the offer.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > >I was surprised to find
> > > 
> > codecs A, B,
> > >and has a limited number of codecs of each type he offers, 
> why should 
> > >expect only those codecs which answerer has explicitly 
> supported in 
> > >the answer?
> > > 
> > >Regards,
> > >Ravi.
> > > 
> > > --
> > >  
> > > Ravishankar. G. Shiroor
> > > of codecs
> > > codecs A, B,

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 19:58:30 +0530

> at section 10.2 of RFC 3264.

That would be when you have to lock down to a subset of what has been
supported in the answer. Lets say if the offer contained A,B,C and the
answer contained only B, what would be the need to lockdown specifically
by another offer answer?

I am trying to understand if there is any particular reason why it has
been kept as it has been kept, considering that one more offer answer
would mean one more round of signaling overhead.

Regards,
Ravi.

> > supported in the
Use

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 22 Nov 2007 16:00:26 +0100

See inline comments. 

> Sent: Thursday, November 22, 2007 3:11 PM
> To: Horvath, Ernst; [email-masked]; 
> [email-masked]; [email-masked]

So what's the problem? The text talks about what the answerer is
supposed to send, not the offerer.  Initially the offerer must expect
any format that he included in the offer. But once the answer has
arrived, an answerer that conforms to RFC 3264 WILL send only formats
included in the answer, so the offerer CAN stop listening for all other
formats.

> saft to only use codecs which BOTH entities include in the SDP.

No, the MAY gives a conformant offerer the permission to stop listening
immediately on arrival of the answer. That means for the conformant
answerer that he MUST NOT assume that the offerer is still listening for
formats that were not in the answer. I know, auxiliary verbs can be
tricky, but the two cited excerpts from RFC 3264 are entirely
consistent.

Regards,
Ernst

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Nov 2007 16:13:20 +0100

Hi, 

>>The question is not what the offerer is supposed to send, 
>>but what he should be able to receive.
>> 
> 
>So what's the problem? The text talks about what the answerer 
>is supposed to send, not the offerer. 

Correct, my misstake. When reading the text again, I agree that it is
clear: whatever codec the answerer is going to send must be both in the
offer AND in the answer.

>Initially the offerer must expect any format that he included in the
offer. But 
>once the answer has arrived, an answerer that conforms to RFC 
>3264 WILL send only formats included in the answer, so the 
>offerer CAN stop listening for all other formats.
> 
>> 
>>>and from section 7:
>No, the MAY gives a conformant offerer the permission to stop 
>listening immediately on arrival of the answer. That means 
>for the conformant answerer that he MUST NOT assume that the 
>offerer is still listening for formats that were not in the 
>answer. I know, auxiliary verbs can be tricky, but the two 
>cited excerpts from RFC 3264 are entirely consistent.

Yes, when re-reading the first citing the second citing makes sense.

Regards,

Christer

> > >So, why should the offerer be expected to deal with formats not 
> > >present in the answer? (Of course, the offerer must be prepared to 
> > >receive ALL offered formats BEFORE the answer arrives)
> > 
> > In many cases the offerer will not - due to different kind 
> of reasons 
> > - accept anything before he receives the answer (yes, yes, 
> I know what
> > RFC3261 says...).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: "Raj Jain" <[email-masked]>
Date: Thu, 22 Nov 2007 10:21:04 -0500

> 
> > > You can always lock down a codec by updating the initial 
> offer. Take 
> > > a
> > look
> That would be when you have to lock down to a subset of what 
> has been supported in the answer. Lets say if the offer 
> contained A,B,C and the answer contained only B, what would 
> be the need to lockdown specifically by another offer answer?

Yes, there is obviously no need to lock down in that case. You are probably
aware that the offerer must be willing to accept any of the codecs that it
offered before the answer arrives (early media). If your offerer
implementation can not handle that then a=inactive in the offer and then a
subsequent update with a=sendrecv will do the trick.

Anyway, you seem to be more concerned about what happens post-answer. I
think RFC 3264 is pretty clear about this. In your example, if the answerer
(who answered with only B) actually sends codecs A or C in the media, then
that answerer is broken. Somebody cited section 6.1 of RFC 3264 in an
earlier posting which clearly spells it out.

Regards,
Raj Jain

---

From: [email-masked]
Date: Thu, 22 Nov 2007 12:34:00 -0500

From: "Horvath, Ernst" <[email-masked]>

   Citing from section 6.1:

   and from section 7:

Perhaps the matter hinges on the meaning of "upset" in the original
post.  It's perfectly legal (per RFC 3264 cited above) for the
receiver to not render RTP using a codec not in the answer, but since
such packets may be lingering in the network, it must not fail or be
problematic if it receives such RTP.

Dale

---

From: [email-masked]
Date: Thu, 22 Nov 2007 12:34:00 -0500

Citing from section 6.1:

   and from section 7:

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Nov 2007 11:41:51 -0600

On Nov 22, 2007, at 4:33 AM, Christer Holmberg wrote:

> life

So how do you deal with asymmetric encoding?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 23 Nov 2007 11:48:19 +0100

Hi,

>> life the only codecs that participants will be prepared to send/receive are

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

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 23 Nov 2007 12:55:53 +0200

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 

> Sent: Friday, November 23, 2007 12:48 PM
> To: Dean Willis
> Cc: [email-masked]
> 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
> 
> 
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 23 Nov 2007 12:12:47 +0100

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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 23 Nov 2007 08:13:19 -0600

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

> 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).
>

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.

> 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
>
>>>> life the only codecs that participants will be prepared to send/ 
>>>> receive
>> are

---

From: [email-masked]
Date: Fri, 23 Nov 2007 12:31:14 -0500

From: Robert Sparks <[email-masked]>

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Nov 2007 10:51:52 -0600

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2007 12:34:27 -0500

> 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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Nov 2007 14:17:15 -0600

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:

> 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.
>
> 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:
>
> *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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2007 15:33:38 -0500

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:
> 
> the offerer must be prepared to receive RTP containing A, B, or C. After 
> each answer (again remember forking),
> 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
> 
>> prepared to receive any of the formats listed in the answer, and MAY 
>> NOT be prepared to receive any other format.
>>
>> "extra" formats listed in the answer (which the answerer has no way of 
>> knowing) then it may go ahead and use those.
>>
>> the intersection of the offer and the answer. So the offerer must be

---

From: [email-masked]
Date: Tue, 27 Nov 2007 00:14:14 -0500

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

   > [...]

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 [...].

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Nov 2007 09:43:53 +0100

Hi,

I also think it would be useful to add some text about the importance of
providing an answer as soon as possible, since some implementations will
not accept any media before they have received an answer (or, at least a
preview of an answer).

Regards,

Christer 

> Sent: 26. marraskuuta 2007 22:17
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Summary of "what answerer can send" thread (was Re: 
> [Sip] SIPit 21 :Topics that attendees argued about)
> 
> Ok - I think we've found the necessary chunks of text needed 
> to put this part of the thread down.
> 
> 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
> 
> >    media for any recvonly streams described by that answer. 
>  It MUST 
> > be
> >>>    accepted stream(s) (assuming it is listed as sendrecv 
> or recvonly 
> >>> in
> >>>       noise codec.  Or, if the user presses a number on 
> the keypad, 
> >>> the
> >>>       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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 30 Nov 2007 15:11:38 +1100

> (nor does it constrain what the answerer can send).

The last sentence from dale's quote says:

"The offerer MAY immediately cease listening for media formats that
  were listed in the initial offer, but not present in the answer"

Isn't that good enough to suggest that the offerer may accept only what both
have negotiated in the offer/answer exchange?

Hisham