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

Christer Holmberg <> Thu, 03 October 2013 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEB2621E809C for <>; Thu, 3 Oct 2013 11:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.826
X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GWZNIfEQ9xFA for <>; Thu, 3 Oct 2013 11:44:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF67B21F8F32 for <>; Thu, 3 Oct 2013 11:35:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-02-524db8e5cfed
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 34.AD.03802.5E8BD425; Thu, 3 Oct 2013 20:35:17 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 20:35:16 +0200
From: Christer Holmberg <>
To: Karl Stahl <>, Magnus Westerlund <>
Thread-Topic: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOvpxUWC3SPyNT0EKIc+6nFGZBBpnh5LSAgAFsUHaAAABltQ==
Date: Thu, 03 Oct 2013 18:35:16 +0000
Message-ID: <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$> <07b001ceb65f$ce3f0cf0$6abd26d0$> <07e401ceb713$bef87a60$3ce96f20$> <>, <00b001cebfc1$ba8e89e0$2fab9da0$>
In-Reply-To: <00b001cebfc1$ba8e89e0$2fab9da0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B3CFAESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvre7THb5BBkufKFhsvjmJ0eJdz1o2 i7X/2tkdmD2WLPnJ5PFp63wWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZbzc8pel4JhfxfTebYwN jPsduxg5OSQETCTurf/KCGGLSVy4t56ti5GLQ0jgMKPE0dUvWCGcxYwSG26fYu5i5OBgE7CQ 6P6nDWKKCMRKnDtgCFLCLLCCUaLp/VwWkEHCAhESrxbtBrNFBCIlTh89xAphO0lcfrSSGcRm EVCRaJu+BizOK+Ar8erlPKjFq5klJj4+BtbMKeAg8fn1WXYQmxHouu+n1jCB2MwC4hK3nsxn grhaQGLJnvPMELaoxMvH/1ghbEWJq9OXQ9XnS9x7+YIFYpmgxMmZT1gmMIrOQjJqFpKyWUjK IOJ6EjemTmGDsLUlli18zQxh60rM+HcIqsZaYua5bhZkNQsYOVYxsucmZuaklxttYgRG4MEt v1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjK795rlxSyzO 123iNnCf9+sEY9X1HNYG9owF9WudvxWI7Dv0OiAzMTn4u3p/5QIT3612hWv8HYza/73YcTr9 mOiXnc5K39I+XlI/nv6JW2nysrjUwvzLwnE8gSIdf+0Z+b5OeWJuu+7fh52HOhvW1xx76X2/ Werw8bLEZ40/3Hvfnfg9932tlhJLcUaioRZzUXEiAGp7RPuOAgAA
Cc: "" <>, "" <>
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: Thu, 03 Oct 2013 18:44:48 -0000


I believe this discussion is outside the scope of the WGLC of draft-ietf-rtcweb-use-cases-and-requirements, so I would suggest changing the subject.




From: Karl Stahl []
Sent: Thursday, 03 October 2013 1:50 AM
To: Magnus Westerlund
Subject: SV: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

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.