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

From: "Sanjoy Sen"<[email-masked]>
Date: Mon, 18 Feb 2002 17:15:04 -0600

Jonathan,

   We at Nortel (that includes at least four of us including a codec expert)
support the second option, i.e., "NO". The primary reason is the #3 reason
that you've - we would like to have the possibility of narrowing down to one
codec without the overhead of an extra roundtrip (O/A exchange). Also, its
not clear to some of us how would you negotiate the attributes that're
associated with the media session (e.g., security parameters). Example,
suppose Offerer sends 3 codecs - 2,3,4 and the answerer responds with 3,4
and adds an a=keymgmt-data: attribute for this media, should the offerer be
ready to accept 2 with the security keys applied?

Thanks,
Sanjoy

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 3:32 PM
> To: [email-masked]
> Subject: [MMUSIC] summarizing discussion on codec placement in answer
> 
> 
> 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: Roman Shpount <[email-masked]>
Date: 19 Feb 2002 00:49:09 GMT

Sanjoy Sen wrote:

> Also, its not clear to some of us how would you negotiate the 
> attributes that're associated with the media session (e.g., security 
> parameters). Example, suppose Offerer sends 3 codecs - 2,3,4 and the 
> answerer responds with 3,4 and adds an a=keymgmt-data: attribute for
> this media, should the offerer be ready to accept 2 with the security 
> keys applied?

I have a related question: How would the same security parameter negotiation work with early media?
___________________________________
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: "Even, Roni" <[email-masked]>
Date: Tue, 19 Feb 2002 12:17:31 +0200

Hi,
I would vote for the No. My reasons are that I would like to distinguish
between symmetric codecs and non symmetric codecs. I would use the sendrecv
if I want symmetric codecs and use recvonly and sendonly if I want non
symmetric codecs. The reasons for the different modes is that I may be an
MCU that needs the video streams to be symmetric or a terminal that cannot
decode one video algorithm and encode another. Point 3 in the no is very
important.

Roni Even
Polycom

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, February 15, 2002 11:32 PM
To: [email-masked]
Subject: [MMUSIC] summarizing discussion on codec placement in answer

Folks,

hopefully invite some further comment from folks outside the few thread

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:

Codecs fit into that category as well, since you are already required to

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.

THanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Feb 2002 01:43:24 -0500

> > this media, should the offerer be ready to accept 2 with the security

That just doesn't work.

My understanding of the a-keymngmt-data attribute is that it is a tunnel
for mikey. MIKEY, as I understand it, requires a two pass exchange.
Thus,
you would have to have this attribute in the offer and the answer for
this
to work.

The a=keymngmt-data attribute is hardly a normal session attribute, for
this reason. As far as other attributes are concerned, some may be
negoiated (like the directional ones), and others are merely declarative
(like ptime) such that there is no relationship between the values in
the offer and the answer. I think the current o/a doc points this out.
There is no general way to know which case it is for a particular
attribute.

> negotiation work with early media?

No different! Thats the entire idea behind the unify proposal. With
unify, early media is just an O/A exchange that finishes before the sip
invite transaction does. Since mikey will work by embedding in any O/A
exchange, as far as I can tell, the fact that the exchange is before the
sip transaction is completed is totally irrelevant. Please do read the
unify draft:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-unify-00.txt

-Jonathan R.