Jonathan, Regarding your (rhetorical?) question, "The rfc2833 could be on the same port, no?", there is no SHALL in the statement, but it sounds like RFC 2833 packets are intended to always be on the same port as the audio stream:
3.1/RFC2833: "DTMF digits and named telephone events are carried as part of the audio stream..." Paul Long ipDialog, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 08, 2002 11:10 PM To: Flemming Andreasen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Flemming Andreasen wrote: > >>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: >> > > That's a slight overloading of the simcap semantics which doesn't define > any kind > of grouping of capabilities. Normal usage of simcap would only list a > given > capability once (per media stream at least). If you wanted to express > something > like the above, you would really want to define a new attribute that > could > describe allowable combinations of codecs, however that level of > expressiveness > was outside the scope of the simcap specification. I understand that now as well, once again, my misinterpretation of the simcap spec. Clearly I thought it was solving something that it is not. This leaves a larger hole than I thought. >>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. >> >> > > However that would require use of multiple ports which could lead to > multiple > resource reservations. Why? The rfc2833 could be on the same port, no? >Also, > - fid cannot be added by the answerer if the offer didn't include it due > to the > media stream matching rules Correct. That seems less of an issue, since if the offerer lists everything it can do, and the answerer is constrained, it can simply select one codec. > - if fid is included in the offer, but not supported by the answerer, > the handling > may not be all that graceful. Right. I am not wed to this specific mechanism. However, from my hopefully-now-correct understanding of simcap, it seems that it simply doesn't help at all with this issue of doing only one codec at a time. So, options 1 and 2 above are no-go. Another possibility is to add an extension to simcap which allows you to convey this one particular constraint. -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
