Re: Proposal and discussion for RtpSender.getCapabilities

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