Subject: [MMUSIC] Using payload types not specified in answer in offer/answer

From: Roman Shpount <[email-masked]>
Date: 13 Feb 2002 04:07:01 GMT

It is unclear from the specification whether answerer is allowed to send media with payload types not specified in the response to sendonly or sendrecv offer. It clearly states that the offerer should be prepared to receive those payload types before the answer arrives, but is it safe to assume that those payload types will not be used if they are not specified in the answer once the answer was received?___________________________________
Roman Shpount, VP of Technology
aTelo, Inc. 
2107 Wilson Blvd., Suite 301 
Arlington, VA 22201 
PCN: 703-621-4040 for voice / fax
www.atelo.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 11:03:14 -0500

Roman Shpount wrote:
> 
> It is unclear from the specification whether answerer is allowed to send
> media with payload types not specified in the response to sendonly or
> sendrecv offer. 

This doesn't make sense to me. If the offer is sendonly, the answer is
recvonly, so the answerer cannot send media. 

In the case of sendrecv, it should only be sending with codecs in its
answer. This is in the document:

It
{\MUST} be prepared to send and receive media for any sendrecv streams
in the answer, and {\MAY} send media immediately. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Roman Shpount <[email-masked]>
Date: 13 Feb 2002 18:52:40 GMT

Roman Shpount wrote:
> 
> My mistake. What I wanted to say was if the offer was recvonly or
> sendrecv. For example if the offer is:
> 
>    v=0
>    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
>    s=
>    c=IN IP4 host.anywhere.com
>    t=0 0
>    m=audio 49170 RTP/AVP 0 110
>    a=rtpmap:0 PCMU/8000
>    a=rtpmap:110 telephone-events
>    a=recvonly
> 
> And if the answer is
> 
>    v=0
>    o=bob 2890844730 2890844730 IN IP4 host.example.com
>    s=
>    c=IN IP4 host.example.com
>    t=0 0
>    m=audio 47920 RTP/AVP 0
>    a=rtpmap:0 PCMU/8000
>    a=sendonly
> 
> Is the answerer allowed to send AVT tones with a RTP payload type 110?

Jonathan D. Rosenberg wrote:

>No. 
>
>But, if it wants to, why would it delete it from the anwer? Just put it
>in.

Is it stated somewhere in the offer/answer? 

Again, it probably makes little sence for recvonly, but it is quite common for sendrecv as well. So if we modify above example for the sendrecv scenario.
 The offer would be:

    v=0
    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
    s=
    c=IN IP4 host.anywhere.com
    t=0 0
    m=audio 49170 RTP/AVP 0 110
    a=rtpmap:0 PCMU/8000
    a=rtpmap:110 telephone-events
 
 And if the answer would be:
 
    v=0
    o=bob 2890844730 2890844730 IN IP4 host.example.com
    s=
    c=IN IP4 host.example.com
    t=0 0
    m=audio 47920 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

Would any party on the call be allowed to use avt tones? If it does or does not, where is it specified?
___________________________________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: 13 Feb 2002 20:48:16 GMT

Jonathan D. Rosenberg wrote:

> Let me ask the converse - what is gained by having the answerer be able
> to send with things not in the answer? Why not just include them in the
> answer?

This is primarily a question of interpretation. I know at least one gateway implementation which is capable of sending, but not receiving avt tones. So this gateway replies to a sendrecv offer, which contains avt tones and G.711, with an answer that contains only G.711, but sends out avt tones anyway. I am looking for the language that states whether this behavior is legal or not.

---

From: Roman Shpount <[email-masked]>
Date: 14 Feb 2002 08:49:28 GMT

Hi Folks,

There are enough SIP implementations on the market that would require treating the set of codecs in the offer and the answer as two independent sets. We can decide whatever we want in the standard but interoperability with existing solutions will force people to implement this anyway. Furthermore, the behavior in which offer and answer are treated separately is more generic and includes all possible scenarios.

So what I offer is that if offer for sendonly or sendrecv offer contains codecs A, B, C, the answer can contain A, B, D. Additionally answer can use different payload types for A and B. The only requirements are that the offer and the answer contain at least one codec of the same type and the answerer must use the payload types from the offer.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 11:07:42 -0500

Roman Shpount wrote:
> This is primarily a question of interpretation. I know at least one
> gateway implementation which is capable of sending, but not receiving
> avt tones. So this gateway replies to a sendrecv offer, which contains
> avt tones and G.711, with an answer that contains only G.711, but sends
> out avt tones anyway. I am looking for the language that states whether
> this behavior is legal or not.

I had text that allowed exactly this in the previous version, for
exactly this reason. Consensus at the last IETF was to remove it. The
reason was, that in a sendrecv stream, the codecs you list have to be
sendrecv codecs. I think that all of the confusion here is about the
interpretation of what it means to be a "sendrecv" codec... please see
my response to Flemming.

Just as a note, we have a DROP DEAD date for completion of this document
by monday, so let us not let this thread die! So far so good, but I just
want to be sure folks are aware of the time pressures we are under.

-Jonathan R.

---

From: Roman Shpount <[email-masked]>
Date: 14 Feb 2002 17:35:47 GMT

> want to be sure folks are aware of the time pressures we are under.

I understand the time pressure. All I want is to have a consistent behavior specified by the standard. The original rfc2543 use to specify in section B.2:

   If the media stream is listed as both send and receive, the callee 
   lists those codecs it is capable of sending or receiving among the 
   ones listed by the caller in the INVITE. 

Starting from rfc2543bis3 it it changed to (Section B.2.1):

   If multiple codecs are listed, it means that the offerer is capable 
   of making use of any of those codecs during the call. In other words,
   the answerer MAY change codecs in the middle of the call, without
   sending a SIP message, to make use of any of those listed.

Once again, there are enough rfc2543bis3 compliant implementations out there to justify not changing the offer/answer behavior once more. The later model can easily be implemented, since the support for it is already in place for early media. In any case, we should at least specify that the offerer MUST accept all the codecs from the original offer, regardless whether the answerer MAY or SHOULD not send using any codecs not specified in the answer.

---

From: Roman Shpount <[email-masked]>
Date: 15 Feb 2002 08:24:12 GMT

I would definitely agree with Jonathan in his point of view about codec negotiation if we had a luxury of defining a new standard. Unfortunately what is being done here (at least from my point of view) is just an attempt to ensure interoperability of existing applications. My suggestion for this standard would be something along the lines:

  Offerer MUST accept all the codecs from the original offer. Answerer 
  SHOULD NOT send using any codecs not specified in the answer.

This way we have implementations compatible with both rfc2543 and rfc2543bis3. It is a compromise that I think should always work.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 10:07:12 -0500

>   SHOULD NOT send using any codecs not specified in the answer.

"SHOULD NOT" is not to be taken lightly, and hence this effectively says that you can only use the codecs in the answer. As I indicated in another e-mail to Jonathan, there's little to be gained from this restriction, but things to be lost, and hence we should continue with the practice of allowing the answerer to send with offered codecs not
contained in the answer.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Roman Shpount <[email-masked]>
Date: 15 Feb 2002 18:17:29 GMT

Roman Shpount wrote:

> I would definitely agree with Jonathan in his point of view about codec
> negotiation if we had a luxury of defining a new standard. Unfortunately 
> what is being done here (at least from my point of view) is just an 
> attempt to ensure interoperability of existing applications. My 
> suggestion for this standard would be something along the lines:
>

Flemming Andreasen wrote:

> "SHOULD NOT" is not to be taken lightly, and hence this effectively says
> that you can only use the codecs in the answer. As I indicated in 
> another e-mail to Jonathan, there's little to be gained from this 
> restriction, but things to be lost, and hence we should continue with 
> the practice of allowing the answerer to send with offered codecs not
> contained in the answer.

There are two problems that I have with answerers sending with codecs not in the answer:
1. Interoperability with original RFC2543
2. Interoperability with current 1 of N codecs selection

Let me explain the second one. The offerer is capable of sending and receiving G.711, G.723 and telephone-events with only G.711 or G.723 supported at the same time. The answerer is capable of sending and receiving G.711 and G.723, but can only send telephone-event. The following message exchange takes place:

Initial offer:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 6400 RTP/AVP 0 4 110
   a=rtpmap:0 PCMU/8000
   a=rtpmap:4 G723/8000
   a=rtpmap:110 telephone-events 
   a=inactive

Initial answer:

   v=0
   o=bob 2890844730 2890844731 IN IP4 host.example.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 6400 RTP/AVP 0 4
   a=rtpmap:0 PCMU/8000
   a=rtpmap:4 G723/8000
   a=inactive

When Alice generates updated offer it has no way of knowing that Bob intends to use telephon
d offer:

   v=0
   o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 6400 RTP/AVP 4
   a=rtpmap:4 G723/8000
   a=sendrecv

Final answer:

   v=0
   o=bob 2890844730 2890844732 IN IP4 host.example.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 6400 RTP/AVP 4
   a=rtpmap:4 G723/8000
   a=sendrecv

Thus after this exchange telephone-events are not used by either party. Thus I am not sure that we achieve anything by allowing the answerer to send with payloads not included in the answer. 

The solution for the problems that we are trying to solve (assymetric use of codecs) is in either SDPng or expanding SDP. I am convinced that expanding SDP can be done in backwards-compatible way (for instance by adding a direction attribute on the per codec basis), but the discussion of this is probably outside the topic of this thread.
  
____________________________________________________
Roman Shpount, VP of Technology
aTelo, Inc. 
2107 Wilson Blvd., Suite 301 
Arlington, VA 22201 
PCN: 703-621-4040 for voice / fax
www.atelo.com

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 14:10:05 -0500

> 1. Interoperability with original RFC2543

Not sure this is a real issue, as RFC 2543 was not entirely clear on this and, as indicated earlier, the understanding a lot of people had is to allow the answerer to send with any offered codec, regardless of the answer.

> When Alice generates updated offer it has no way of knowing that Bob intends to use telephone-events, so it does not include it in updated offer:
>
>    v=0

Well, nothing prevents Alice from including telephone-events in the offer again, especially if she knows that Bob could actually still use it, so this really doesn't show much. Also, if you didn't use the "inactive" offer/answer intially, but instead did "sendrecv", it would still work.

>
> The solution for the problems that we are trying to solve (assymetric use of codecs)

I'm not trying to solve that problem, as it would entail much more than we have on the table here. The question is simply which of two interpretations/modes of operation to go with. I've provided arguments on this in several e-mails already.

> is in either SDPng or expanding SDP. I am convinced that expanding SDP can be done in backwards-compatible way (for instance by adding a direction attribute on the per codec basis), but the discussion of this is probably outside the topic of this thread.

I agree it's a separate discussion :-)

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Roman Shpount <[email-masked]>
Date: 15 Feb 2002 19:51:44 GMT

Flemming Andreasen wrote:

> Not sure this is a real issue, as RFC 2543 was not entirely clear on
> this and, as indicated earlier, the understanding a lot of people had is
> to allow the answerer to send with any offered codec, regardless of the
> answer.

The problem is that there are also enough people that interpreted RFC 2543 the other way (not accepting codecs not specified in the answer). So, in order to interoperate with products from those people the answerer should not send media with codecs not included in the answer.

---

From: Roman Shpount <[email-masked]>
Date: 15 Feb 2002 21:40:28 GMT

Roman Shpount wrote:

> The problem is that there are also enough people that interpreted RFC
> 2543 the other way (not accepting codecs not specified in the answer).
> So, in order to interoperate with products from those people the 
> answerer should not send media with codecs not included in the answer.

Flemming Andreasen wrote:

> We obviously can't support both interpretations, however could we put in
> a note about it being a potential problem for some older implementations
> and hence at least alert people to it ?

Why can't we? If a device accepts everything in its offer and sends only with codecs specified in the answer it will interoperate with devices that are implemented according to either interpretation. This is a general "accept as much as possible, generate only standard compliant" type principal. This is why I proposed "SHOULD NOT send with codecs not specified in answer" in the standard.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 16:53:15 -0500

> Why can't we? If a device accepts everything in its offer and sends only with codecs specified in the answer it will interoperate with devices that are implemented according to either interpretatio…

Well, that would be picking one interpretation - not supporting both.

-- Flemming

--
Flemming Andreasen
Cisco Systems