Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Magnus Westerlund <[e-mail]>]

Hi Karl,

I just want to provide a comment on your below suggestion.

On 2013-09-21 23:44, Karl Stahl wrote:
> Yet another thing related to
> draft-ietf-rtcweb-use-cases-and-requirements-11:
> It is about payload type, PT=, in SDP and RTP, so I am copying MMUSIC
> 
> Network service providers have expressed an interest to know whether packets
> carry audio or video, to be able to handle them differently in the network
> (e.g. quality wise). PT is visible outside the encrypted payload in RTP,
> however if dynamic payload types PT:96-127 are used, you cannot know what
> the payload is without knowledge of the SDP (which we for WebRTC must assume
> the network provider has no knowledge of).
> 
> In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I see
> no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC.
> 
> So, can we have payload types assigned to codecs that will be recommended
> for WebRTC (PT:35-71 are unassigned)?

And this is because over 10 years ago we (IETF) stopped assigning static
payload types, actually forbid future static assignments. All payload
types are assumed to be dynamically assigned in RTCWEB. The reason is
that we have more codecs and codec configurations than there is PT space.


> Or can we at least split dynamic payload types PT:96-127 into groups for
> audio and video codecs?

That assumes that one understand how many of each there is going to be.
You also have the supplemental payload types, like RTP Retransmission
that has a one to one binding with another payload type in the RTP
session. So how should one do this split without being significantly
restricted in how you use the payload type space. I personally see that
the 96-127 space will be insufficient in quite many cases due to the
combination of supporting a number of audio and video codes combined
with retransmission and FEC.

I don't really dare doing a split, as I would have to live with it for
the foreseeable future, and it would inevitable be wrong.

Cheers

Magnus