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

On 07/21/2015 01:41 AM, Silvia Pfeiffer wrote:
>
>
> On 21 Jul 2015 1:21 am, "Roman Shpount" <roman@telurix.com
> <mailto:roman@telurix.com>> wrote:
> >
> > On Sun, Jul 19, 2015 at 3:41 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com <mailto: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.
> >
>
> 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.
>
For clarity: MIME type and parameters are not represented in RTP (that's
a protocol).

What we're discussing is how they should be represented in
RTP{sender,receiver}.getCapabilities.

> 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?
>

I think that's what *I* am proposing; others may have other opinions.
(I'm still mad at English for not having separate singular and plural
forms of "you"....)


-- 
Surveillance is pervasive. Go Dark.