- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 21 Jul 2015 09:41:31 +1000
- To: Roman Shpount <roman@telurix.com>
- Cc: Peter Thatcher <pthatcher@google.com>, public-webrtc <public-webrtc@w3.org>
- Message-ID: <CAHp8n2mgH_85V13tHNe8xYXLnvpW611eTPaCNCvhKZD0aeKdZg@mail.gmail.com>
On 21 Jul 2015 1:21 am, "Roman Shpount" <roman@telurix.com> wrote: > > 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. > 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