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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Oct 2013 13:51:12 +0200

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 http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml 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.

Cheers

Magnus

---

From: Saverio Vardaro <[email-masked]>
Date: Tue, 1 Oct 2013 18:01:24 +0200

On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl <[email-masked]> wrote:

> > Does your mobile provider currently do reverse dns for your mobile's
> real ip address?****
>
> >CB****
>
> Good question and the answer is good: Yes****
>
> We just checked both major 3G mobile operators TeleaSonera and Tele2 in
> Sweden.****
>
> E.g. just surfing  to http://whatismyipaddress.com ****
>
> (which tells me it is TeliaSonera, Wireless Broadband)****
>
> Then clicking the “Additional IP Details” button, I get the PTR record:***
> *
>
> host-95-199-196-65.mobileonline.telia.com****
>
> Tele2 gave: m83-186-15-99.cust.tele2.se****
>
> ** **
>
> So, obviously mobile providers have ways of provisioning these kind of
> things in DNS.****
>
> ** **
>
> How does it look in other places of the world?****
>
> **
>
[SV] This is NOT the case for Vodafone Italy

> **
>
> /Karl****
>
> ** **
>
> ** **
>
> *Från:* cb.list6 [mailto:[email-masked]]
> *Skickat:* den 27 september 2013 01:06
> *Till:* Karl Stahl
> *Kopia:* [email-masked]; [email-masked];
> [email-masked];
> [email-masked]
> *Ämne:* Re: SV: [rtcweb] TURN server address via DHCP, WGLC of
> draft-ietf-rtcweb-use-cases-and-requirements-11****
>
> ** **
>
>
> On Sep 26, 2013 8:27 AM, "Karl Stahl" <[email-masked]> wrote:
> >
> > Here comes the suggestion I got from my developer that would allow a
> network
> > provider to offer his TURN server for the WebRTC browser to use. This
> would
> > require NO new DHCP-options or similar, and NO OS changes (I do realize
> > those should be avoided if possible...).
> >
> > The idea is still, that whoever is responsible for giving a device an IP
> > address (the network provider or a LAN administrator) can also announce a
> > TURN server for the WebRTC browser to use.
> >
> > The suggestion is to use RFC6763 (DNS-Based Service Discovery, see
> chapter
> > 11) where the network provider (the owner of the IP address) has set up a
> > DNS PTR record for the TURN server in the in-addr.arpa domain.
> >
> > If the device got IP 173.164.252.149, then make a query for the PTR
> record
> > for:
> > _turn._udp.149.252.164.173.in-addr.arpa.
> > Then the SRV record would return the actual address to the TURN server
> (and
> > you may find several for load balancing and failover I guess)
> >
> > If the device is on a LAN, the IP 173.164.252.149 to query would be the
> WAN
> > IP you get via STUN in the ICE process. But if the LAN administrator
> > provides a local TURN server, then he also should have blocked STUN in
> the
> > firewall, and the browser should query the device's local host address
> (as
> > in the ICE procedure) and the local LAN DNS server should answer the
> query
> > to give the local TURN server address on the LAN.
> >
> > Shouldn't this work to allow network provider to offer his TURN server
> > "automatically and generally"?
> >
> > And wouldn't this work nicely for mobile devices, whenever the device is
> on
> > a "WebRTC-ready access" (actually good for everything using ICE), whether
> > fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
> > provider hopefully offers a prioritized pipe there as one usage of this
> > mechanism).
> >****
>
> Does your mobile provider currently do reverse dns for your mobile's real
> ip address?****
>
> CB****
>
> > Not to slow down every call setup by doing this in the ICE process, I
> guess
> > this could be done when starting the browser and when the device gets a
> new
> > IP address, to have the TURN server address ready for later use.
> >
> > /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: [email-masked] [mailto:[email-masked]] För
> > [email-masked]
> > Skickat: den 26 september 2013 14:06
> > Till: [email-masked]; [email-masked]
> > Kopia: [email-masked]
> > Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> > draft-ietf-rtcweb-use-cases-and-requirements-11
> >
> > Hi,
> >
> > Cullen Jennings wrote:
> > >
> > > I will note that browsers have many ways to learn about HTTP proxies
> > > from the network and it seems to me that using some of theses same
> > > technique might also be a good way to learn about TURN servers.
> > >
> >
> > I agree. I assume that in enterprises it would be the same people
> managing
> > both of these.
> >
> > Is there something the IETF can or should do about this, or do we just
> > assume it will happen? A new DHCP option is something the IETF could
> easily
> > do, but I also doubt how usable that would be.
> >
> > Markus
> > _______________________________________________
> > rtcweb mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >****
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Oct 2013 14:51:39 -0700

On 24 September 2013 23:15, Harald Alvestrand <[email-masked]> wrote:
>
> The existence of that (public) document explains some strange features
> of some earlier Microsoft proposals that I was never able to get an
> explanation for.
>
> This approach (which seems to have many of the properties of RSVP) seems
> to offer a solution to some problems that people have been solving by
> snooping SIP (which is impossible if SIP isn't used, and very hard when
> all the SIP channels are encrypted). Is there a chance that we could get
> public-stable specification of the required pieces, so that other
> companies can dare to depend on it?

http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

I've had interest in this from other people.  It is currently framed
as a mitigation for an attack, but it turns out that the TURN
allocation sizing is probably the most interesting part, since the
consent mechanism provides a fairly effective mitigation mechanism.
Especially if we define a new STUN error code that can be used to
provide immediate consent termination.

It's less generic than the malice draft, which I find compelling,
though I know generality is appealing to some people.

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 3 Oct 2013 00:50:01 +0200

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
reconsider...

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).

/Karl

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[email-masked]] 
Skickat: den 1 oktober 2013 13:51
Till: Karl Stahl
Kopia: [email-masked];
[email-masked]
Ämne: Re: [rtcweb] [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,

On 2013-09-21 23:44, Karl Stahl wrote:
> 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 http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml 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.

Cheers

Magnus

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 3 Oct 2013 14:36:55 +0000

On Sep 21, 2013, at 4:29 PM, Karl Stahl <[email-masked]> wrote:

> I've heard several carries expressing that they want to provide their own
> TURN servers with their accesses.

Any chance you could put me in touch with some of them. I'd love to get more information on what is needed so we can solve this.

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 3 Oct 2013 17:58:20 +0200

Yes, I'll check with them and I return on your fluffy email. /Karl

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Skickat: den 3 oktober 2013 16:37
Till: Karl Stahl
Kopia: [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of

On Sep 21, 2013, at 4:29 PM, Karl Stahl <[email-masked]> wrote:

> I've heard several carries expressing that they want to provide their 
> own TURN servers with their accesses.

Any chance you could put me in touch with some of them. I'd love to get more
information on what is needed so we can solve this.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 18:35:16 +0000

Hi,

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.

Thanks!

Regards,

Christer

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

Hej Magnus,

/Karl

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[email-masked]]
Skickat: den 1 oktober 2013 13:51
Till: Karl Stahl
Kopia: [email-masked];

Hi Karl,

of).

Cheers

Magnus

---

From: Justin Uberti <[email-masked]>
Date: Thu, 3 Oct 2013 11:59:20 -0700

WPAD already supports DNS-based discovery (in addition to DHCP). If you
have host-95-199-196-65.mobileonline.telia.com as your endpoint hostname,
it will try to get a PAC file from wpad.mobileonline.telia.com.

Since for all practical purposes, TURN is a "UDP proxy", I think it should
be handled similar to other proxy autoconfig mechanisms.

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <[email-masked]> wrote:

> I happily withdraw my suggestion to use DHCP to find a network provider
> offered TURN server in favor of the DNS-Based Service Discovery method
> (inserted last below). The major problem with the DHCP usage was that you
> then also have to do something similar for: RA - Router Advertisement - in
> IPv6, addition to the IPCP protocol for PPPoE and something for the mobile
> OTT channel – wherever DHCP is NOT the method to give you an IP address.**
> **
>
> ** **
>
> Further:****
>
> > On Thu, Sep 27, 2013 Justin Uberti wrote:****
>
> > Agree. I still think that extending PAC files to include TURN
> information is the right way to go.****
>
> > PAC files can already be discovered via DHCP or DNS, there is no need to
> reinvent this wheel.****
>
> ** **
>
> >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <
> [email-masked]> wrote:****
>
> >>I think we need to give some advise to the browsers vendors on what they
> should implement to find turn servers****
>
> ** **
>
> I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file
> can be picked up through a URL based on the device name. Similar could work
> for finding a TURN server on a LAN, but what about the case with a network
> provider offered TURN server? The network provider hands out an IP address
> and wants to announce a related TURN server address: – Is there a “PAC-way”
> to announce it to a device on a LAN (behind a NAT/firewall)? The device
> must find such configuration file based on its public IP address (that he
> can find using STUN as in the suggestion below).****
>
> ** **
>
> But generally, finding a TURN-server is a network-thing, ICE (or even TURN
> not using ICE), not a Web-thing, so for that reason the DNS-Based Service
> Discovery method is at a better level. Such method could also be used by
> SIP clients (even a Skype client could implement it to benefit from a
> real-time path with better quality, if the network provider offers such
> path through his TURN server).****
>
> ** **
>
> The DNS-Based Service Discovery method should be easy to implement in a
> WebRTC browser (doing complex ICE things anyway). The question is rather
> how easy it is for the network provider to provision. Do they all do
> reverse DNS like with found with mobile operators TeliaSonera and Tele2 in
> Sweden? Then it should not be too difficult.****
>
> ** **
>
> Or is there yet another better method to announce a TURN server address
> with the IP address offered?****
>
> ** **
>
> /Karl****
>
> ** **
>
> ** **
>
> *Från:* [email-masked] [mailto:[email-masked]] *För *Bernard
> Aboba
> *Skickat:* den 29 september 2013 02:41
> *Till:* Harald Alvestrand
> *Kopia:* [email-masked]
>
> *Ämne:* Re: [rtcweb] TURN server address via DHCP, WGLC of
> On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <[email-masked]> wrote:
>
> "So far, neither the POSIX standard nor any OS vendor has offered a
> generic facility to access information made available in DHCP packets."***
> *
>
> ** **
>
> [BA] The Windows DHCP client API does provide this: ****
>
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx
> ****
>
> ** **
>
> In particular, the SendParams argument to the DhcpRequestParams
> function can be used to request a particular parameter (e.g. TURN server
> address), which will then be returned in the RecdParams variable.  ****
>
> ** **
>
> Nevertheless, I still think that using DHCP to configure the TURN server
> address in a browser isn't a good idea.  For one thing, since DHCP is
> effectively unsecured, this mechanism could be used by a rogue DHCP server
> to force traffic to a rogue turnserver.   Great for surveillance!****
>
> ** **
>
> ** **
>
> On Sep 27, 2013 1:27 AM, "Karl Stahl" <[email-masked]> wrote:****
>
> provider to offer his TURN server for the WebRTC browser to use. This would
> The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapter
> If the device got IP 173.164.252.149, then make a query for the PTR record
> for:
> Then the SRV record would return the actual address to the TURN server (and
> If the device is on a LAN, the IP 173.164.252.149 to query would be the WAN
> provides a local TURN server, then he also should have blocked STUN in the
> firewall, and the browser should query the device's local host address (as
> in the ICE procedure) and the local LAN DNS server should answer the query
> And wouldn't this work nicely for mobile devices, whenever the device is on
> Not to slow down every call setup by doing this in the ICE process, I guess
> this could be done when starting the browser and when the device gets a new

---

From: "cb.list6" <[email-masked]>
Date: Thu, 3 Oct 2013 17:08:46 -0700

> > I've heard several carries expressing that they want to provide their
own
> Any chance you could put me in touch with some of them. I'd love to get
more information on what is needed so we can solve this.

+1. I am especially interested in the case of providing my ipv6-only access
customers with dual-stack TURN capabilities

CB
T-Mobile US

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Oct 2013 10:38:00 +0200

Hi Karl,

> codec that will be selected for WebRTC (VPx or H.26y).

Yes, but we already today have at least 126 media type names registered
that has RTP Payload formats. Out of these a significant number do
requires additional parameters, like H.264, AMR, i.e. one media type may
not represent one interoperability point but many.

Thus static assignment of codec plus parameters are totally out of the
question. We also have various different usages and none includes all
the available media types, if they would, we already now would have run
out of RTP payload types.

> bring us beyond POTS quality on a massive scale - we (IETF) may

IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field. If you argument is that it is
difficult to agree on mapping between media types and quality to static
value being used everywhere, the same applies to RTP level. You will not
be able to make legacy abide any static assignments. So you will see
voice in the video class etc and vice versa.

> and surely others, like SIP-client, would follow this usage (or add it to

What would you gain if you can't rely on the PT value being used for the
defined usage. In general you will see other IP/UDP/RTP flows with
PT=111 that will be H.264, or MPEG-2 or what ever.

Also, are you really interested in knowing that it is VP9 vs H.264,
isn't the questions this is video of this priority that is important?

I think you need to more carefully consider what are the goals you try
to achieve them. What layer do you want to achieve them at. Who are
going to react to you information and how can one trust it across
administrative boundaries. Also what scope for this information are you
trying to achieve, full end to end, only first two hops?

This is a difficult issue with no good solutions. A restricted problem
may be possible to solve, a larger one may not be realistic.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 7 Oct 2013 14:21:08 +0200

We checked some more mobile service providers in US and Japan (Softbank) and
they all did reverse DNS for the real IP address at the OTT channel.

US: Charter Communications, Broadband: Hostname:
66-189-44-147.dhcp.oxfr.ma.charter.com 

US: Verizon Wireless, Wireless Broadband: Hostname:
179.sub-174-252-35.myvzw.com

Japan (Softbank): ASAHI Net,Inc.: Hostname: k185241.ppp.asahi-net.or.jp

Sweden (Tele2/Comviq): Hostname: m90-130-225-160.cust.tele2.se

Sweden: Telia Sonera AB, Wireless Broadband: Hostname:
host-95-199-20-150.mobileonline.telia.com

Sweden: Tele2 SWlPnet, Tele2 Mobil, wireless Broadband: Hostname:
m5-243-149-119.cust.tele2.se

Sweden: Telenor Sverige AB, Wireless Broadband: Hostname:
c-5eeaaa41-74736162.cust.telenor.se

/Karl

Från: Saverio Vardaro [mailto:[email-masked]] 
Skickat: den 1 oktober 2013 18:01
Till: Karl Stahl
Kopia: cb.list6; [email-masked]; [email-masked];
[email-masked]
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

> Does your mobile provider currently do reverse dns for your mobile's real
ip address?

>CB

Good question and the answer is good: Yes

Sweden.

E.g. just surfing  to http://whatismyipaddress.com 

(which tells me it is TeliaSonera, Wireless Broadband)

Then clicking the “Additional IP Details” button, I get the PTR record:

host-95-199-196-65.mobileonline.telia.com

Tele2 gave: m83-186-15-99.cust.tele2.se

things in DNS.

How does it look in other places of the world?

/Karl

Från: cb.list6 [mailto:[email-masked]] 
Skickat: den 27 september 2013 01:06
Till: Karl Stahl
Kopia: [email-masked]; [email-masked];
[email-masked];
[email-masked]
Ämne: Re: SV: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

network
would
(and
WAN
on
> provider hopefully offers a prioritized pipe there as one usage of this

Does your mobile provider currently do reverse dns for your mobile's real ip
address?

CB

guess
new
> I agree. I assume that in enterprises it would be the same people managing
> both of these.
>
easily

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 7 Oct 2013 15:21:39 +0200

So the WPAD-way of getting a network provider’s TURN server address for the real (white, global) IP address he has handed out to a user, the browser would:

- Use STUN to find the global IP address (done anyway in ICE)

- Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that is not yet deployed)

- Make a URL based on the hostname from the reverse DNS lookup, e.g. from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

- And there find a list (in JS) of TURN server addresses for the network provider’s IP addresses

 Or would an alternative be to add your own IP address to the URL and get only your specific TURN server address?

Doing it at this Web level, I think we also should consider clients using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client be able to parse a “JS table” to find his TURN server address easily? Also, are there long time-outs to be considered when there is no h ttp://turned.myvzw.com to be found?

This method may be easier for a network provider to deploy (I don’t know, but for local use on a LAN I guess it is). On the other hand, the DNS-Based Service Discovery method is quick and easy for a WebRTC browser, so that may be tried as well.

Independent of how we find the network provided TURN server, one advantage with it is the authentication: The network provider simply sets up the TURN for usage from the IP addresses he has handed out.

/Karl

Från: Justin Uberti [mailto:[email-masked]] 
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); [email-masked]; [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

WPAD already supports DNS-based discovery (in addition to DHCP). If you have  <http://host-95-199-196-65.mobileonline.telia.com/> host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it will try to get a PAC file from wpad.mobileonline.telia.com.

Since for all practical purposes, TURN is a "UDP proxy", I think it should be handled similar to other proxy autoconfig mechanisms.

I happily withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address.

Further:

> On Thu, Sep 27, 2013 Justin Uberti wrote:

> Agree. I still think that extending PAC files to include TURN information is the right way to go.

> PAC files can already be discovered via DHCP or DNS, there is no need to reinvent this wheel.

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < <mailto:[email-masked]> [email-masked]> wrote:

>>I think we need to give some advise to the browsers vendors on what they should implement to find turn servers

I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file can be picked up through a URL based on the device name. Similar could work for finding a TURN server on a LAN, but what about the case with a network provider offered TURN server? The network provider hands out an IP address and wants to announce a related TURN server address: – Is there a “PAC-way” to announce it to a device on a LAN (behind a NAT/firewall)? The device must find such configuration file based on its public IP address (that he can find using STUN as in the suggestion below).

But generally, finding a TURN-server is a network-thing, ICE (or even TURN not using ICE), not a Web-thing, so for that reason the DNS-Based Service Discovery method is at a better level. Such method could also be used by SIP clients (even a Skype client could implement it to benefit from a real-time path with better quality, if the network provider offers such path through his TURN server).

The DNS-Based Service Discovery method should be easy to implement in a WebRTC browser (doing complex ICE things anyway). The question is rather how easy it is for the network provider to provision. Do they all do reverse DNS like with found with mobile operators TeliaSonera and Tele2 in Sweden? Then it should not be too difficult.

Or is there yet another better method to announce a TURN server address with the IP address offered?

/Karl

Från: [email-masked] [mailto:[email-masked]] För Bernard Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: [email-masked]

Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

"So far, neither the POSIX standard nor any OS vendor has offered a generic facility to access information made available in DHCP packets."

[BA] The Windows DHCP client API does provide this: 

In particular, the SendParams argument to the DhcpRequestParams function can be used to request a particular parameter (e.g. TURN server address), which will then be returned in the RecdParams variable.  

Nevertheless, I still think that using DHCP to configure the TURN server address in a browser isn't a good idea.  For one thing, since DHCP is effectively unsecured, this mechanism could be used by a rogue DHCP server to force traffic to a rogue turnserver.   Great for surveillance!

On Sep 27, 2013 1:27 AM, "Karl Stahl" < <mailto:[email-masked]> [email-masked]> wrote:

Here comes the suggestion I got from my developer that would allow a network
provider to offer his TURN server for the WebRTC browser to use. This would
require NO new DHCP-options or similar, and NO OS changes (I do realize
those should be avoided if possible...).

/Karl

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 7 Oct 2013 22:16:04 +0200

Quality (below)... and it's NOT all about bandwidth

Dan Wing wrote: 
> Unfortunately the industry doesn't yet seem to agree there is even a
problem.

Well, that depends on which part of "the industry" we seem to be in:

There seems to be more concern about quality for 3.5 kHz POTS pre AM-radio
quality voice, than for HiFi and HD video WebRTC with telepresence
capability... I think forward carriers are concerned.

And when putting the media over our data crowded Internet accesses (that is
the way it is/has to be with WebRTC, Skype etc.) there is certainly
competition for the bandwidth. TCP type of traffic is always
(intermittently) filling the pipe at the most narrow point, packets are lost
(that is the way TCP flows share the bandwidth and make the Internet work),
but both TCP and UDP packets carrying media are lost. Level 3 (or lower) QoS
mechanisms diffserve, RSVP, prioritization and traffic shaping at congestion
points (most often the CPE/Firewall/access router) helps/works - if used!

- Carriers deploying POTSoIP with voice ending up in RJ11 ports on a CPE
(often part of a triple play service, delivering also data and IP-TV) always
have some sort of level 3 or below QoS, giving them loss-less voice media
transport. E.g. my ADSL+2 CPE classifies RJ11 voice, puts it on prioritized
level 2 ATM (57 byte packets!) until the DSLAM headend puts it together to
prioritized VLAN Ethernet frames and some switch puts it onto an MPLS link,
that in this case actually carries IP-packets with routable addresses. This
call may go to a 100 Mbps triple play Ethernet service where the voice comes
over a VLAN tagged Ethernet, not competing with data that is on another VLAN
(but often broken by some TDM peering point if more carriers are
involved...).

- Today, with higher access speeds, there is a carrier trend to use IP-level
diffserve QoS in the access (instead of level 2-2.5 separate networks), and
cable networks use RSVP for media that are shared on their Internet pipes.
That is sufficient and gives loss-less, low delay media transport.

QoS mechanisms at data crowded Internet accesses are required, even for
decent POTS voice. I have a good 2 Mbps upstream ADSL2+ Annex M access.
Using VoIP on my LAN without any QoS mechanism - 100 kbps voice is not even
possible for the remote end to understand, when two kids are surfing and
file sharing resulting in some 2000 open TCP flows on the same access.
Adding prioritization and traffic shaping in the ADSL modem/firewall
(built-in E-SBC which SIP proxy keeps track of SIP media and classifies it),
the voice get as perfect as when I had the pipe to myself for my call only.

When SIP Trunking PBXs (i.e. connecting them to ITSPs IP telephony access,
as we do with our Ingate and Intertex E-SBCs), there is often a separate
non-Internet pipe (maybe over MPLS) or an Internet access only used for the
SIP Trunk. But when we share an Internet pipe with TCP flow intensive data,
we certainly apply QoS (prioritization and traffic shaping (staying below
the access bandwidth by holding back data traffic). That is a must for
decent sound quality - even when you have plenty of bandwidth.

Now with WebRTC, there is no signaling protocol to help us see what is going
on, diffserve bits cannot be set in common OS (and maybe never when muxing
different flows over a single UDP port), signaling and media is encrypted
and ICE is used for traversing NAT/firewalls without them having a clue what
is going on (which was the purpose with ICE...). How can we then classify
the real-time traffic and apply any level 3 QoS methods that can do miracles
in this harsh environment?

That is why I brought up the idea of enforcing TURN at the access and
classifying or routing UDP flows opened by ICE.

Even if favoring UDP over TCP, using tolerant codecs, FEC, and other
endpoint smart trix helps a lot, there is a limit to what can be achieved if
you have packet loss and delay. Those are the things handled with level 3
(and below) QoS. WebRTC requires better transport than POTS voice, and
bandwidth is not everything. The network must be given a chance to
prioritize the traffic that needs it.

(Just to clarify: I don't want us to use separate networks - Let's stay on
our Internet accesses!)   

/Karl

PS: Just browsed your links briefly and noted "(PCP [RFC6887]).
...surprising ...does not require the network operate a NAT..." The same
goes for TURN also, doesn't it?

-----Ursprungligt meddelande-----
Från: Dan Wing [mailto:[email-masked]] 
Skickat: den 23 september 2013 19:57
Till: Karl Stahl
Kopia: [email-masked];

of).
> recommended for WebRTC (PT:35-71 are unassigned)?
> I relation to that simple request, one may wonder how the network 
> anyway can know what is carried in an UPD packet (the RTP header is no 
> reserved field - it could be the payload of something else).
> 
> Quality related requirements F38, A23 and A26 in the use case draft, 
> nowadays only seem to relate to the browsers, not assuming that 
> diffserve bits or similar are conveyed to the network. That is 
> realistic, since most operating systems don't allow quality markings
(diffserve, TOS) of packets.
> However, 3.2.1.  Simple Video Communication Service, mentions "The web 
> service monitors the quality of the service (focus on quality of audio 
> and
> video) the end-users experience.". I don't understand how "The *web 
> service* monitors" based on the listed requirements. Should it be "The 
> *browsers* monitors"?
> 
> What are then the possibilities for a network to classify traffic for 
> quality or other purposes?

I agree there is a problem here, and have been trying to convince others
there is a problem that needs to be solved.  So far, there appears to be
scant agreement there is a problem.  See thread on TSVWG starting at
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12182.html.  The
solution I am pitching is an extension to PCP, draft-wing-pcp-flowdata.
Another solution is MALICE which adds information to the ICE connectivity
checks (bandwidth, drop preference, etc.) which can be DPI'd by network
devices.

But before getting deep on solutions, we first we need some consensus that
some flows need different handling than other flows, and then acquiescence
that existing techniques do not solve the problem (RSVP, NSIS, Diffserv).
Unfortunately the industry doesn't yet seem to agree there is even a
problem.

-d

> 
> 3G/4G networks have DPIs (Deep Packet Inspection) - such box may guess 
> what encrypted RTP traffic is... or may not...
> 
> Real time communication protocols using ICE as a pre-protocol to 
> establish media paths give a possibility though. If the network 
> provider offers a TURN server at his access, and enforces the TURN 
> server to be used (by eating STUN packets), then the RTP flows set up 
> through the TURN server could classify and mark packets. Then it is 
> useful to know whether it is an audio or video packet by looking at the
payload type.
> 
> A LAN firewall, can also include a TURN-server, that in addition to 
> classifying and marking packets for the transport network (if honored 
> - which rarely is the case on the Internet today), it can also 
> prioritize and traffic shape so the RTP traffic at least is 
> undisturbed through a data crowded Internet access.
> 
> A more difficult request comes from networks using bandwidth 
> reservation
> (RSVP) for quality, like mobile and cable networks. Such networks 
> would benefit from knowing the bandwidth used, but that is not fixed 
> for advanced codecs like the ones considered for WebRTC. One way would 
> be to reserve maximum bandwidth, and possibly repeat the reservation 
> if less is actually used.
> 
> /Karl
> 
> 
> Karl Stahl
> Skickat: den 21 september 2013 02:16
> Till: [email-masked];
> Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
> 
> While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, 
> here are a few "telephony related" WebRTC things I think should be 
> clarified in the use cases.
> 
> 
> 3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...  
> The invited user might accept or reject the session. 
> [Suggest adding] The invited user might accept only audio, rejecting 
> video (even if a camera is enabled). A user may also select to 
> initiate an audio session, without video.
> 
> And in API requirements:
>   ----------------------------------------------------------------
>   A1      The Web API must provide means for the application to ask the
> browser for permission to use cameras and microphones, individually as 
> input devices. (One must be able to answer with voice only - declining
video.)
>   ----------------------------------------------------------------
> Same under
> 6.2.  Browser Considerations
> ...
> The browser is expected to provide mechanisms for users to revise and 
> even completely revoke consent to use device resources such as camera 
> and microphone. [Suggest adding] Specifically, a user must be given 
> the opportunity to only accept audio in a video call invitation.
> 
> 
> 
> 3.2.12.  Multiparty video communication 3.2.12.1.  Description ...
> [Suggest adding] It is essential that automatic adjustments of 
> microphone volume is disabled, or microphones not spoken into are 
> muted. (This is a serious problem with most soft clients (SIP clients) 
> of today, plaguing conferences with ever increasing noise from silent 
> participants.)
> 
> And in API requirements:
>   ----------------------------------------------------------------
>   A15     The Web API must provide means for the web application to adjust
> the level in audio streams.
>  ----------------------------------------------------------------
>   Axx     The Web API must provide means to disable any automatic volume
> adjustment in the sent audio streams. (To avoid disturbing noise in 
> conferences - making many softclients unusable).
>   ----------------------------------------------------------------
> 
> 
> 
> 3.2.6.  Simple Video Communication Service, access change 3.2.6.1.
> Description ...
> the user has to start a trip during the session. The communication 
> device automatically changes to use WiFi when the Ethernet cable is 
> removed and then moves to cellular access to the Internet when moving 
> out of WiFi coverage.  The session continues even though the access method
changes.
> 
> [Question] Is this some sort of roaming without network support 
> (please clarify)? Getting a new access will also give the client a new 
> IP address, won't it? How could then the session continue? The 
> browsers will have no signaling connection and cannot renegotiate a media
connection, can they?

---

From: Justin Uberti <[email-masked]>
Date: Mon, 7 Oct 2013 23:17:04 -0700

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <[email-masked]> wrote:

> So the WPAD-way of getting a network provider’s TURN server address for
> the real (white, global) IP address he has handed out to a user, the
> browser would:****
>

How does this get bootstrapped? That is, how is the STUN server found?

> ****
>
> - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that
> is not yet deployed)****
>
> - Make a URL based on the hostname from the reverse DNS lookup, e.g. from
> 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com
>

I was hoping we could do something simpler, such as using the ISP's
configured domain search list, to determine the domain.

> ****
>
> - And there find a list (in JS) of TURN server addresses for the network
> provider’s IP addresses****
>
>  Or would an alternative be to add your own IP address to the URL and get
> only your specific TURN server address?****
>
> ** **
>
> Doing it at this Web level, I think we also should consider clients using
> ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client
> be able to parse a “JS table” to find his TURN server address easily? Also,
> are there long time-outs to be considered when there is no h ttp://
> turned.myvzw.com to be found?
>
****
>
> ** **
>
> This method may be easier for a network provider to deploy (I don’t know,
> but for local use on a LAN I guess it is). On the other hand, the DNS-Based
> Service Discovery method is quick and easy for a WebRTC browser, so that
> may be tried as well.****
>
> ** **
>
> Independent of how we find the network provided TURN server, one advantage
> with it is the authentication: The network provider simply sets up the TURN
> for usage from the IP addresses he has handed out.****
>
> ** **
>
> /Karl****
>
> ** **
>
> *Från:* Justin Uberti [mailto:[email-masked]]
> *Skickat:* den 3 oktober 2013 20:59
> *Till:* Karl Stahl
> *Kopia:* Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);
> *Ämne:* Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of
> it will try to get a PAC file from wpad.mobileonline.telia.com.****
>
> ** **
>
> be handled similar to other proxy autoconfig mechanisms.****
>
> ** **
>
> On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <[email-masked]>
> wrote:****
>
> *Kopia:* [email-masked]****
>
>
> mechanism).****
> IP address, to have the TURN server address ready for later use.****
>
> /Karl****
>
> ** **
>

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 8 Oct 2013 09:17:00 +0200

Hej Magnus,

> Also, are you really interested in knowing that it is VP9 vs H.264, isn't
the questions this is video of this priority that is important?
> I think you need to more carefully consider what are the goals you try to
achieve them.

Actually, my concern is to get an idea of the maximum bandwidth that could
be required for a WebRTC (ICE) setup media flow. Both voice and video should
be prioritized over data (their individual priority is of less importance as
long as there is sufficient bandwidth for both).

With diffserv you don’t need to know the bandwidth requirement, but with
RSVP reservation (like in cable and mobile networks) you need to know how
much to reserve. Voice is like 100's kbit/s, video VP8 or H.264 is like 3,5
mbps. 

To add to the complication of codec variants, the video codecs in question
for WebRTC have variable bandwidth, and when there is a poor connection we
see Chrome reducing the video window size to reduce the bandwidth used... 

I think the payload type field at best can reflect a maximum bandwidth to
initially reserve bandwidth for, and thereafter make new reservations if the
bandwidth changes during the call. So could we change RTP to show maximum
bandwidth instead of payload type in that field outside the encrypted
payload :) ... Or maybe that is not a joke?

> IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field.

Sure, but current OS stop those bits to be set by the WebRTC browser. And
when multiplexing everything over one UDP port, I doubt we will ever see
diffserv bits coming from the application. Further, diffserv bits does not
give us the bandwidth required for RSVP networks.

In cable networks today, they look into the SIP/SDP signaling to see the
bandwidth to reserve (usually only G.711 I believe). That cannot be done
with no signaling WebRTC and all encrypted. On another track, I suggested
enforcing TURN to be used (by eating the initial STUN packet). That could
capture the ICE initiated media flow, but there is still a need to estimate
the bandwidth requirement for RSVP type of networks.

/Karl

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[email-masked]] 
Skickat: den 7 oktober 2013 10:38
Till: Karl Stahl
Kopia: [email-masked];
[email-masked]
Ämne: Payload Types assignments was Re: SV: [rtcweb] [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,

On 2013-10-03 00:50, Karl Stahl wrote:
> 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).

Yes, but we already today have at least 126 media type names registered that
has RTP Payload formats. Out of these a significant number do requires
additional parameters, like H.264, AMR, i.e. one media type may not
represent one interoperability point but many.

Thus static assignment of codec plus parameters are totally out of the
question. We also have various different usages and none includes all the
available media types, if they would, we already now would have run out of
RTP payload types.

> (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 reconsider...

IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field. If you argument is that it is
difficult to agree on mapping between media types and quality to static
value being used everywhere, the same applies to RTP level. You will not be
able to make legacy abide any static assignments. So you will see voice in
the video class etc and vice versa.

> 
> 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).

Also, are you really interested in knowing that it is VP9 vs H.264, isn't
the questions this is video of this priority that is important?

I think you need to more carefully consider what are the goals you try to
achieve them. What layer do you want to achieve them at. Who are going to
react to you information and how can one trust it across administrative
boundaries. Also what scope for this information are you trying to achieve,
full end to end, only first two hops?

This is a difficult issue with no good solutions. A restricted problem may
be possible to solve, a larger one may not be realistic.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Oct 2013 13:00:59 +0200

> long as there is sufficient bandwidth for both).

You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement
and event information (data) is MORE time sensitive than the voice data.

> much to reserve. Voice is like 100's kbit/s, video VP8 or H.264 is like 3,5

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth
variation of screencast (semi-static with sudden, large changes) is
completely different from that of a talking head, which is again
completely different from a high-movement scene.

> payload :) ... Or maybe that is not a joke?

I think these ruminations only lead to one conclusion:

You can't tell what the needed bandwidth is up front without asking the
application.
You can't tell what the right priority ranking is without asking the
application.

If you need to know the bandwidth or the priority up front, the
application has to tell you. Anything else is pure heuristics.

---

From: <[email-masked]>
Date: Thu, 10 Oct 2013 17:02:19 +0200

The basic question seems to be: how can the web server or JS client learn about local policy enforcement elements in the user's network and access them to allocate bandwidth, setup priorisation etc?

The ALTO WG had a very similar problem and proposed DHCP after DNS experts dismissed a discovery mechanism based on reverse DNS lookups.

The classical solution: avoid the problem by having a webrtc server in your local network which does policy enforcement/QoS priorisation etc, and interconnects to some other webrtc server with a standardized protocol like SIP or XMPP. Popular in RTCWEB, less popular elsewhere..

The DHCP way: let the browser learn about the policy enforcement elements through DHCP, it may communicate them to the server. This has some problems. There are no widely adopted DHCP APIs, and the policy enforcement elements may be unwilling to let some random web server access them.

DNS magic: derive the address of your local policy enforcement element by manipulating the result of a reverse DNS lookup of the global IP address. 

Manual configuration: Solves only the problem of missing DHCP APIs and introduces the usability nightmare we know too well from SIP clients. 

3rd party auth: the user authenticates with a local idP, which not only carries the user's name but also the local policy enforcement urls as attributes. A web server can use the 3rd party auth token to access the local network elements. Haven't thought this through yet. 

Wolfgang Beck

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: [email-masked]
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On 10/08/2013 09:17 AM, Karl Stahl wrote:
>> isn't
> Actually, my concern is to get an idea of the maximum bandwidth that 
> could be required for a WebRTC (ICE) setup media flow. Both voice and 
> video should be prioritized over data (their individual priority is of 
> less importance as long as there is sufficient bandwidth for both).

You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement and event information (data) is MORE time sensitive than the voice data.

>
> With diffserv you don't need to know the bandwidth requirement, but 
> with RSVP reservation (like in cable and mobile networks) you need to 
> know how much to reserve. Voice is like 100's kbit/s, video VP8 or 
> H.264 is like 3,5 mbps.

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely different from a high-movement scene.

>
> To add to the complication of codec variants, the video codecs in 
> question for WebRTC have variable bandwidth, and when there is a poor 
> connection we see Chrome reducing the video window size to reduce the bandwidth used...
>
> I think the payload type field at best can reflect a maximum bandwidth 
> to initially reserve bandwidth for, and thereafter make new 
> reservations if the bandwidth changes during the call. So could we 
> change RTP to show maximum bandwidth instead of payload type in that 
> field outside the encrypted payload :) ... Or maybe that is not a joke?

You can't tell what the needed bandwidth is up front without asking the application.
You can't tell what the right priority ranking is without asking the application.

If you need to know the bandwidth or the priority up front, the application has to tell you. Anything else is pure heuristics.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Oct 2013 09:30:53 -0700

On Thu, Oct 10, 2013 at 8:02 AM, <[email-masked]> wrote:

> The basic question seems to be: how can the web server or JS client learn
> about local policy enforcement elements in the user's network and access
> them to allocate bandwidth, setup priorisation etc?
>
>
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?

Ted

> The ALTO WG had a very similar problem and proposed DHCP after DNS experts
> dismissed a discovery mechanism based on reverse DNS lookups.
>
> The classical solution: avoid the problem by having a webrtc server in
> your local network which does policy enforcement/QoS priorisation etc, and
> interconnects to some other webrtc server with a standardized protocol like
> SIP or XMPP. Popular in RTCWEB, less popular elsewhere..
>
> The DHCP way: let the browser learn about the policy enforcement elements
> through DHCP, it may communicate them to the server. This has some
> problems. There are no widely adopted DHCP APIs, and the policy enforcement
> elements may be unwilling to let some random web server access them.
>
> DNS magic: derive the address of your local policy enforcement element by
> manipulating the result of a reverse DNS lookup of the global IP address.
>
> Manual configuration: Solves only the problem of missing DHCP APIs and
> introduces the usability nightmare we know too well from SIP clients.
>
> 3rd party auth: the user authenticates with a local idP, which not only
> carries the user's name but also the local policy enforcement urls as
> attributes. A web server can use the 3rd party auth token to access the
> local network elements. Haven't thought this through yet.
>
>
> Wolfgang Beck
>
> Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC
> of draft-ietf-rtcweb-use-cases-and-requirements-11
>
> In, for instance, a shooter game with voice backchannels, the movement and
> event information (data) is MORE time sensitive than the voice data.
>
> >
> completely different from that of a talking head, which is again completely
> different from a high-movement scene.
>
> >

---

From: <[email-masked]>
Date: Fri, 11 Oct 2013 11:20:13 +0200

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. 

Wolfgang Beck

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Oct 2013 13:05:26 +0200

> 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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Oct 2013 04:31:59 -0700

On 11 October 2013 04:05, Harald Alvestrand <[email-masked]> wrote:
> describes a proposal for how to find objects on the local net (currently:
> announced via upnp and zeroconf), and
>
> describes a proposal for getting some information about how you're connected
> to the network.

Those solutions may not be appropriate for use in web browsers, in
much the same way that the "raw sockets" API is not.

> Putting that information to use once we have it may be in scope.

I find it more appropriate to say first that the problem is in scope,
then to look for solutions that you don't have to build yourself.  It
seems that if you want to be able to do priority marking, then a way
of discovering what markings do what is entirely in scope.

This is, of course, another case where the delineation of
responsibilities is required.  The W3C group you chair might decide to
use the discovery API, but there may be a need to assess the discovery
mechanisms here.

Other items on the list - a reasonable set of questions - seemed like
even larger problems.  If we're talking about a generic way to
advertise packet prioritization capabilities in a network, plus ways
to manage access to those features, that's a non-trivial enterprise.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Oct 2013 14:19:22 +0200

> much the same way that the "raw sockets" API is not.

That's the reason why I selected those particular ones - they are 
proposals being made for use in browsers.

They might be successful or unsuccessful, but the browsers are their target.

> to manage access to those features, that's a non-trivial enterprise.

Yup. Those proposals above don't address those problems. But if they are 
able to do what they are designed to do, following their lead may be 
more doable than striking out in a completely new direction.

(The netinfo API seems a bit moribund, btw. If anyone knows why, it 
would be nice if they could post an update here.)

---

From: <[email-masked]>
Date: Fri, 11 Oct 2013 14:25:59 +0200

Martin Thomson wrote:
>> .. http://www.w3.org/TR/2013/WD-discovery-api-20130924/ ..
>>
> Those solutions may not be appropriate for use in web browsers, in much the same way that the "raw sockets" API is not.
Netinfo-api is implemented in Firefox (with a moz prefix). It could be extended to match the use cases I described.

WD-discovery-api is wonderfully flexible, but probably too scary for the user:
"example.com wants to scan you network for all TVs, printers, routers, TURN-Servers: Deny/Allow?"
I guess that's the reason why no browser supports it.

Wolfgang

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Oct 2013 05:35:46 -0700

> Netinfo-api is implemented in Firefox (with a moz prefix). It could be extended to match the use cases I described.

That doesn't sound like a great idea, but it's there all right.  That
said, the capabilities are significantly less than what I remember
from when I last reviewed the specification:

>>> navigator.mozConnection.bandwidth
Infinity
>>> navigator.mozConnection.metered
false

Not exactly earth-shattering.

> WD-discovery-api is wonderfully flexible, but probably too scary for the user:

Oh hooray, another API with a requirement to ask a user for permission
without any real consideration given to how to ask properly.  You are
right, Section 4.1 is a frightful mess.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Oct 2013 10:56:17 -0700

On Fri, Oct 11, 2013 at 2:20 AM, <[email-masked]> wrote:

> 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.
> - 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?
>

I see.  I was taking your original statement "The basic question seems to
be: how can the web server or JS client learn about local policy
enforcement elements in the user's network and access them to allocate
bandwidth, setup priorisation etc?" a bit too literally--I thought you were
focused purely on prioritization and resource allocation.  If part of what
you mean is "how do I discover a service on the local network when I
require it", then the answer is going to be dependent on the service, not
on the condition that causes you to require it.  That it is, for TURN you
look to RFC 5766 and RFC 5928 and their successors, not to RTCWEB.

- 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)?
>

So, I'm not sure there are many places where DSCP markings from external
parties are trusted at AS borders in any case, but the theory is that we
say what DSCP marking should be used and the ISP recognizes it as WebRTC
traffic from that code point.  In the case where the ISP does trust
external markings but doesn't use a standard one, you have a bit of problem
in any case--the marking on the packet from the peer may be valid in the
origin network, so recommending it be changed to the one in the destination
may result in sub-optimal processing in the origin.  At that point, you
need one of the two peer networks to adjust the markings at the border.
This is, again, not really a problem for RTCWEB to solve.

> - 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)?
>
> Yeah, I tend to agree that this is 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.
>
>

For the services like TURN, I believe the answer is "use what ever is
defined for that service, rather than inventing a new one for WebRTC".  For
the marking, I think the answer has to be "define a standard marking",
since you likely can't find the specific markings and then implement
translations for all the networks a flow might traverse.

Just my opinion as a contributor, mind, not a chair or company statement.

regards,

Ted

---

From: "Lee, Richard FTC" <[email-masked]>
Date: Fri, 11 Oct 2013 14:25:33 -0400

I think peer to peer communications are fine and will work akin to the Skype (Best Effort delivery) model
Session quality will suffer periodically. While annoying, part of the price to pay for a free service
The expectation of providing network guarantees for timely service delivery does require active intervention (ToS or DSCP) with associated cost
Negotiation of codecs and bandwidth assignments are typically done by the endpoints in a peer to peer endpoints for a given session.
Due to the bandwidth options associated with video, it is expected that controls will be implemented at enterprise borders to enforce session constraints
In part to allow as many sessions as possible.

Enterprise support of webRTC will probably evolve as SIP has done.
There will be a service/proxy exposed to allow communications inside the corporate network
In many organizations protocols that bypass standard firewalls (STUN, TURN, ICE ...) are blocked.

Regards
Rich

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Friday, October 11, 2013 1:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Fri, Oct 11, 2013 at 2:20 AM, <[email-masked]<mailto:[email-masked]>> wrote:

I see.  I was taking your original statement "The basic question seems to be: how can the web server or JS client learn about local policy enforcement elements in the user's network and access them to allocate bandwidth, setup priorisation etc?" a bit too literally--I thought you were focused purely on prioritization and resource allocation.  If part of what you mean is "how do I discover a service on the local network when I require it", then the answer is going to be dependent on the service, not on the condition that causes you to require it.  That it is, for TURN you look to RFC 5766 and RFC 5928 and their successors, not to RTCWEB.

So, I'm not sure there are many places where DSCP markings from external parties are trusted at AS borders in any case, but the theory is that we say what DSCP marking should be used and the ISP recognizes it as WebRTC traffic from that code point.  In the case where the ISP does trust external markings but doesn't use a standard one, you have a bit of problem in any case--the marking on the packet from the peer may be valid in the origin network, so recommending it be changed to the one in the destination may result in sub-optimal processing in the origin.  At that point, you need one of the two peer networks to adjust the markings at the border.  This is, again, not really a problem for RTCWEB to solve.

For the services like TURN, I believe the answer is "use what ever is defined for that service, rather than inventing a new one for WebRTC".  For the marking, I think the answer has to be "define a standard marking", since you likely can't find the specific markings and then implement translations for all the networks a flow might traverse.
Just my opinion as a contributor, mind, not a chair or company statement.
regards,

Ted

Wolfgang Beck

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: [email-masked]<mailto:[email-masked]>
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Dan Wing <[email-masked]>
Date: Fri, 11 Oct 2013 17:35:12 -0700

On Oct 10, 2013, at 9:30 AM, Ted Hardie <[email-masked]> 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?

* Several operating systems do not allow non-privileged applications to set DSCP bits at all; Windows, for example.  Yes, I know everyone is supposed to use any other OS, but Linux has also only allowed certain DSCP values to be set.
* When joining a network, the DSCP values for the network cannot be learned or discovered -- we lack a protocol to do that.  The RFCs that define DSCP values are not standards (they are informational) and many a network choose their own values.  
* Setting the correct DSCP value affects only outgoing traffic but has no influence on the incoming traffic.  As you stated in a later post, incoming DSCP isn't trusted anyway.  "Reflexive DSCP Policy" was attempted years ago to allow the network to assume a host's DSCP settings could be applied to the other direction, but it was rejected I believe during IETF review but I couldn't find record why it was actually disposed (document was draft-ietf-ieprep-reflexive-dscp).

-d

---

From: <[email-masked]>
Date: Mon, 14 Oct 2013 17:04:12 +0200

WPAD has already been discussed on this list as a way to discover local TURN servers. If we extend WPAD for TURN servers, we may extend it for other local information.

WPAD never became an RfC so it could not be referenced in a RTCWEB document. The success of WPAD shows that there is a need for such a functionality.

Is it time to revive the 12 year old draft?

Wolfgang Beck

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 22 Oct 2013 16:36:31 +0200

This discussion got side tracked from where I started it from, so in the
next two mails I am jumping back to the threads where the original subjects
were left.  

Comment on this discussion: 

Using a WebRTC browser as a client into an application specific network
(e.g. IMS/VoLTE/RCS) is one usage of WebRTC. When building such a gateway as
a Web application, doesn’t the gateway (the web application) in itself know
the characteristics of the application specific network? I don’t see the
need to discover that.

But such gateway has the other side towards the Internet - That is where we
have the Web and the WebRTC browser. 

For the Internet side (in general, and of course with browser to browser
communication over the Internet also in mind)  I raised two questions:

1) How can the browser find a network provided TURN server (both local on a
LAN or provided by a carrier)?

2) Can the WebRTC browser/application convey real-time quality requirements
to the network, by using the payload type (that is what we can still see in
RTP, when both the payload and signaling are hidden from the network as it
is with WebRTC, and diffserv bits are not sufficient and not available
through the OSs).

These questions are related: There are carriers wanting to support WebRTC
traffic with better Internet access than their data crowded best effort
accesses. ICE/STUN/TURN allows a network provider to capture the real-time
traffic in a TURN server, where the network provider can offer a better path
for real-time traffic. 

Capturing such TURN flow, is a good start for providing better network
quality, but it would be even better would if the bandwidth requirements and
maybe some more qualities could be seen by the TURN server, e.g. by
signaling them in the RTP payload type. (This is especially true and I would
say required for RSVP type of networks, that has to reserve bandwidth.)

Jumping back to the two threads I started which were left at:

1) Justin pointing out the bootstrap problem of using reverse DNS to find a
network provided TURN server. (How is the STUN server to use first found?) I
will instead propose an anycast-way, that I think will do everything we are
looking for.

2) Harald listing the media types and their various quality needs. There is
actually a good way to signal those needs to the network (without using the
PT, or diffserv bits, which aren’t sufficient for RSVP type of networks
anyway). The RTP header extension field is also visible to the network, and
a week ago came
http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines
the use of the extension field for classification of the traffic.

/Karl

Från: [email-masked] [mailto:[email-masked]] För Dan Wing
Skickat: den 12 oktober 2013 02:35
Till: Ted Hardie
Kopia: [email-masked]
Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

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?

* Several operating systems do not allow non-privileged applications to set
DSCP bits at all; Windows, for example.  Yes, I know everyone is supposed to
use any other OS, but Linux has also only allowed certain DSCP values to be
set.

* When joining a network, the DSCP values for the network cannot be learned
or discovered -- we lack a protocol to do that.  The RFCs that define DSCP
values are not standards (they are informational) and many a network choose
their own values.  

* Setting the correct DSCP value affects only outgoing traffic but has no
influence on the incoming traffic.  As you stated in a later post, incoming
DSCP isn't trusted anyway.  "Reflexive DSCP Policy" was attempted years ago
to allow the network to assume a host's DSCP settings could be applied to
the other direction, but it was rejected I believe during IETF review but I
couldn't find record why it was actually disposed (document was
draft-ietf-ieprep-reflexive-dscp).

-d

Ted

The classical solution: avoid the problem by having a webrtc server in your
local network which does policy enforcement/QoS priorisation etc, and
interconnects to some other webrtc server with a standardized protocol like
SIP or XMPP. Popular in RTCWEB, less popular elsewhere..

The DHCP way: let the browser learn about the policy enforcement elements
through DHCP, it may communicate them to the server. This has some problems.
There are no widely adopted DHCP APIs, and the policy enforcement elements
may be unwilling to let some random web server access them.

Wolfgang Beck

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: [email-masked]
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth variation
of screencast (semi-static with sudden, large changes) is completely
different from that of a talking head, which is again completely different
from a high-movement scene.

If you need to know the bandwidth or the priority up front, the application
has to tell you. Anything else is pure heuristics.

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 22 Oct 2013 16:36:59 +0200

See my comments below. The problem of having to know a first STUN server in order to use DNS discovery, makes the suggestions below less good.

Another idea came up; to use anycast to allow a WebRTC browser to find a network provided TURN server (both local on a LAN or provided by a carrier). (There are some discussion around using anycast in the STUN and TURN RFCs.) This anycast-way should work both for a TURN server on a LAN and a TURN server outside the NAT/Firewall (any router in the chain can take care of an anycast address) and by the simple method below, return the available TURN server closest to the client. Finding a TURN server close to the client (the WebRTC browser) will also minimize “the turn” the real-time traffic has to take.  

The suggestion is to define an anycast IP address for STUN servers and:

- The network provider, offering a TURN server on his access, adds a route in his access router (or NAT/Firewall) so that the anycast address routes to his TURN/STUN server (a TURN server is an extension of STUN server, thus included in the same box).

- The TURN/STUN server is configured to respond to a binding request with a “300 Try alternate server”, that points out the same TURN/STUN server (by its real IP address, not the anycast address).

The WebRTC browser client would then:

- Issue a STUN binding request to the anycast address

- Issue another STUN binding request to the ALTERNATE SERVER IP address in the “300 Try alternate” response (as any client should do). 

- Interpret the received “300 Try alternate” response now having the same ALTERNATE SERVER IP address as the source IP address of that response, as an indication to use its TURN server (not the STUN server) at that address. 

That is the TURN server to use!

The only addition to existing standards is the interpretation above of the “300 Try alternate” response in the STUN RCF 5766 having the same ALTERNATE SERVER IP address as the source IP address of the response. It means: Use the TURN server at the specified address. That should be easy to clarify.

(The STUN server at the anycast address, may or may not be the same TURN/STUN server used in second binding request.) 

Authentication could simply be that the TURN/STUN server only is reachable from the IP addresses that the network provider want to support with the TURN server (easy for the network provider, since he is handing out those IP addresses).

This should be easy to provision for a carrier or a LAN administrator and trivial to try for the WebRTC browser.

An advantage is that the two STUN binding requests directly returns the TURN server address, whereby the following ICE process should be quick and easy. This could also be done only once when the browser is started or get a new IP address and cashed for later calls.

/Karl

PS If you wonder why not define an anycast address for a TURN server instead, read this thread from 2008:   <http://www.ietf.org/mail-archive/web/behave/current/msg03582.html> http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. There, the use of anycast to a TURN server is discussed, but found not to work. (Here anycast is only used for the first request to the STUN server, where after the real address to the TURN/STUN server is used.)

Från: Justin Uberti [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 8 oktober 2013 08:17
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl < <mailto:[email-masked]> [email-masked]> wrote:

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery.

I was hoping we could do something simpler, such as using the ISP's configured domain search list, to determine the domain.

 [Karl] But carriers don’t push out such things, do they? And if they could do it via DHCP we are back with those problems again.

/Karl

Från: Justin Uberti [mailto: <mailto:[email-masked]> [email-masked]] 
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

WPAD already supports DNS-based discovery (in addition to DHCP). If you have  <http://host-95-199-196-65.mobileonline.telia.com/> host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it will try to get a PAC file from  <http://wpad.mobileonline.telia.com> wpad.mobileonline.telia.com.

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl < <mailto:[email-masked]> [email-masked]> wrote:

/Karl

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" < <mailto:[email-masked]> [email-masked]> wrote:

 <http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx

 

/Karl

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 22 Oct 2013 16:37:18 +0200

Harald, I mostly agree with the quality requirements of different real-time
traffic that the WebRTC browser/application may use. But rather than asking
the application, let's convey the bandwidth and priority requirements to the
network. Just like with the Payload type (that is hard to squeeze that
information into) it must be visible to the network (and not changed by the
network, like diffserv bits are). Such marking must also be available for
incoming traffic, which is especially important in RSVP type of networks,
that has to reserve bandwidth for it.  

There is actually a good way to show these needs to the network (without
using the PT, or diffserv bits, which aren’t sufficient anyway). 

Let's use the RTP header extension field that also is visible outside the
encrypted payload. A week ago came
http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00  that
outlines the usage of the extension field for classification of traffic!
This document does not yet outline what to put in there and how to encode it
though.

Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses
other webrtc usages of the RTP header extension in 5.2 (there can be many
header extensions according to RFC 5285) and in 9 there is "WebRTC Use of
RTP: Future Extensions".

So, it looks obvious to use the RTP header extension to show the
characteristics and bandwidth requirements to the network. It should not
introduce any backward incompatibilities either.

Such marking is done in every RTP packet so it can be set individually for
each stream and could even be changed during a session (e.g. when limiting
the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP
extension header usage can be negotiated in SDP. I think this could be
easily done by the WebRTC browser for "all current and future needs" if
properly specified now.

I suggest that two parameters (e.g. two bytes each) are encoded into the RTP
header extension:

A) The maximum bandwidth requirement: Two bytes could contain everything
from some bps for real-time text to Gbps for future 3D supersize
telepresence… on a logarithmic scale.

B) The quality characteristics for the stream, with the highest bit set to
1, we could allocate a bit each quality e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay
Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery,
Prioritize X, Variation Y, that could be combined as required to describe
the stream.

And with highest bit set to 0, there could instead be a number for special
usage that does not fit the general description of the individual bits.

Please note the totally different requirements a diffserv and an RSVP
network have to know, so let’s put all into these bytes. (E.g. a diffserv
network don't need the bandwidth usage, but RSVP reservation networks (e.g.
cable and 3G/4G OTT) do. There one should initially reserve the maximum
bandwidth indicated, but can later re-reserve.)

/Karl

PS Microsoft seems to have done work in this field, defining a proprietary
attribute “MS Service Quality”; 

However that seems to apply to the TURN server allocation request and would
therefore:

--- Apply to the whole UDP flow, and could not be set for each stream
individually (with different requirements), and

--- Does not handle the bandwidth requirement for incoming real-time traffic
(required to reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may  be
considered.

This is 2.2.2.19 MS-Service Quality Attribute from 

http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx 

MS-Service Quality Attribute

The MS-Service Quality attribute is used to convey information about the
data stream that the protocol client is intending to transfer over an
allocated port. The protocol client SHOULD<21> include this attribute as
part of an Allocate request message. A TURN server SHOULD use the
information in this attribute to make decisions about resource allocation,
bandwidth prioritization, and data delivery methods. If the attribute is not
present in the Allocate request message, the TURN server SHOULD assume that
the data stream is audio with best effort delivery. The format of this
attribute is as follows... 

...

The following stream types are supported in this extension. All other stream
types are reserved for future use.

§ "0x0001": Audio

§ "0x0002": Video

§ "0x0003": Supplemental Video

§ "0x0004": Data

Service Quality (2 bytes): The service quality level required by the
protocol client for the stream.

The following service quality levels are supported in this extension. All
other service quality levels are reserved for future use.

§ "0x0000": Best effort delivery.

§ "0x0001": Reliable delivery.

-----Ursprungligt meddelande-----

Från: [email-masked] [mailto:[email-masked]] För Harald
Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: [email-masked]

>> I think you need to more carefully consider what are the goals you 

>> try to

> With diffserv you don’t need to know the bandwidth requirement, but 

rtcweb mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/rtcweb>
https://www.ietf.org/mailman/listinfo/rtcweb