[rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Magnus Westerlund <[e-mail]>]

Hi Karl,

On 2013-10-03 00:50, Karl Stahl wrote:
> Hej Magnus,
> 
> Hmm, if we (IETF) allowed ourselves to each decennium allocate payload types
> for the 3-4 most common/important codecs, the unassigned pool (PT:35-71)
> would last 100 years! I think our own Opus, H.264, and maybe some mobile and
> the Skype codec (SILK) could be honored AND of course the mandatory video
> codec that will be selected for WebRTC (VPx or H.26y).

Yes, but we already today have at least 126 media type names registered
that has RTP Payload formats. Out of these a significant number do
requires additional parameters, like H.264, AMR, i.e. one media type may
not represent one interoperability point but many.

Thus static assignment of codec plus parameters are totally out of the
question. We also have various different usages and none includes all
the available media types, if they would, we already now would have run
out of RTP payload types.

> 
> The need for assigning new payload types may have been small - dynamic
> payload types works equally well - EXCEPT for the quality routing reason.
> (RSVP quality type of networks could at least know maximum bandwidth. DPI
> guesswork could/should be avoided.) So with WebRTC, expecting to finally
> bring us beyond POTS quality on a massive scale - we (IETF) may
> reconsider...

IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field. If you argument is that it is
difficult to agree on mapping between media types and quality to static
value being used everywhere, the same applies to RTP level. You will not
be able to make legacy abide any static assignments. So you will see
voice in the video class etc and vice versa.

> 
> If that really is impossible, is there anything stopping _the RTCWEB RFC_ to
> recommend (MUST or SHOULD) specific _dynamic_ payload types to be used for
> e.g. Opus:PT=111, H.264:PT=112, VP9:PT=113 etc.? That may be good enough,
> and surely others, like SIP-client, would follow this usage (or add it to
> their recommendations).

What would you gain if you can't rely on the PT value being used for the
defined usage. In general you will see other IP/UDP/RTP flows with
PT=111 that will be H.264, or MPEG-2 or what ever.

Also, are you really interested in knowing that it is VP9 vs H.264,
isn't the questions this is video of this priority that is important?

I think you need to more carefully consider what are the goals you try
to achieve them. What layer do you want to achieve them at. Who are
going to react to you information and how can one trust it across
administrative boundaries. Also what scope for this information are you
trying to achieve, full end to end, only first two hops?

This is a difficult issue with no good solutions. A restricted problem
may be possible to solve, a larger one may not be realistic.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------