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

["Karl Stahl" <[e-mail]>]

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

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

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

/Karl

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[e-mail]] 
Skickat: den 1 oktober 2013 13:51
Till: Karl Stahl
Kopia: [e-mail];
[e-mail]
Ämne: Re: [rtcweb] [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

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