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

Magnus Westerlund <> Tue, 01 October 2013 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59FA321F93E1 for <>; Tue, 1 Oct 2013 04:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.598
X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q98Atuh5HaVG for <>; Tue, 1 Oct 2013 04:49:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFBC921F9F9D for <>; Tue, 1 Oct 2013 04:49:46 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-a0-524ab6d92d5e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 14.96.03802.9D6BA425; Tue, 1 Oct 2013 13:49:45 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Tue, 1 Oct 2013 13:49:45 +0200
Message-ID: <>
Date: Tue, 01 Oct 2013 13:51:12 +0200
From: Magnus Westerlund <>
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 <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$> <07b001ceb65f$ce3f0cf0$6abd26d0$> <07e401ceb713$bef87a60$3ce96f20$>
In-Reply-To: <07e401ceb713$bef87a60$3ce96f20$>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7NbV5BBi8OKFhsvjmJ0eJdz1o2 i7X/2tkdmD2WLPnJ5PFp63wWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZbybdpaxYKJAxcQNC5ka GP/zdDFyckgImEicWryRHcIWk7hwbz1bFyMXh5DAYUaJJfOmM0I4yxglbi65xAhSxSugLTHz RRMTiM0ioCJx58oGMJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfsIDYIgLqEtPOnwKLMwuE Sfw5tAMsLgxkN387AbXsNJPEm93HWEESnAIOEudWLoM6T1Ji26Jj7BDNehJTrrYwQtjyEtvf zmEGsYWAjmto6mCdwCg0C8nuWUhaZiFpWcDIvIqRPTcxMye93GgTIzCED275rbqD8c45kUOM 0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgNO+W3/TK9JP7EY/lvy/6m7YI a7ifjC5ZsPTxJqez/RJZa//rqaQ1yNe7uc7nMFP/nWL08ULhl4hfS5Zw7P/rwR9QcVhoFVeY UHqe5Yyzgs58k1OctW+rTSmZm2oXHS3YOmPK7MdyFo7zbrWIxD8W/XyKYUJr6e/rOllvf/FI rVj6WEoodt4yJZbijERDLeai4kQADPE47y8CAAA=
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: Tue, 01 Oct 2013 11:49:52 -0000

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 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 (PT:35-71 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.