W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2014

Re: Proposal and discussion for RtpSender.getCapabilities

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 27 Nov 2014 13:13:47 +0100
Message-ID: <5477157B.6060504@alvestrand.no>
To: public-webrtc@w3.org
Den 27. nov. 2014 11:35, skrev Peter Thatcher:
> If a header extension can be used for both audio and video, I think that
> would be two different capabilities, and could be represented as two
> different RTCRtpHdrExtCapability objects:  one for each kind.  

I think I'll have to step back a step here.... what is the point of
RtpSender.getCapabilities()? What action is a client expected to take
based on information returned from it?

If the client needs to understand the actual extension in order to make
use of it, the "kind" field is useless. If it doesn't - what does it
need to do?

Note about which extensions exist:

The mechanism uses URIs, so registration is not required, but the
registrations so far are:

urn:ietf:params:rtp-hdrext:toffset (any)
urn:ietf:params:rtp-hdrext:smpte-tc (video, I think)
urn:ietf:params:rtp-hdrext:ntp-64 (any)
urn:ietf:params:rtp-hdrext:ntp-56 (any)
urn:ietf:params:rtp-hdrext:ssrc-audio-level (audio)
urn:ietf:params:rtp-hdrext:csrc-audio-level (audio)
urn:ietf:params:rtp-hdrext:encrypt (any)
urn:3gpp:video-orientation (video)
urn:3gpp:video-orientation:6 (video)

So in registration counts, the ones that apply to any type (4) outnumber
those that only apply to audio (2) and video (3).
Received on Thursday, 27 November 2014 12:14:28 UTC

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