Hi there,
After I read the simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx
t), I found that it is not backwards compatible with the SDP (RFC 2327).
Here's my comments.
1. the rtpmap's format in RFC 2327 is
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>].
While in simcap, it is :
a=rtpmap:<payload type> telephone-event
Where is the "telephone-event" defined as an encoding name? If the UA is
implemented according to RFC 2327, how can it talk to the UAs implemented
according to the simcap?
2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the
media attributes already. I don't know why it is necessary to define a new
attributes of "a=cdsc" and "a=cpar". There are some redundant information
here, I think.
3. If we want to describe a subset of capabilities among all capabilities
the SDP claimed, we can simply introduce one new attribute to describe the
subset. For example,
a=subset subset_codec_number : total_codec_number.
This way, even some UAs don't understand a = subset, they still can talk
with the one supports this attribute by at list one media streaming.
Here's an example:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=subset 2:3
m=video 3458 RTP/AVP 26 31
a=rtpmap:26 JPEG/90000
a=rtpmap:31 H261/90000
a=subset 1:2
This packet means the sender can support two audio streams among three
different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or
H261.
Above all, it is not a good idea to introduce new headers only if 1)
backwards compatible, 2) really necessary and can solve problems, 3) easy to
implement.
Thanks,
Jerry Yin
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan
> Rosenberg
> Sent: Friday, January 04, 2002 4:47 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Sip-implementors] 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-sd
> p-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
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
