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

On 21 Jul 2015 1:21 am, "Roman Shpount" <> wrote:
> On Sun, Jul 19, 2015 at 3:41 AM, Silvia Pfeiffer <> 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 These
are exactly the codecs for which rate is required in getCapabilities result.

OK, what we're struggling with then is that the mime type and params in rtp
are represented as a single string while in sdp they are in different
fields. In the api we should pick one representation only to expose both.
I'm all about consistency. It sounds like some parts are best parsed out
while the rest ends up in a params string. Is that what you are proposing?

Received on Monday, 20 July 2015 23:42:04 UTC