Re: Proposal and discussion for RtpSender.getCapabilities

> On 27 Nov 2014, at 14:13, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 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)

IIRC, it can be used sync for A/V sync, mainly when frames are represented by time codes.

> 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)
> 

Firstly, the mappings are not really documented anywhere, except evident from the fact that audio and video appear in the URI.

> 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:42:56 UTC