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

There was previous discussion about the "kind".  My original proposal
didn't require a "kind" parameter.  But on the list, people expressed two
concerns that were left unresolved:

1.  If we don't pass in the kind, we have to have the kind on each of the
capability sub-objects (for example: codec.kind, headerExtension.kind).
That was seen as a bit too much clutter.

2.  If a header extension doesn't really apply to either or audio or video,
or applies to both, what "kind" do you put?  A blank?  Undefined?

With those two concerns in mind, passing in the kind seemed more simple:
you don't need ".kind" on the sub-objects, and it's clear that the header
extension is supported for that kind.

Are you in favor going back to my original proposal (which is more similar
to ORTC)?  Here is the original thread if you want to read it:
http://lists.w3.org/Archives/Public/public-webrtc/2014Nov/0008.html

On Sat, Jul 18, 2015 at 6:23 AM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> I don't get the need to pass in the kind at all.  Why not just return all
> the capabilities? Or pass in just the video or audio and get all the codecs
> of that type.
>
>
> > On Jul 18, 2015, at 12:17 PM, Roman Shpount <roman@telurix.com> wrote:
> >
> > On Fri, Jul 17, 2015 at 7:33 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
> >
> > > I would think that having separate codec.name and codec.mimeType
> would be the best option. Based on
> http://www.iana.org/assignments/media-types/media-types.xhtml there are
> cases when there is a mismatch between the name and the mime type, such as
> "vnd.vivo" and "video/vnd-vivo". I hope no will ever need any of those
> codecs, but theoretically it is possible.
> >
> > One piece of warning: duplicate information like this can lead to
> conflicting information orifices in the two fields. I would prefer to just
> use mime types as defined by IANA:
> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml. note
> that these are the rtp mime types, not the file mime types, which is more
> appropriate for WebRTC imho.
> >
> > I agree, redundant data can be dangerous, so only one field should be
> specified. I generally prefer to have the data parsed, so I would like to
> see separate codec.name, set just to name, and codec.kind set to "audio"
> or "video". Which brings the question, what about the extra encoding
> parameters, such as clock rates, channels, or bit rates supported? If mime
> types are used, these can be specified as mime type parameters such as
> "audio/L16;rate=16000", but analyzing them becomes even more difficult. I
> would like to see at least explicit codec.rate and codec.channel as well.
> > _____________
> > Roman Shpount
> >
>
>