W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: I have created a PR for RtpSender.getCapabilities and RtpReceiver.getCapabilities

From: Roman Shpount <roman@telurix.com>
Date: Mon, 20 Jul 2015 11:21:12 -0400
Message-ID: <CAD5OKxvT38k-iwzC_Ov4=DQY2DhVQKk+J9VnCfFWnPLtLmCkjg@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: public-webrtc <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
On Sun, Jul 19, 2015 at 3:41 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
wrote:

>
> I'd suggest just going with a single mime type field to avoid having
> to deal with all these issues. Mime type is defined as a single string
> that a lot of things already understand and parse - ripping the bits
> of the mime type field apart just means that for some things you have
> to put them back together again and that seems more effort than it's
> worth. For example, most mime types won't have a rater and a channel -
> how are you going to fill these fields sensibly then? If you fill them
> from some other information, how are you going to put the original
> mime type field back together again?
>

Every SDP media line has rate and audio lines have channels. The fact that
the browser supports L16 can mean that it supports L16 at 8KHz and 16Khz or
it can mean something else. Without the rate and channel information codec
capabilities cannot be serialized into SDP.

P.S. All RTP mime type have a rate. Some support multiple, and do not list
the default rate in the
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml. These
are exactly the codecs for which rate is required in getCapabilities result.

Regards,
_____________
Roman Shpount
Received on Monday, 20 July 2015 15:21:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC