Subject: [MMUSIC] summarizing discussion on codec placement in answer

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2002 16:31:41 -0500

Folks,

I wanted to take a moment to summarize where we were in regards to our
long thread on interpretation of the codecs in the answer. The purpose
of the summarization is to put all the points on the table, and
hopefully invite some further comment from folks outside the few thread
participants in the few days which remain.

ISSUE:

A sends an offer to B. That offer, for example, is for a single sendrecv
media stream, which lists codecs 1,2 and 3. The answerer, B, responds,
and lists codecs 1 and 2. Now, the question is this: can B still send to
A using codec 3? Related to that, can B add codecs in the answer, which
A can then send with?

Arguments for YES:

1. A needs to be prepared to receive with codec 3 once it sends the
offer anyway.
2. If A wants to restrict the set based on the answer, it can always
generate a new offer with a reduced set of codecs.
3. SDP has always been interpreted as indicating your own capabilities,
and is therefore an "advertisement" that sticks until updated.
4. There are useful cases for adding codecs in the answer, particularly,
support for rfc2833. Thus, lets say A is an end user which can send rfc
2833, but not receive it. So, when it sends an INVITE, it doesn't
include rfc2833 in the INVITE. The server that responds is a media
server, which supports rfc2833. So, it includes it in the answer. Now, A
can actually send with it during the middle of the session, and it will
never receive it (since it didn't advertise it). This provides a useful
function that would otherwise require FID.

Arguments for NO:

1. The purpose of the O/A model is to agree on shared views of certain
session parameters, such as the directionality (send/recv/sendrecv).
Codecs fit into that category as well, since you are already required to
indicate, in the answer, a set that partially overlaps with the offer.
Furthermore, the goal with codecs is to have the same in both
directions, generally, so that this would speak to them being a shared
state that is negotiated.

2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If
you go for YES, there may be interop issues. The converse is not true,
of course.

3. It is very useful to narrow down the codec sets in the answer, and we
should not always require an extra exchange of O/A just to do that.

I took a private poll amongst some implementors. The initial results
showed that most assumed the YES case. Some more mails since then
indicate its a bit more split, although I think somewhat in favor of YES
still.

I am somewhat on the fence; I think NO is more correct based on
offer/answer, although YES would be the SDP purist view. What I really
want is more opinions on this one....

THanks,
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: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 16:57:52 -0500

> you go for YES, there may be interop issues. The converse is not true,

On the contrary. Consider the offerer sending codec 1, 2, 3 based on the
"NO" interpretation, and the answerer sending back codec 1, 2 based on the
"YES" interpretation. Regardless of which interpretation you pick, you can
get into trouble when trying to interoperate with the other.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Bert Culpepper" <[email-masked]>
Date: Fri, 15 Feb 2002 17:27:42 -0500

I think your YES points are currently allowed by rfc2543 and rfc2327.
However, I'd like the changes as suggested by your NO points.  But I see
these as changes and likely to require changes in some implementations.
(Again, I'd like to deprecate sending codecs not "declared" by the sender.)

Regards,
Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Friday, February 15, 2002 4:32 PM
> To: [email-masked]
> Subject: [MMUSIC] summarizing discussion on codec placement in answer
>
>
> Folks,
>
> A using codec 3?
> Related to that, can B add codecs in the
> answer, which
> A can then send with?
>
> Arguments for YES:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 04:02:01 -0500

Well, the time has arrived for me to make a judgement call, and put some
text into offer/answer.

I think a sensible approach is a compromise. I phrased the question

> A using codec 3? Related to that, can B add codecs in the answer, which

There are two questions in there. I had assumed that both needed the
same answer, but they don't. Most of the advocates of NO want it because
of the first question (narrowing down the set). Most of the advocates of
YES wanted it because of the second question. So, let us do both. NO to
first, YES to second. This is actually consistent; the consistency is
that the answer contains the final set, whether it be a larger or
smaller one.

Specifically, for a sendrecv stream, the answerer MUST NOT send using
any media formats not present in both the offer and answer. It MUST be
prepared to receive with any codecs in the answer. The offerer MUST NOT
send using any media formats not present in the answer, and it MUST be
prepared to receive using any media formats in the offer which were also
in the answer.

Similarly, for an sendonly offer, the answerer can add media formats to
the answer (or put fewer).

For a recvonly offer, the answerer cannot add any formats (it makes no
sense).

This is not set in stone; there is the opportunity to modify this during
IESG last call, but it seems a reasonable compromise position.

Thanks,
Jonathan R.