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:15:42 -0400
Message-ID: <CAD5OKxv=Oh-UACB4bHShKRzTcd_WHPWeoPv8hAVnVod9B4cPUw@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Luis López Fernández <luis.lopez@urjc.es>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
I think I need to clarify my point:

I would prefer to see all the fields necessary to produce or match SDP
explicitly broken out. For this purpose, we need to specify:
1. kind -- "audio"/"video". If getCapabilities("") returns a single list of
codecs, we need to know which one is which
2. name -- "vp8" or "opus" or other. This is the payload name used in SDP
3. rate -- rate parameter in SDP. In cases like CN ot telephone-event, I
would expect to see multiple codec entries with the same name and different
rates, i.e one CN entry for rate 8000 and another for rate 48000
4. channels -- empty, 1 for things like G.711 and 2 for Opus. In the future
we might add support for more channels.
5. parameters -- this can be a DOMString with the default values for all
the parameters, the way they are used in SDP. It can also be a dictionary.

If getCapabilities provides any less information, it cannot be converted
into SDP without some additional lookup tables.

An alternative would be to provide all this data as a single mime type
string like this "audio/opus;rate=48000;channels=2;stereo=1;useinbandfec=1",
but this will require an additional parser to convert this string into
something that can be used in SDP. Not the worst thing in the world, but
would require most people who use it to write yet another parser.

Regards,
_____________
Roman Shpount
Received on Monday, 20 July 2015 15:16:12 UTC

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