Subject: RE: [MMUSIC] supporting just one codec at a time

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 4 Jan 2002 21:52:57 -0500

a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our
model nicely.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, January 04, 2002 4:47 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [MMUSIC] supporting just one codec at a time

Folks,

I've been combing through the sip-implementors and sip lists, looking 
for open issues that need resolution, or comments that needed addressing 
in the specification. This is the source of much of my spamming on 
sip-implementors....

An issue that has arisen time and time and time again, is the need for 
an endpoint to indicate in its SDP that it can do any one of these three 
codecs, but can only do one at a time, that is, it doesn't support 
dynamically changing codecs on the fly. Since the question has been 
asked 1/2 dozen times on sip-implementors, and concerns both sip and 
mmusic, I have cross posted. If the thread takes off we'll trim it to a 
single list.

The response I gave to people who asked about it, was that this was what 
simcap 
(http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx
t) 
was for, and to go read that. However, after a discussion with Flemming, 
it appears I misinterpreted that specification. It is merely a 
declaration of the codes that an endpoint can support. This information 
would be used in subsequent offer/answer exchanges, so that a UA can 
make an offer without having to guess whether it would or wouldn't be 
accepted. I was under the false impression that the point of simcap was 
to, in fact, solve this particular problem of one-codec-at-a-time for 
the initial exchange.

So, we are faced with this gap of how to handle this problem. I see a 
few solutions:

1. Use a three-way handshake in SIP, using offer/counter-offer/answer.

The offer would list ALL the codecs the UA can do, the counter-offer is 
the subset that the other UA can do, and the answer can reduce it 
further to just a few.

This solution would require us to define this 3-way handshake somewhere; 
that is still being debated as an open issue. Bill has included this 
already in manyfolks, partly to solve this problem (or maybe entirely to 
solve this problem).

2. Define a backwards compatible usage of simcap to modify the 
offer-answer exchange.

The offer would contain an m line with a single codec choice (in this 
particular case where it can do only one a time), but the offer would 
include simcap attributes indicating support for other codecs. The 
answerer could choose from amongst those codecs in formulating the 
answer. So, for example:

Offer:

m=audio 8778 RTP/AVP 0 76
a=rtpmap:76 telephone-event
a=sqn:0
a=cdsc: 1 audio RTP/AVP 0 76
a=cdsc: 3 audio RTP/AVP 1 76
a=cdsc: 5 audio RTP/AVP 2 76

This offer means that the offerer is definitely using PCMU with someone 
that doesn't understand simcap, but is indicating they can also do 
codecs 1 and 2 (and each of them with rfc2833). The answerer could pick 
one of those alternate cdsc in the answer:

m=audio 7554 RTP/AVP 1 76
a=rtpmap:76 telephone-event

We would probably need to define an additional attribute in the SDP that 
indicates that this "simcap effects the m line selection" semantic is 
being followed.

This approach may confused intermediaries that are assuming a subset of 
codecs in the answer.

3. Define a sort-of backwards compatible usage of simcap with offer/answer

In this model, the offerer lists all codecs they can do in the offer. 
They include simcap declarations as well. As with normal offer/answer, 
the answerer has to pick a subset, but they use the simcap declarations 
to help them pick a subset which is an allowed capability. So, in the 
example above where the caller can do codecs 0,2,3,4 along with 76, but 
only ONE of 0,2,3,4 at a time, the O/A would look like this:

OFFER:

m=audio 8778 RTP/AVP 0 1 2 76
a=rtpmap:76 telephone-event
a=sqn:0
a=cdsc: 1 audio RTP/AVP 0 76
a=cdsc: 3 audio RTP/AVP 1 76
a=cdsc: 5 audio RTP/AVP 2 76

ANSWER:
m=audio 7554 RTP/AVP 1 76
a=rtpmap:76 telephone-event

If, however, the UAS doesn't understand simcap, its possible that 
they'll return an SDP listing all four codecs, and possibly change them 
on the fly. That can be fixed, in general, by another re-invite which 
lists only a single codec. This will work, but might cause an RTT worth 
of media to be sent using a codec different from the one the UAC 
"loaded" into the DSP.

4. Declare that simcap is overkill for this one problem, and define a 
single attribute, a=pickone, which says to choose only one of the codecs 
in the m line.

The "I can do one of N, but only one at a time" problem, IMHO, the only 
capability problem that anyone actually has in real usage. I will note 
that, in fact, this is the only capabilities question ever asked on 
sip-implementors.

A single attribute would easily solve it. If you want to do rfc2833 
along with any one of N other codecs, you could use fid along with this, 
to include an m line with the rfc2833, and then another m line with the 
N codecs and the a=pickone attribute.

One way or another, we need to solve this problem. My apologies for 
bringing this up so late, but I had thought it was solved (I thought it 
implied approach #3 above).... comments on the various alternatives?

-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: "Mark Watson"<[email-masked]>
Date: Mon, 7 Jan 2002 15:43:57 -0000

Generalising:

a=pickn: <n> <fmt list>

meaning "pick any 'n' codecs from the list on the m= line, so long as the
ones from <fmt list> are included in that n" would allow you to encode
things like 'I support G.711 *or* G.726 and I support RFC2833 with either':

There are a bunch of other ways to specify general sub-sets of the <fmt
list>, for example a list of n-bit bit masks, where n is the size of the fmt
list etc.

I can imagine cases where a UA supports several compressed codecs, only one
at a time, but supports upspeeding to G.711 and RFC2833 with all of them.

The offer/counter-offer/answer case is always needed for whenever the UAS
does not support any new SDP attribute such as that above. In this case you
have the possibility of 1 RTT of lost media, as described below.

...Mark

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: 05 January 2002 02:53
To: 'Jonathan Rosenberg'; [email-masked]; [email-masked];
[email-masked]
Subject: [Sip] RE: [MMUSIC] supporting just one codec at a time

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Friday, January 04, 2002 4:47 PM 
To: [email-masked]; [email-masked]; [email-masked] 
Subject: [MMUSIC] supporting just one codec at a time 

Folks,