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

From: Roman Shpount <[email-masked]>
Date: 13 Feb 2002 17:25:49 GMT

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?

___________________________________
Roman Shpount

------ Original message ------
>From: Jonathan Rosenberg <[email-masked]>
>Subject: Re: Using payload types not specified in answer in offer/answer
>Date: 13 Feb 02, 04:03 PM
>To: Roman Shpount <[email-masked]>
>Cc: [email-masked]

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 13:23:22 -0500

> Is the answerer allowed to send AVT tones with a RTP payload type 110?

No. 

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

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Feb 2002 14:40:40 -0500

> > Is the answerer allowed to send AVT tones with a RTP payload type 110?

No ? I believe the answer is yes. Haven't we always said, that the SDP
indicates the set of media formats I can receive (assuming proper direction
attributes), and I want to change that, I need to send a new SDP ?

Where in offer/answer is this restriction described ? Also, if it you still
mean "no", then I don't understand why you want to allow the answer to
contain media formats not specified in the offer ? If asymmetry is allowed
in one direction, it should be allowed in both.

>
> But, if it wants to, why would it delete it from the anwer?

Same reason as the answerer might want to add a media format not present in
the offer:    asymmetry (e.g. I can send RFC 2833 to you, but I can't
receive it).

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

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

> attributes), and I want to change that, I need to send a new SDP ?

It indicates what you can receive for recvonly, indicates what you send
for sendonly, and indicates what you will both send and receive for
sendrecv. I thought you had argued strongly for that view at IETF 52...

> in one direction, it should be allowed in both.

In the case of sendrecv, subsetting is the only thing that makes sense.
If A indicates in an offer that it can send and receive with codecs
1,2,3, and B indicates in its answer that it can send and receive with
2,3,4, the presence of 4 is useless. B can't send with it, since it
doesn't know whether A can receive it. 

Now, consider the case once more of sendrecv, where A sends 1,2,3 in the
offer, and B sends 1,2 in the answer. Can B send with codec 3? No, it
can't. It can't because A can't send with it, and thus the codec would
effectively be unidirectional. This is a birdirectional stream. So, in
the case of sendrecv, B needs to be prepared to send and receive with
the codecs in the answer, and this is what the text 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 {\MAY} send media immediately. 
--

Now, in the case of a recvonly offer, A could indicate the ability to
receive 1,2, and 3. In the answer, lets say B returns 1,2 as sendonly.
But, then it sends using 3 anyway. If the answerer does not go with
whats in the answer, the answer provides zero information. The point of
the answer in this case is to help the offerer restrict the set of
codecs it needs to be prepared to receive. I do admit that I find no
text at the moment which says that the answerer in a sendonly answer
should send only with the codecs in the answer. However, that has been
my interprtation.

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?

> the offer:    asymmetry (e.g. I can send RFC 2833 to you, but I can't

Remember, we only support asymmetric codecs in asymmetric stream types.
In the case you describe, you are talking about a recvonly offer and a
sendonly answer. The spec says that the offer lists the codecs the
offerer can receive. If its not there, what is gained by adding it in
the answer? The answerer can't send it anyway, since it doesn't know if
the offerer supports it?

We did previously allow addition of recvonly codecs by the answerer in a
sendrecv stream, but agreed at IETF 52 to remove this hack in favor of
FID, which is the proper way to support such things. I recall you argued
in favor of that, even.

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Feb 2002 15:35:49 -0500

> sendrecv. I thought you had argued strongly for that view at IETF 52...

Yes - that's what I meant.

> doesn't know whether A can receive it.

Correct, but A can send with it.

> effectively be unidirectional.

I don't buy that argument since you could equally well have A sending with 1
and B sending with 2.

> This is a birdirectional stream. So, in

If the above was the intended implication, then it's not entirely clear.

> codecs it needs to be prepared to receive.

I thought it was so offerer can figure out what he can actually send with
(ignoring some of the unidirectional stream cases for a momemt).

> I do admit that I find no

I have always understood, that once I hand out an SDP indicating the ability
to receive codec 1,2, and 3, then I have to be able to receive those codecs
until I send out another SDP. Of course you can say, that this is because SDP
never defined the negotiation that offer/answer does, but this seems to
introduce an unnecesary deviation from "normal" SDP usage.

> to send with things not in the answer? Why not just include them in the

It could for example be that I can send RFC 2833 but not receive it.
Admittedly, SDP is not really good at expressing such unidirectional
constraints, and we probably shouldn't get hung up on it (however I thought
this was one of your concerns). My real concern here is that it seems to
deviate from current SDP behavior.

> Remember, we only support asymmetric codecs in asymmetric stream types.

We do ? If I offer 2 or more codecs and you answer with two or more codecs,
then we can have asymmetric codec usage.

> the answer? The answerer can't send it anyway, since it doesn't know if

However, I thought it would apply to bidirectional streams as well. For
example, if RFC 2833 is not offered , but the answerer is able to accept it,
he may want to indicate so in the answer (and vice versa).

> FID, which is the proper way to support such things. I recall you argued

I still do, however that doesn't mean you can't add a sendrecv codec to a
sendrecv stream, even though you may only be able to send or receive with it.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 03:06:49 -0500

inline. Let us resolve this quickly, only a few days remain in wglc:

Flemming Andreasen wrote:

> Correct, but A can send with it.

So, if A can send with it, but B can't, how is this a sendrecv codec,
practically speaking? 

> I don't buy that argument since you could equally well have A sending

True, although that is not the recommended behavior. 

> If the above was the intended implication, then it's not entirely clear.

Apparently not....

> (ignoring some of the unidirectional stream cases for a momemt).

You've lost me; we are talking explicitly about the unidirectional cases
here.

> until I send out another SDP. 

It is certainly true that you need to be able to receive them once you
send them, to handle media clipping. It had been my implicit assumption,
arguably not well thought thruough, that the answer would restrict what
the element needs to be prepared to receive. I suppose that, since it
needs to be able to receive them initially anyway, is there much gained
by learning that the set of things to receive is less than it needs to
initially?

One example is if A can support codecs 1,2,3,4,5, and it sends an offer
to B which really only supports 1, and thats what is in the answer. Now,
A would still need to be preapred to reeive 1-5 based on your proposal,
even though it effectively knows that B is never going to use anythign
but 1. I had assumed that the point of the offer/answer exchange was to
do a one-pass subsetting of the codecs in use. I am sure we have
discussed this in the past in the sip wg.

> Of course you can say, that this is
> because SDP

I can see that it is a bit odd.

I suppose that, if the offerer really wants to know a more restricted
set, it can always send an updated offer with fewer codecs, ala the
1-of-N mechanism in the examples in the draft. But, isn't it better to
avoid that if you know that the answer defines a subset that is
acceptable?

> deviate from current SDP behavior.

I guess I am confused on this, because we had text along those lines
before, and we agreed at ietf 52 to remove it. Specifically, we agreed
that, in a sendrecv answer, you cannot add codecs which are recvonly,
they have to be sendrecv. From the above, it sounds like you are backing
down from that.

> > > Same reason as the answerer might want to add a media format not
> present
> > > in

See above comment; I thought that we agreed that a sendrecv stream had
to list sendrecv codecs. 

> he may want to indicate so in the answer (and vice versa).

As above, I removed text that explicitly allowed this based on iETF 52
consensus, where we agreed fid was better for it.

> sendrecv stream, even though you may only be able to send or receive

Perhaps I am being pedantic, but if I am only able to send or receive
with it, isn't it not a sendrecv codec?

Anyway, I am willing to be flexible here, but to me this is a reasonably
big change, and so I'd like to here from other folks.....

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Feb 2002 10:06:13 -0500

> So, if A can send with it, but B can't, how is this a sendrecv codec,

It is a sendrecv codec inasmuch, that if B sends an offer with this codec (as
sendrecv), it knows that A can actually support it.

> You've lost me; we are talking explicitly about the unidirectional cases

I thought you were referring to offer/answer in general. The purpose of an
offer/answer should be the same for unidirectional and bidirectional media
streams. The question in general is, if A sends an offer indicating
willingness to receive codecs 1,2, and 3, and B sends an answer omitting one
or more of these codecs, is A still obligated to receive all three codecs. I
don't see this as a unidirectional stream issue only.

> by learning that the set of things to receive is less than it needs to

There is, but in the process, we loose some abilities too. Since we could
effectively achieve the same by issuing a new offer with the "answer" set of
codecs, I'm not convinced this is a good trade-off.

> but 1.

That's where we differ - I don't think A can make that assumption.

> I had assumed that the point of the offer/answer exchange was to

> avoid that if you know that the answer defines a subset that is

We loose something in the process as described above, and hence I'm not
convinced. Also, I am concerned about deviating from "normal" SDP usage (the
way I've understood it so far at least).

> they have to be sendrecv. From the above, it sounds like you are backing

No - I'm still saying that if an agent lists a media formats listed in a
sendrecv stream then the agent must support that media format bidirectionally
(regardless of whether the context implies that it can only be used
unidirectionally). In the above example, if the (sendrecv) offer contains RFC
2833, but the answer does not, the answerer might still be able to send with
RFC 2833, but not receive it (which is why he didn't include it in the
answer).

> See above comment; I thought that we agreed that a sendrecv stream had

We still do, however whether the context in which is supplied may still lead
to it only being usable in one direction. If the context changes, then maybe
it can be used bidirectionally.

> consensus, where we agreed fid was better for it.

I believe that was different inasmuch as that was referring to unidirectional
capabilities on bidirectional streams. If I recall correctly, the fid-draft
would allow the offerer to indicate unidirectional capabilities, and have the
answerer respond accordingly. However, the answerer cannot add media streams
to indicate unidirectional capabilities in response to bidirectional media
stream.

What I am talking about is bidirectional capabilities on bidirectional
streams, however the context may imply that the flow of a particular media
format can only occur in one direction (e.g. because only the offer or the
answer contained that media format).

> with it, isn't it not a sendrecv codec?

It may only be able to be used unidirectionally in the currect context,
however if the context changes, we know that it is supported bidirectionally
(3pcc for example).

> big change,

Maybe from the current text, but the discussions we had on the previous
version of the draft at least was intended to convey the above.

-- Flemming

> and so I'd like to here from other folks.....

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 13:38:09 -0500

Flemming Andreasen wrote:

> don't see this as a unidirectional stream issue only.

That is the question, indeed. 

So, I sent private emails to a bunch of folks who I suspect have an
opinion, but who haven't been following the threads (I fear that the
huge volume that has been going on on the lists, and the fast pace, have
pushed a lot of people out of touch). All of the replies I got (about 5)
indicated that peoples interpretations had been the same as yours and
Roman's, with one person waffling a bit.

So, in the interests of progress and rough consensus, I will declare
myself in the apparent minority. I see and understand the points
Flemming is making; I don't think either side is technicall incorrect,
it is merely an issue of interpretation. I will change the text to
indicate that the offerer needs to be prepared to always receive any of
them, and that the answerer can send with ones not present in the answer
(but won't receive, obviously).

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Feb 2002 13:53:01 -0500

Sounds good - that addresses all of my comments then.

Thanks a lot for all your hard work on this.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 14 Feb 2002 15:49:36 -0500

I was trying to find a place to jump in (with all the traffic and its pace
:) but I see I'm late now.  I'll say my 2 cents anyway...

I always thought not getting an affirmative indication of what a sender will
send was a deficiency in the protocol.  For a multi-session platform that
wants to optimize its resources, this behavior is not desirable if its goal
is to try to find one format the other end supports.  In order to minimize
resource usage (i.e., not allocate DSP resources for formats that will
probably not be used in the session), I can only "advertise" what I'm
willing to reserve.  Which will be a single encoding format in almost all
cases.  I liked where Jonathan was going, but I understand consensus...

If I look at the case where a gateway can send rfc2833 and an endpoint wants
it, I would prefer to see the gateway "advertise" support with the sendonly
attribute rather than it saying nothing.

Regards,
Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, February 14, 2002 1:38 PM
> To: Flemming Andreasen
> Cc: Roman Shpount; [email-masked]; Jonathan Rosenberg
> Subject: Re: [MMUSIC] Re: Using payload types not specified
> in answer in
> offer/answer
>
>
>
>
> > I thought you were referring to offer/answer in general.
> The purpose of
> > an
> > willingness to receive codecs 1,2, and 3, and B sends an
> answer omitting
> > one

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Feb 2002 16:07:02 -0500

> cases.  I liked where Jonathan was going, but I understand consensus...

Also note, that you can achieve almost the same by issuing an updated
offer/answer with the the single codec, if that's what you want.

> attribute rather than it saying nothing.

There's only so much we can do within the existing semantics of SDP, however you
can still use the fid-draft to provide unidirectional media formats in an offer
- you just can't add it to the answer if it the offer didn't contain it.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 14 Feb 2002 18:41:42 -0500

> offer/answer with the the single codec, if that's what you want.

I shouldn't be in so much of a hurry to jump in...You're right, with an
extra message exchange I can satisfy both goals.  This will work for me.

Thanks,
Bert

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 21:34:15 -0500

I got some more responses in private, and also noodled over this some
more. I still have a queasy feeling.

The question is really fundamental. What is the "answer" in an O/A
exchange? Is it a declaration, as is the offer, which are not much
related, or is it a negotiation to arrive at agreed upon parameters? One
way to figure it out is to look at other aspects of the SDP negotiation.

Consider the a=sendrecv, a=sendonly, a=recvonly attributes. If A sends
an offer, with the stream as sendrecv, and the answer (from B) says
recvonly, here is the question. Can B now send to A? If you believe that
the directional attributes are a shared, negotiated view of the session,
which has been my interpetation, the answer is NO. This stream is from A
to B, period. If you believe that B always can do whatever is declared
to it in the offer, the answer is yes - A can receive, so B should be
able to send.

Really, the offer/answer model has some attributes which are merely
declarative (like ptime), and others which are shared and negotiated
(directionality). Therefore, the argument that SDP is always declarative
holds no ground, since I think (hope) we can agree that there are most
definitely attributes which are shared and negotiated. So, are, or are
not, codecs part of this? If the goal, in general, is for a common codec
to be used in each direction, then I think the view has to be that they
are shared. While we could just reduce the set later with an additional
offer, as Flemming has pointed out, the value that the O/A exchange
brings to the table is the ability to not need to do that. 

Thanks,
Jonathan R.

---

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

> brings to the table is the ability to not need to do that.

Actually, it doesn't. With the present O/A text, we already have to support
all codecs in the offer until we get the answer. Furthermore, since the
offerer has no control over the answer, it is quite possible that the answer
contains more than one of the offered codec, and hence we are back where we
started. The only way to get down to one codec is a new offer/answer exchange.
Thus, the above can at most be seen as a possible optimization between
offerers and answerers that both agree to pick just one codec. Since it
doesn't really solve the problem then, we loose some functionality in the
process, and we depart with what at least a lot of people had understood
(based on your earlier e-mail), we should stick to yesterday's consensus.

-- Flemming

--
Flemming Andreasen
Cisco Systems