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

"Karl Stahl" <> Wed, 02 October 2013 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A33EE21F9A61 for <>; Wed, 2 Oct 2013 15:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 60tAemuOCujJ for <>; Wed, 2 Oct 2013 15:50:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2B04021F9DC7 for <>; Wed, 2 Oct 2013 15:50:02 -0700 (PDT)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201310030049588596; Thu, 03 Oct 2013 00:49:58 +0200
From: Karl Stahl <>
To: 'Magnus Westerlund' <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$> <07b001ceb65f$ce3f0cf0$6abd26d0$> <07e401ceb713$bef87a60$3ce96f20$> <>
In-Reply-To: <>
Date: Thu, 03 Oct 2013 00:50:01 +0200
Message-ID: <00b001cebfc1$ba8e89e0$2fab9da0$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6+nFH8CL2Yst2HTRSvKXyZPyqIGgBIBUtA
Content-Language: sv
Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Oct 2013 22:50:41 -0000

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

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


-----Ursprungligt meddelande-----
Från: Magnus Westerlund [] 
Skickat: den 1 oktober 2013 13:51
Till: Karl Stahl
Ämne: Re: [rtcweb] [mmusic] WGLC of

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