a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our model nicely.
-----Original Message-----
From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 04, 2002 4:47 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
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.txt)
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 PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
mmusic mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/mmusic
