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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
