Re: [rtcweb] [tram] Payload Types assignments

"Charles Eckel (eckelcu)" <> Tue, 25 February 2014 15:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F5661A0134; Tue, 25 Feb 2014 07:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eZLkvqmBOBAB; Tue, 25 Feb 2014 07:52:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 45B911A0115; Tue, 25 Feb 2014 07:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3359; q=dns/txt; s=iport; t=1393343540; x=1394553140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ywdrgw4vIZ5CJh+M+UTi9LlzASMdLz8A7wJHnTrF7w0=; b=TngmorOE9jLH/VLo5i9k3oPEhplYHlHbC+31RjmHtAc+ZIeZYAXQz1SZ eI5Oq0e7KowqMR3ZvgU7HjEVcO0ORD3c9q33v0HQ9f39ZFHTjSPay4Owy trKPWVE2gy0fax4hAThtb9EJj2oIcFe1dmEFeU1j7k0n0VxhuNy67rxEu s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="306201743"
Received: from ([]) by with ESMTP; 25 Feb 2014 15:52:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1PFqKHL021141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 15:52:20 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 09:52:19 -0600
From: "Charles Eckel (eckelcu)" <>
To: Magnus Westerlund <>, Karl Stahl <>
Thread-Topic: [tram] [rtcweb] Payload Types assignments
Thread-Index: AQHPMgUpm6jL6hsIxEqt4QadBq4rXJrF/YCA
Date: Tue, 25 Feb 2014 15:52:19 +0000
Message-ID: <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$> <07b001ceb65f$ce3f0cf0$6abd26d0$> <07e401ceb713$bef87a60$3ce96f20$> <> <00b001cebfc1$ba8e89e0$2fab9da0$> <> <050801cec3f6$6172aec0$24580c40$> <> <02bf01cecf34$35e174a0$a1a45de0$> <04dd01cf31ad$0fe62d00$2fb28700$> <> <052e01cf31cb$5311a0a0$f934e1e0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [rtcweb] [tram] Payload Types assignments
X-Mailman-Version: 2.1.15
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, 25 Feb 2014 15:52:23 -0000

It may have been mentioned previously, but those interested in this may
well want to have a look at the following drafts being discussed on the
AEON list (

While QoS is not the sole focus of this work, it is one of the important
work flows prevalent in networks today that is more challenging in the
face of emerging communication applications such as those enabled by
WebRTC. One of the goals of the AEON effort is to provide a framework such
as the one mentioned by Magnus.
Comments on the AEON list are welcome, as is your attendance at the AEON
side meeting at IETF 89:


On 2/25/14, 12:39 AM, "Magnus Westerlund" <>

>(As individual)
>I also wish for more usable QoS mechanisms. However, I don't see that
>being achieved by your proposal. In addition I agree with Colin about
>the issues with putting the information in the RTP header extension. I
>would also note that this would be very RTP specific, and not at all
>help with the data channels multiple streams and their priorities. There
>might be data channel information that is more crucial than any of the
>RTP media stream packets.
>You are pushing for a small piece in the middle. A piece that will not
>help with the more general issue of QoS. How does the application and
>the multiple ISPs that carries the traffic reach an agreement on what
>properties that can be provided, that the application in this instance
>have the right to request those properties and that any cost is
>correctly associated with the user or the user's agent in regards to
>carrying the associated cost.
>When it comes to setting DSCP from user land in the OS, that is
>restricted due to the security implications. If those implications where
>resolved, then OS could open up those interfaces.  There are many
>interlinked reasons why things look like they do today. I don't believe
>in tugging on a single random thread in ball of yarn and hope that it
>comes out without any knots and ties on it.
>Show me the framework for the QoS functions you have in mind that at
>least has less issues than the currently deployed and take care of at
>least some of the bigger issues. If that requires information in the RTP
>streams for some reasons, then let us talk about how to best encoded it.
>But, we need that framework first, the architecture that makes this a
>better solution than the current Diffserv architecture or any other QoS
>Magnus Westerlund
>Services, Media and Network features, Ericsson Research EAB/TXM
>Ericsson AB                 | Phone  +46 10 7148287
>Färögatan 6                 | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto:
>tram mailing list