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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 07 October 2013 08:37 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28BDA21E819A for <rtcweb@ietfa.amsl.com>; Mon, 7 Oct 2013 01:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.88
X-Spam-Status: No, score=-104.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QODZoLEMaUaf for <rtcweb@ietfa.amsl.com>; Mon, 7 Oct 2013 01:37:15 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 775D521E819E for <rtcweb@ietf.org>; Mon, 7 Oct 2013 01:37:14 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-d9-525272b9fcd4
Received: from ESESSHC004.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9D.3B.03802.9B272525; Mon, 7 Oct 2013 10:37:13 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 10:37:12 +0200
Message-ID: <525272E8.5050300@ericsson.com>
Date: Mon, 07 Oct 2013 10:38:00 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Karl Stahl <karl.stahl@intertex.se>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se>
In-Reply-To: <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7OoqAggwmvJS0235zEaPGuZy2b xdp/7ewOzB5Llvxk8vi0dT6Lx5fLn9kCmKO4bFJSczLLUov07RK4MvoPX2MuOChVMWvReaYG xk2iXYycHBICJhJ9pw+zQNhiEhfurWfrYuTiEBI4zChxdOY9JghnGaPEuqUHmEGqeAW0Jf4/ OsAKYrMIqEj8WXEdrJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfgNWICKhLTDt/CizOLBAm 8efQDrC4sEC1xP8/j5ghls1nluh9uoIdJMEp4CDx+fVZdojzJCW2LTrGDtGsJzHlagsjhC0v 0bx1NthxQkDHNTR1sE5gFJqFZPcsJC2zkLQsYGRexciem5iZk15utIkRGMIHt/xW3cF455zI IUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOvHp7C3+enoCp3xGxT9xb u2SV3jAePlufcWcve+x5lsBnS6f7aLVd/s387mqgCOe2LMbLt0o/fao4+3b+Qs2wF5cUenL8 rpVosgntW6qb8uPBumuGGimfA5dJ/3rpJmBtvnFnxr2/s7iyBQtuBPbs9GFbM3NK59GFpu5b 77JwL5fxrmyZZaumxFKckWioxVxUnAgAk7KaLS8CAAA=
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 08:37:25 -0000

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.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com