Re: [rtcweb] [tram] Payload Types assignments

Magnus Westerlund <> Tue, 25 February 2014 08:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 200EA1A0384; Tue, 25 Feb 2014 00:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10tJQJVH8LUO; Tue, 25 Feb 2014 00:39:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C61F81A0329; Tue, 25 Feb 2014 00:39:43 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-29-530c56ce195b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 17.6E.10875.EC65C035; Tue, 25 Feb 2014 09:39:42 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 09:39:41 +0100
Message-ID: <>
Date: Tue, 25 Feb 2014 09:39:41 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Karl Stahl <>
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: <052e01cf31cb$5311a0a0$f934e1e0$>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje65MJ5gg+P7ZSze9axls1j7r53d 4sPaC2wOzB5Llvxk8vi0dT5LAFMUl01Kak5mWWqRvl0CV8bDK1wFTwQrLvYfZ25g3MzXxcjJ ISFgIrHh9BIWCFtM4sK99WxdjFwcQgKHGCWenDnBDOEsB3L+b2IDqeIV0JY4f2ApO4jNIqAq 8eTUJEYQm03AQuLmj0awGlGBYImdB34zQtQLSpyc+QRsg4iAusS086fAapgF1CQmfbwPNkdY wEri0af1LBDLnrJKfJ8+lRkkwSngIPH0/wqgIg6g88QlehqDIHr1JKZcbWGEsOUlmrfOBisX ArqtoamDdQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAoD245bfuDsZT50QOMUpzsCiJ 83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH4tZyf+qyPsgf1D3Mq1HUprJ5pFF69 5JPq5EnHuoXONc2dVn3kz/QLqv9ldL8c4WoN4SheVq5oX+/XunR1c1NUmX7p8+xXizfNmi1i VWVmILKHcbqbFvv7vYfNu1KZTrGVCD4ovmLyuECt6ODbhwJliuumCq91cIjXKZu/5dXqZTtf H/bS2K7EUpyRaKjFXFScCAAmPveOKAIAAA==
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 08:39:46 -0000

(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: