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

Harald Alvestrand <harald@alvestrand.no> Fri, 11 October 2013 11:05 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470F921E81C2 for <rtcweb@ietfa.amsl.com>; Fri, 11 Oct 2013 04:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWPamAlxOnfy for <rtcweb@ietfa.amsl.com>; Fri, 11 Oct 2013 04:05:36 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBC21E813A for <rtcweb@ietf.org>; Fri, 11 Oct 2013 04:05:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5848E39EA0A; Fri, 11 Oct 2013 13:05:28 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4VcEpLsl1ml; Fri, 11 Oct 2013 13:05:27 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5DF1339E04C; Fri, 11 Oct 2013 13:05:27 +0200 (CEST)
Message-ID: <5257DB76.7000200@alvestrand.no>
Date: Fri, 11 Oct 2013 13:05:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: BeckW@telekom.de, ted.ietf@gmail.com
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <AAE428925197FE46A5F94ED6643478FEAD1BDC6F0B@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CA+9kkMDo2zu12qLfEeSC2YFaEeK-LbZ4JTDJiG8zfktBb-iB2A@mail.gmail.com> <AAE428925197FE46A5F94ED6643478FEAD1BDC7177@HE111644.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <AAE428925197FE46A5F94ED6643478FEAD1BDC7177@HE111644.EMEA1.CDS.T-INTERNAL.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [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: Fri, 11 Oct 2013 11:05:41 -0000

On 10/11/2013 11:20 AM, BeckW@telekom.de wrote:
> Ted wrote:
>> So, I'm a little confused about why that is the basic question.  If the prioritization is done by something like a diffserv code
>> point, it seems like the question is how the flow signals its classification, rather than to whom it signals that .  I would
>> presume that the networks which honor such markings would be constructed such that some conversant network element is on path.
>> What it is and where it is kind of aren't the JS app or browser's issue.
>> What am I missing?
> Here are some examples that were mentioned on the list or elsewhere:
> - My company doesn't allow tunnels to the TURN server of some outside WebRTC service. How can I tell the WebRTC service to use my company's TURN server?
> - My ISP uses DSCP code point x for low delay. How can I tell my WebRTC service to use this code point for the flows that require low delay (as Harald correctly pointed out, only the service self knows about the requirements of a flow)?
> - My ISP requires admission control to protect its low delay class from packet loss. How can a WebRTC service contact the resource admission control service (ok, this a bit speculative)?
>
> In all those cases, the WebRTC service needs information about the user's infrastructure, be it the company intranet or the ISP. We currently don't have a good way to get such information.

This topic may have solutions that aren't being pursued in the RTCWEB WG.

In particular:

http://www.w3.org/TR/2013/WD-discovery-api-20130924/

describes a proposal for how to find objects on the local net 
(currently: announced via upnp and zeroconf), and

http://www.w3.org/TR/netinfo-api/

describes a proposal for getting some information about how you're 
connected to the network.

Getting that information may be out of scope for WEBRTC or RTCWEB.
Putting that information to use once we have it may be in scope.