Subject: RE:[MMUSIC] Mulit-codec Response Offer/Answer Issue

From: "William Janning"<[email-masked]>
Date: Sat, 23 Feb 2002 08:26:26 -0600

This is re: Jonathan Rosenberg's question on codec selection. This may be a
double post (I'm not sure it got through the first time)
 
-----------------------------------------------
 
NO is definitely the answer. 
 
When "A" sends a request with SDP, it is saying "I CAN do 1,2,3". When "B"
responds, it is saying "I WILL do 1, 2, or 3". In reality it makes no sense
for "B" to respond with "I WILL do 1 and 2" as practically speaking this
would mean B could dynamically switch between receiving codec 1 or 2 at the
whim of A, or that B would be able to properly mix 1 & 2 to the transducer.
If this is negotiation, then let us CHOOSE.
 
There is an assumption in codec selection that the codec "B" elects to
receive is also the one it is sending (so it must pick from "A"'s initial
list). This is implied in the SDP protocol because a single media
description only negotiates a single codec - there is not provision to
identify the send codec from the receive codec. This fact and the above
practicality are why NO is the answer with even additional restrictions (B
should never reply with multiple codecs). 
 
Supporting the codec capability preference for a particular session for
clients is completely related to bandwidth management and perceived voice
quality - though mostly bandwidth management. If everybody could do G711 or
G722, then they would. Period. So if I say I will receive G729, then there's
no way I'm going to send G711 or even G723. Likewise I can't say I'll
receive G711 (because I have higher download bandwidth) but send G729
(because my upstream is limited). "A" would have no clue I'm doing so
because all I replied in my response was G711. 
 
There is no such thing as a "send only" or "receive only" codec - codecs
always support both encoding/decoding. However if I did want to specify
unique send and receive codecs, then the use of two media descriptions could
be used as such:
 
v=0
o=user 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=recvonly
m=audio 9902 RTP/AVP 4 18
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=ptime:10
a=sendonly

I would argue that the attributes "sendonly, recvonly, sendrecv" are
MANDATORY in messages and reflect the "I WILL" versus "I CAN", though the
difference is also identified by "response" versus "request" message. If the
originator wanted to tell the far-end that it was receiving already in the
request, then it MUST use the recvonly attribute (though this is a security
risk - since the originator doesn't know who the far-end is supposed to be,
anybody can be sending the originator packets which they'd happily play
until the real far-end answers (assuming of course there was no early media
established like on a 183). 
 
In order to really handle multiple m= lines with the same media type,
something like s= lines should also be per media description (or another
field added to the m= line to uniquely identify the media description). This
would eliminate m= ordering requirements and facilitate better renegotiation
management. Maybe FID helps here (I need to understand the purpose of FID
better). 
 
---------------------------------------------------

Arguments for YES: 

1. A needs to be prepared to receive with codec 3 once it sends the 
offer anyway. 

It is a security risk for A to receive RTP before it knows about the
far-end. "A' should not receive anything until it receives an SDP response.
A should not "play" received RTP unless it comes from the address indicated
in the far-end's media description (one reason why c= lines should always be
per media description, not session description). 

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. 

B can do likewise. Once the Offer-Answer completes, SDP is set until another
Offer-Answer is initiated by either side.

3. SDP has always been interpreted as indicating your own capabilities, 
and is therefore an "advertisement" that sticks until updated. 

We must clearly delineate when we are broadcasting our capabilities versus
when we are choosing for session establishment. At some point in time we
have to CHOOSE. Advertising your capabilities should be done via some other
mechanism like OPTIONS.

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. 

Either : a) secondary codec's are uniquely flagged in the media description
for a specific purpose (like 2833), b) multiple m= lines are used and the
response is allowed to negotiate in capabilities which would then be
responded to in the ACK. For instance:

Request :

v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 4 18 0
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=ptime:30

Response :

v=0
o=user2 13723311241683545 13723311241683545 IN IP4 192.168.0.2
s=session1
p=+user2
t=104100452 0
m=audio 9800 RTP/AVP 0
c=IN IP4 192.168.0.2
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 192.168.0.2
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=recvonly

ACK :  (Really just necessary to confirm the change

v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 0.0.0.0
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=sendonly

The latter choice is good in that it can be used for other things as well
(e.g. the term party could negotiate in video without having to generate
another Offer/Answer exchange) . This would also support the conference
server case where it would like to negotiate a separate return stream (e.g.
G729 in, G711 out).
 
William Janning
Nortel Networks 
[email-masked] <mailto:[email-masked]> 
sip:billj@ <mailto:sip:billj@sipfx .com> sipfx .com

-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH] 
Sent: Monday, February 18, 2002 11:52 AM
Subject: FW: [MMUSIC] summarizing discussion on codec placement in answer
Importance: High

Do we've any opinion on the interpretation of the ANSWER in the SDP
Offer/Answer model (please read Jonathan's email below)? I would
particularly appreciate some feedback from our codec experts.

Sanjoy 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<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 <http://www.jdrosen.net>                   PH:  (973)
952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  

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