Jonathan Rosenberg wrote: > 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. simcap is indeed overkill for this and I like new attribute as long as we relax the requirement currently in offer-answer: "Once the offerer has sent the offer, it MUST be prepared to receive media described by that offer." If this is not relaxed the offerer cannot know which of the list of codecs to receive with and may not be able to listen with all of them until receiving the answer. Of course simcap can still be used in addition to this to indicate media that can be supported but not initially opened (e.g., rfc2833). > > > 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 > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- ------------------------------------------------------------ Terry L Anderson mailto:[EMAIL PROTECTED] Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:[EMAIL PROTECTED] title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard
