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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 4 Sep 2013 16:23:41 +0000

We would like to start a working group last call of draft-ietf-rtcweb-use-cases-and-requirements-11.

Please send comments by the end of the day on September 21. 

Thank you, 

The chairs ….

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 5 Sep 2013 08:45:36 +0000

> Please send comments by the end of the day on September 21.

In the current version (-11) we've not addressed Andrew Hutton's input 
on handling the case with a FW that only allows traffic via a HTTP Proxy 
[1].

This should be fixed for the next version.

[11] http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2013 14:00:45 +0200

Hi,

I have reviewed the Use Case and Requirements draft (v11) in the WG last
call. I have the following comments on this document. I have found a
number of issues that I definitely needs to be fixed prior to any
publication request.

1. First of all I like to bring up a document structure problem. When
reviewing this it is difficult to follow what requirements that are
added for the different use cases. I would propose that each Use Case or
general section that describe something that causes new requirements
that hasn't been listed yet in the document to define the Requirement
there. Something like this:

3.2.2.1.  Description

   This use-case is almost identical to the Simple Video Communication
   Service use-case (Section 3.2.1).  The difference is that one of the
   users is behind a NAT that blocks UDP traffic.

3.2.2.2.  Derived Requirements

   F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28

   A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12

   New Requirement:

   F29     The browser must be able to send streams and
           data to a peer in the presence of NATs that
           block UDP traffic.

This makes the incremental use cases much more understandable in how
they add requirements.

This I think will also affect Section 3.1 which will need to include the
requirement definitions created by these general considerations.

However, I do suggest that you leave the collection of all requirements
in place for easy reference.

2. Section 1:

   The document focuses on requirements related to real-time media
   streams and data exchange.  Requirements related to privacy,
   signalling between the browser and web server etc. are currently not
   considered.

I think this needs to be rewritten. The draft actually do consider a
number of high level security and privacy concerns.

3. Section 2:

If you have no definitions, do remove the section, rather then leaving
it TBD.

4. Section 3.1

   o  Clients can be on wideband (10s of Mbits/sec)

   o  Clients can be on narrowband (10s to 100s of Kbits/sec)

Due to the usage of the terms wideband and narrowband I think you need
to be more explicit about what is actually referred to here. My
assumption is network throughput capability. And in these cases maybe
expressing this explicitly is a better choice.

5. Section 3.1:

   o  Clients can be on networks with any type (as described in RFC4787)
      of NAT.

I think "any type" is unclear here, as there are no types defined in
that RFC unless you are trying to express the difference between basic
NAT and NAPT, which I don't believe you are. I think you should use
something like this:

   o  Clients can be on networks with a NAT using any type of Mapping
      and Filtering behaviors (as described in RFC4787).

6. Section 3.2.1.1:

   It is essential that the communication cannot be wiretapped
   [RFC2804].

This sentence returns a number of times in this document. I think it is
a general security requirement that applies to probably all of the use
cases. If there is one use case that don't need to enable protection
against this, then please be explicit about that.

My Suggestion is to move this into the general considerations section.

7. Section 3.2.1.1:

   In addition, it is required that browsers enable the media and data
   security keys to be cryptographically bound to the user identity.

I think this sentence is actually subtly wrong in a couple of ways.
First of all it talks about "the identity", where I think it should be
talking about "a identity". This can both the human users identity, but
also a role identity, like Police Officer.

Secondly, binding it to  the security keys without putting requirements
on the keying and key-exchange mechanism to prevent man in the middles
empties this requirement. I would recommend that you reformulate this to
a high level requirement without going into mechanism. For example:

In addition, it is required that browsers enables binding an identity of
the user's choice to his end of the secured communication and that such
mechanism prevent man in the middle attacks.

8. Section 3.2.1.1

   One user has an unreliable Internet connection.  It sometimes loses
   packets, and sometimes goes down completely.

I guess the requirement here is to handle this in a graceful way from
media transport and rendering perspective. The packet loss is also
unclear as I don't know if the intention is to capture spurious packet
losses due to the link media, or congestion losses. I think some
expansion of this is needed.

9. Section 3.2.1.1:

   One user is located behind a Network Address Translator (NAT).

What is the point being stressed here that isn't covered by the general
consideration in 3.1 that says:

   o  Clients can be on networks with any type (as described in RFC4787)
      of NAT.

Section 3.2.2.2:

3.2.2.2.  Derived Requirements

   F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F29

   A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12

How come this list of Derived Requirements are shorter than for the
parent use case which has the following list:

3.2.1.2.  Derived Requirements

   F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39

   A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26

If each use case is listing all the requirement then it needs to be
consistently done and actually list all that applies. If there are
requirements from the parent that doesn't apply that may even be worth
explicitly mentioning.

This comments applies to all use cases as there appears to be general
inconsistencies.

10. Section 3.2.3.1:

3.2.3.1.  Description

   This use-case is almost identical to the Simple Video Communication
   Service use-case (Section 3.2.1).  The difference is that one of the
   users is behind a FW that only allows http traffic.

If a firewall only allows HTTP traffic, then can we really assume that
the firewall administrator per default will accept WebRTC Media and Data
traffic?

I am far from certain of this, and think on a requirement level needs to
express a situation where the firewall administrator allows WebRTC
across its FW, or at least can easily configure a rule to block it. Thus
resulting in that any solution for this needs to be easily identifiable
and possible to block.

See also [email-masked] mailing list.

11. Section 3.2.8.1:

   But in addition to this, one of the users can share what is being
   displayed on her/his screen with a peer.  The user can choose to
   share the entire screen, part of the screen (part selected by the
   user) or what a selected applicaton displays with the peer.

Does this needs mentioning of additional high level security requirements?

12. Section 3.2.10.1:

  The service providers are interconnected by some means, but exchange
   no more information about the users than what can be carried using
   SIP.

   NOTE: More profiling of what this means may be needed.

The Note, can it be removed, or do we need additional text in this document?

13. Section 3.2.10.1:

   The same issues with connectivity apply.

I don't understand this comment. What is it intended to refer to?

14. Section 3.2.11.1:

   Before the game starts, and during game breaks, the talent scout and
   the manager have a 1-1 audiovisual communication session.  Only the
   rear facing camera of the mobile phone is used.  On the display of
   the mobile phone, the video of the club manager is shown with a
   picture-in-picture thumbnail of the rear facing camera (self-view).
   On the display of the desktop, the video of the talent scout is shown
   with a picture-in-picture thumbnail of the desktop camera (self-
   view).

I get a bit confused with what is the front and rear of my smart phone.
I would consider the display side the front side, and the rear the other
big side of my block shaped mobile phone. I suggest using other terms.

15. Section 3.2.14.1:

   Discussion: This use-case was briefly discussed at the Quebec webrtc
   meeting and it got support.  So far the only concrete requirement
   (A17) derived is that the application must be able to ask the browser
   to treat the audio signal as audio (in contrast to speech).  However,
   the use case should be further analysed to determine other
   requirements (could be e.g. on delay mic->speaker, level control of
   audio signals, etc.).

I think this Discussion points needs to be dealt with before we can
publish this document. I would consider the question if this needs more
analysis a open issue.

16. Section 3.3.2.1:

   Alice uses her web browser with a service that allows her to call
   PSTN numbers.  Alice calls 1-800-gofedex.  Alice should be able to
   hear the initial prompts from the fedex IVR and when the IVR says
   press 1, there should be a way for Alice to navigate the IVR.

Can you please expand IVR.

17. Section 3.3.3.1:

   The organization has an internal network set up with an aggressive
   firewall handling access to the Internet.  If users cannot physically
   access the internal network, they can establish a Virtual Private
   Network (VPN).

I think the requirements or limitations the above paragraph try to
express is not clear. There is some missing assumptions of location of
server related to clients that is not covered. Thus it is not clear what
requirements this results in.

Can you please expand this to something that is understandable.

18. Section 3.3.3.1:

   This use-case adds requirements on support for fast stream
   switches F7, on encryption of media and on ability to traverse very
   restrictive FWs.

Regarding the restricted FWs, my comment 10) applies to also this comment.

19. Section 4.2:

   F14     The browser must be able to measure the level

   F15     The browser must be able to change the level
           in audio streams.

Can you please make explicit what type level you think should be
measured or changed, energy, "voice activity"?

20. Section 4.2

  F19     Streams and data must be able to pass through
           limited middleboxes.

What type of limitations are you considering in this requirement?

21. Section 4.2

I note that F30, and F36 may be affected by earlier comments on the
underlying reason for these requirements and need additional text or
clarifications.

22. Section 4.2:
   F37     The browser must be able to send streams and
           data to a peer in the presence of FWs that only
           allows http(s) traffic.

I think this requirement should have a caveat along the lines: when FW
policy allos WebRTC traffic.

23. Section 5:

Change the TBD to a statement that there are no IANA actions in this
document.

24. Section 6.2:

These security considerations are really security requirements on the
browser or the API. I don't know if would be better to move them to
relevant use case sections, or leave them in place.

25. Section 7:

   13.  Enable company coop without being able to decipher http://
        www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html

What is "coop" in the above?

26. Please run a spell checker on the document prior to submitting the
update.

27. Ensure that the ID nits issues are not real issues:

  == Line 667 has weird spacing: '...resence  of NA...'

  == Line 785 has weird spacing: '...of that  strea...'

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: Bernard Aboba <[email-masked]>
Date: Tue, 17 Sep 2013 14:32:11 -0700

I agree with Magnus's comments in large part.  A few notes: 

> there....>> This makes the incremental use cases much more understandable in how> they add requirements.

[BA] +1 on this.  I found myself flipping back and forth between the requirements definition and the use cases to try to understand what the incremental functionality was and sometimes it was less than obvious why a requirement (such as "no wiretapping") was dropped from the basic use case.  To me, it makes more sense to lay out basic use cases, and then to focus on incremental requirement additions based on that.  
> number of high level security and privacy concerns.
[BA] I do think the document covers the security and privacy concerns (modulo some issues I had with the "wiretapping" definition).  So I think we can eliminate that last sentence entirely. 
> against this, then please be explicit about that.>> My Suggestion is to move this into the general considerations section.

[BA] There is a use case ("distributed music band") that omits the requirement, but that omission didn't make sense to me.  Personally, I would elevate this to a universal requirement in the base use case, and all other cases. 
> expansion of this is needed.

[BA] To me, connectivity loss and packet loss are somewhat different issues.  Connectivity loss leads to addition of requirements relating to keep-alives and/or consent (e.g. if the peer drops off the Internet, the consent mechanism will detect it eventually and stop sending).   Packet loss leads to requirements relating to concealment, FEC and/or RTX.  So lumping them together doesn't make sense to me.  > 3.2.2.2.  Derived Requirements
> parent use case which has the following list:

[BA] Yes, that didn't make sense to me either.  Better to stick with the requirements of the base case and add to them as necessary for more advanced cases.  If something is deleted, I think the document needs to explain why, but in this case the deletions didn't make sense to me. 
> the firewall administrator per default will accept WebRTC Media and Data

[BA]  Data traffic sent as SCTP/DTLS/UDP will *not* work in this case.  Websockets might, but then I think you need to clarify whether "HTTP only" includes websockets (in my experience, in most cases it won't). 
> Does this needs mentioning of additional high level security requirements?

[BA]  The requirements may need to be *very* high level (e.g. "without introducing other vulnerabilities"), because this is a tricky area that may end up requiring significant work. 
> The Note, can it be removed, or do we need additional text in this document?
[BA] The NOTE tells me that we're not even really sure why this section is there.  So perhaps we should figure out what it adds above and beyond the gateway use case.

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 20 Sep 2013 17:43:42 +0200

For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets the
TURN server address from the web application, or gets it configured by a LAN
admin via an “admin policy template”.  

However, there is a need (motivations below) for the TURN server address to
be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, and
the OTT channel in mobiles have their own method I’ve been told). Simply
put, just as you often get your IP-address, DNS address, etc. automatically
from the network access, you should also get the TURN server address.

I suggest the following is added to the end of use case (which today is
about multiple TURN servers)
3.2.4.  Simple Video Communication Service, global service provider
3.2.4.1.  Description
...
"A network service provider must be able to automatically supply a TURN
server addresses to the browser when accessing a network. The address may
come via DHCP or a similar mechanism (maybe RA - Router Advertisement - for
IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whatever
method the mobile OTT channels use). The mechanism should be similar to
automatically getting the IP-address, DNS address, etc.. and need extensions
to current recommendations/standards. 

There are several reasons for a network service provider to supply a TURN
server as part of his offered access:
- to keep media paths short, specifically not sending media outside its own
network to some distant application provided TURN server
- to support mobility, i.e. you may want to move from a LAN with a
configured TURN server to accessing via WiFi or 3G/4G OTT channels 
- to offer a media path with better quality (than best effort data traffic).
Getting “WebRTC-ready” access and we look forward to telepresence for
everyone.

An enterprise network that want to keep a restrictive firewall not allowing
UDP traffic, could provide a real-time path using a TURN server paralleling
the firewall, instead of tunneling RTP through always open http or https
ports resulting in RTP media over TCP – with severe quality problems from
TCP retransmissions of dropped packets. The TURN server address is most
easily provided in the same way as the IP address and DNS address. (That
would also put the right party in control – The network provider decides
what is allowed on his network.)

This browser should select which available TURN server address to use in the
following priority order, where ICE could be used to try several:

1) TURN server address configured in the browser by the user (special cases,
normally not used) 
2) TURN server address configured by the network administrator via an “admin
policy template”
3) TURN server address supplied by DHCP or similar automatic network method 
4) TURN server address being supplied by the web application"

Two new requirements can be extracted:
"   ----------------------------------------------------------------
   F40     The browser must support retrieving TURN server addresses via
DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, an
addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the
mobile OTT channels use). The mechanism should be similar to automatically
getting the IP-address, DNS address, etc..
   ----------------------------------------------------------------
   F42     This browser should select which available TURN server address to
use in the following priority order, where ICE could be used to try several:

1) TURN server address configured in the browser by the user (special cases,
normally not used) 
2) TURN server address configured by the network administrator via an “admin
policy template”
3) TURN server address supplied by DHCP or similar automatic network method 
4) TURN server address being supplied by the web application   
----------------------------------------------------------------"

I suppose this also will add to:
5.  IANA Considerations
   TBD

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Cullen
Jennings (fluffy)
Skickat: den 4 september 2013 18:24
Till: [email-masked]
Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

We would like to start a working group last call of
draft-ietf-rtcweb-use-cases-and-requirements-11.

Thank you, 

The chairs ….

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 20 Sep 2013 17:57:38 +0000

> resulting in that any solution for this needs to be easily identifiable

Stefan already stated that this use case will be changed to take account of my comments in http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So the "only allows HTTP traffic" is going to be removed and changed to describe the use case when the firewall requires traffic to flow via a HTTP Proxy. 

We also have a use case when a network specific TURN server is deployed (3.2.5.1).

In both cases I agree that a network administrator must have a way to block webrtc but there are various ways of achieving this including just configuring the browser not to do webrtc, normal HTTP black/white lists, and also I can imagine solutions based on putting something in the HTTP Connect sent to the proxy so the proxy can block it. 

So I agree that it must be possible to block webrtc traffic but we need to careful not to specify the solution in the use case.  

Andy

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 23:17:22 +0200

I'm very hesitant to add more requirements that translate to "new 
protocol needs to be developed, implemented and deployed across the 
network before the requirement is useful".

In this case, it's "only" a DHCP option, but what new DHCP options do we 
have that have become widely used in the last 10 years?

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 21 Sep 2013 00:11:30 +0200

I want to point out that all methods suggested for RTP media through
firewalls that do not allow UDP traffic, by using "always open" https port
443 (or http port 80) result in tunneling RTP media over TCP. That gives
with severe quality problems from TCP retransmissions of dropped media
packet packets. Do we really want that for WebRTC?

A quality wise better solution is already pointed out in use case 3.2.5.1
mentioned below:
"An enterprise that uses a RTCWEB based web application for communication
desires to audit all RTCWEB based application session used from inside the
company towards any external peer. To be able to do this they deploy a TURN
server that straddle the boundary
between the internal network and the external"
 
I suggest the following is added to that use case:
"Such TURN server allows a media path, separated from the usually data
crowded enterprise Internet access, offering superior quality. This is a
better way to enable WebRTC on a network behind a restrictive firewall not
allowing UDP traffic, instead of tunneling RTP through always open http or
https ports resulting in RTP media over TCP – with severe quality problems
from TCP retransmissions of dropped packets. 

Such network administrator provided auditing TURN server would also put the
right party in control – The network administrator decides what is allowed
on his network."

Why should a network administrator that wants to block webrtc media, have to
do more than just closing his firewall for UDP, like below suggested
"configuring the browser not to do webrtc, normal HTTP black/white lists,
and solutions based on putting something in the HTTP Connect sent to the
proxy so the proxy can block it"?

Another thing in the second half of the same use case 3.2.5.1: 
Are NAT/firewalls inside the enterprise network assumed? If not, I think the
second half can be deleted.

" In cases where employees are using RTCWEB applications provided by an
   external service provider they still want to have the traffic to stay
   inside their internal network and in addition not load the straddling
   TURN server, "

ICE establishes a direct connection in this case, not using any TURN server
at all, doesn’t it? This is then not a problem.

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Hutton,
Andrew
Skickat: den 20 september 2013 19:58
Till: Magnus Westerlund; Cullen Jennings (fluffy); [email-masked];
[email-masked]
Ämne: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On: 17 September 2013 13:01 Magnus Westerlund Wrote:
> the firewall administrator per default will accept WebRTC Media and 
> Data traffic?
> 
> I am far from certain of this, and think on a requirement level needs 
> to express a situation where the firewall administrator allows WebRTC 
> resulting in that any solution for this needs to be easily 
> identifiable and possible to block.
> 

Stefan already stated that this use case will be changed to take account of
my comments in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So the
"only allows HTTP traffic" is going to be removed and changed to describe
the use case when the firewall requires traffic to flow via a HTTP Proxy. 

We also have a use case when a network specific TURN server is deployed
(3.2.5.1).

In both cases I agree that a network administrator must have a way to block
webrtc but there are various ways of achieving this including just
configuring the browser not to do webrtc, normal HTTP black/white lists, and
also I can imagine solutions based on putting something in the HTTP Connect
sent to the proxy so the proxy can block it. 

So I agree that it must be possible to block webrtc traffic but we need to
careful not to specify the solution in the use case.  

Andy

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Sep 2013 17:09:39 -0700

> have that have become widely used in the last 10 years?

[BA] And of those, which ones are supported by *browsers*?
 
I do think it is useful for a browser to be able to locate a local TURN server, if this is to happen it will need to be done at the application layer, not via DHCP.

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 21 Sep 2013 02:16:23 +0200

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: Marc Abrams <[email-masked]>
Date: Fri, 20 Sep 2013 18:32:57 -0700

Hi, Bernard:

Even hard phones can use "WebRTC" and DHCP options for programming so
having a DHCP option for pointing the phone at a local TURN server makes
sense.

Marc.

On Fri, Sep 20, 2013 at 5:09 PM, Bernard Aboba <[email-masked]>wrote:

> I do think it is useful for a browser to be able to locate a local TURN
> server, if this is to happen it will need to be done at the application
> layer, not via DHCP.
>

-- 

____________________
+1-949-270-0935

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 21 Sep 2013 23:44:27 +0200

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)?
Or can we at least split dynamic payload types PT:96-127 into groups for
audio and video codecs?

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?

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

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Karl
Stahl
Skickat: den 21 september 2013 02:16
Till: [email-masked];
[email-masked]
Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

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:

And in API requirements:

3.2.6.  Simple Video Communication Service, access change 3.2.6.1.
Description ...

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 22 Sep 2013 00:29:26 +0200

This is an ICE network infrastructure request (rather than WebRTC specific)
so I am copying MMUSIC.

Harald Alvestrand said: 
> I'm very hesitant to add more requirements that translate to "new protocol
needs to be developed, implemented and deployed across the network before
the requirement is useful".
--- Who isn't? Still the need is there, especially for network providers to
offer TURN servers with their accesses (see below). And worse, it is not 
> "only" a DHCP option
--- it is: "DHCP or a similar mechanism (maybe RA - Router Advertisement -
for IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or
whatever method the mobile OTT channels use)"
--- But for the browser it is a trivial thing to implement - Just use the
DHCP provided TURN server address suggested. 

The burden to get the standards done fall on others...

There were some comments seeing the need for local TURN-servers (where there
are other possibilities than the "automatic DHCP", see below), but I want to
stress the importance of allowing network providers to offer TURN servers
with their accesses. That is why I call it a "WebRTC-ready" broadband
access. 

I've heard several carries expressing that they want to provide their own
TURN servers with their accesses. The reason has both been to avoid that
media unnecessarily is sent outside their own network to some remote TURN
server and for quality reasons. The quality reason is especially important
e.g. in cable operator networks, using bandwidth reservation (RSVP) type of
QoS. They need to get hold of the RTP media streams and reserve bandwidth
for them and can do that by enforcing a TURN server at the access to be
used, and that TURN server can classify and reserve the bandwidth. (They do
these things for POTS 3.5kHz voice - They certainly need it for telepresence
capable WebRTC.) 

I think we should be happy and encourage carrier's interest to supply a high
quality path for RTC traffic, here WebRTC. (That is a different attitude
than e.g. trying to block Skype.)

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Karl
Stahl
Skickat: den 20 september 2013 17:44
Till: 'Cullen Jennings (fluffy)'; [email-masked]
Ämne: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

about multiple TURN servers) 3.2.4.  Simple Video Communication Service,
global service provider 3.2.4.1.  Description ...

/Karl

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

Thank you, 

The chairs ….

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 21 Sep 2013 23:14:03 +0000

The use case draft section 3.2.5.1 states

"It mustbe possibele to configure the browsers used in the enterprise with  network specific STUN and TURN servers.  This should be possible to achieve by autoconfiguration methods."

I had assumed that this meant using the browser configuration scripts in the same way as the browser would discover the HTTP Proxy I can see that DHCP is also an option which might be useful but I am not sure whether browsers would use it.

Andy

From: [email-masked] [[email-masked]] on behalf of Bernard Aboba [[email-masked]]

Sent: Saturday, September 21, 2013 1:09 AM

To: Harald Alvestrand; [email-masked]

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

---

From: "Marc Abrams" <[email-masked]>
Date: Sat, 21 Sep 2013 16:26:44 -0700 (PDT)

But phones and ATAs and other IoT devices would.

Marc 

________________
+1-949-270-0935

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 21 Sep 2013 23:40:37 +0000

See below.

________________________________________
From: Karl Stahl [[email-masked]]
Sent: Friday, September 20, 2013 11:11 PM
To: Hutton, Andrew; 'Magnus Westerlund'; 'Cullen Jennings       (fluffy)'; [email-masked]; [email-masked]
Subject: SV: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[AndyH] This is not about which is the better solution it is simply describing use cases. One in which the network administrator is aware of WebRTC and deploys mechanisms to deal with it and one in which there is no administrator or network specific mechanism for handling WebRTC media.  I think the use case in which there is no network specific TURN server will be at least in the near term by far the most common use case and therefore we need mechanisms to deal with it and it is a valid use case.

[AndyH] This does not sound like use case text to me it is comparing solutions to different use cases.

[AndyH] The use case of most concern is the one where there is no network administrator and we need WebRTC to work in those environments by default if that means an administrator who is WebRTC aware has to go to a little effort to block it then I think that is ok.

/Karl

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

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 21 Sep 2013 23:44:06 +0000

Agreed.

So it may be needed but the rtcweb use case draft is about browser requirements.

Andy

________________________________
From: Marc Abrams [[email-masked]]
Sent: Sunday, September 22, 2013 12:26 AM
To: Hutton, Andrew
Cc: [email-masked]; Harald Alvestrand; Bernard Aboba
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

Marc
________________
+1-949-270-0935

On Sat, Sep 21, 2013 at 4:14 PM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:

Andy

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 11:13:36 +0200

+1

Shouldn't we add it as a requirement also?

Best regards
Sergio

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 23 Sep 2013 09:28:07 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Saturday, September 21, 2013 5:40 AM
To: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 [TR] The other way to locate local TURN servers could be to use DNS-Based Service Discovery.

-Tiru.

---

From: "cb.list6" <[email-masked]>
Date: Mon, 23 Sep 2013 09:58:01 -0700

> configured TURN server to accessing via WiFi or 3G/4G OTT channels

I have not read the draft but would like to make it clear that no 2g/3g/4g
provider uses dhcp over the mobile network so this dhcp solution would not
apply.

CB

---

From: Dan Wing <[email-masked]>
Date: Mon, 23 Sep 2013 10:57:09 -0700

> 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

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 23 Sep 2013 21:57:47 +0200

CB > I have not read the draft but would like to make it clear that no
2g/3g/4g provider uses dhcp over the mobile network so this dhcp solution
would not apply. 

[Karl] True, my proposed requirement was: 

> The browser must support retrieving TURN server addresses via DHCP or a
similar mechanism (maybe RA - Router Advertisement - for IPv6, an
addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the
mobile OTT channels use).

“or whatever method the  mobile OTT channels use”

is of course not proper language – 3G/4G do provide IP and DNS addresses by
some method and the same is proposed for a network provided TURN server
address.

Actually, it is up to the OS to retrieve, and the browser should only use it
for its ICE implementation.

If (hopefully) such network provided TURN server addresses becomes
available, the next suggested browser requirement becomes important:

> The browser should select which available TURN server address to

I believe step 2) and 4) is implemented in Chrome today

/Karl

 

Från: cb.list6 [mailto:[email-masked]] 
Skickat: den 23 september 2013 18:58
Till: Karl Stahl
Kopia: [email-masked]; Cullen Jennings (fluffy)
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

CB

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Tue, 24 Sep 2013 02:14:26 +0000

Hi Karl, 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Karl Stahl
>Sent: Saturday, September 21, 2013 8:16 AM
>To: [email-masked];
>Subject: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>

>opportunity to only accept audio in a video call invitation.
[Xin] it is a common use case to accept only audio call and reject the video and quite useful. But I am doubt that this function should be mixed with video or audio device access permission . Do I misunderstand your proposal?  I think we could just disable the video stream when signaling. So we could make video call with one and reject it with other in the same web-service. I think the audio and video device access permission is not for each call(peer connection). 

Thanks,
   Xin

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Sep 2013 22:00:18 -0700

Dan Wing said: 
"Another solution is MALICE which adds information to the ICE connectivity checks (bandwidth, drop preference, etc.) which can be DPI'd by network devices."
[BA]  I am fairly keen on adding some of this information to ICE, though not to assist DPI.   Rather, my concern is that with SDP being optional in WebRTC, some of the info that would otherwise be exchanged in the signaling channel may not be present, and if present, cannot necessarily be trusted, so that putting this into the ICE exchange has potential security value.  Also, in a situation where TURN servers are rented in the cloud, it can be useful to signal the maximum bandwidth that could be used for a given allocation.  To my mind, the issue to be fixed in the TURN REST API wasn't necessarily the ability to steal credentials, but the ability to misuse those credentials in a way that could impose significant cost on the victim.  The act of mis-using a TURN credential does not by itself impose that cost -- but pumping huge amounts of traffic through it would.

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 24 Sep 2013 09:03:54 +0200

-----Ursprungligt meddelande-----
Från: Chenxin (Xin) [mailto:[email-masked]] 
Skickat: den 24 september 2013 04:14
Till: Karl Stahl; [email-masked];
[email-masked]
Ämne: RE: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl, 
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Karl Stahl
>Subject: [rtcweb] WGLC of 
>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.
>
>
>[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:
>browser for permission to use cameras and microphones, individually as 
>input devices. (One must be able to answer with voice only - declining
video.)

>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 
[Xin] it is a common use case to accept only audio call and reject the video
and quite useful. But I am doubt that this function should be mixed with
video or audio device access permission . Do I misunderstand your proposal?
I think we could just disable the video stream when signaling. So we could
make video call with one and reject it with other in the same web-service. I
think the audio and video device access permission is not for each call(peer
connection). 

Thanks,
   Xin
[Karl] Try using a WebRTC application with Chrome and you will see: The
Permission/Allowance to use Camera and Microphone comes up at a bar at the
top of the browser window and is the actual answering of a call.

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Tue, 24 Sep 2013 11:55:34 +0000

Hi Karl,
>top of the browser window and is the actual answering of a call.

[Xin] yes, it come up because invoking the getUserMedia API. When we write the webrtc app, we could call getUserMedia API just once and use the same mediaStream later. The webrtc app could decide to send the video stream to the other side or not by configure the signaling(SDP or other).  It is trivial to click the Permission bar at the top every time when I get a call, even terrible when join a p2p conference. 
That is the reason I think the use case you mentioned should not mix with permission, which should be a signaling configuration problem. Now in Chrome,we could control it by using creatOffer or createAnswer and setting the OfferToReceiveVideo constraint. 

Thanks,
   Xin

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 24 Sep 2013 22:08:38 +0200

-----Ursprungligt meddelande-----
Från: Chenxin (Xin) [mailto:[email-masked]] 
Skickat: den 24 september 2013 13:56
Till: Karl Stahl; [email-masked];

Hi Karl,
>>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.
>>
>>
>>video (even if a camera is enabled). A user may also select to 
>>initiate an audio session, without video.
>>
>>And in API requirements:
>>and microphone. [Suggest adding] Specifically, a user must be given 
>>the opportunity to only accept audio in a video call invitation.
>>
>[Xin] it is a common use case to accept only audio call and reject the 
>video and quite useful. But I am doubt that this function should be 
>mixed with video or audio device access permission . Do I misunderstand
your proposal?
>I think we could just disable the video stream when signaling. So we 
>could make video call with one and reject it with other in the same 
>web-service. I think the audio and video device access permission is 
>not for each call(peer connection).
>
>Thanks,
>   Xin
>Permission/Allowance to use Camera and Microphone comes up at a bar at 
>the top of the browser window and is the actual answering of a call.

[Xin] yes, it come up because invoking the getUserMedia API. When we write
the webrtc app, we could call getUserMedia API just once and use the same
mediaStream later. The webrtc app could decide to send the video stream to
the other side or not by configure the signaling(SDP or other).  It is
trivial to click the Permission bar at the top every time when I get a call,
even terrible when join a p2p conference. 
That is the reason I think the use case you mentioned should not mix with
permission, which should be a signaling configuration problem. Now in
Chrome,we could control it by using creatOffer or createAnswer and setting
the OfferToReceiveVideo constraint. 

Thanks,
   Xin
[Karl] If you permit the Browser to use the camera, then later "answer with
only audio in the application" (as I understand you suggest) - Can we trust
that the application isn't sending our video anyway - not even informing us?

I don't think we can trust any video WebRTC application, but will learn to
only trust well known browsers not to view us, when we don't want to be
seen.

Isn't this a necessary security thing?

/Karl

---

From: Dan Wing <[email-masked]>
Date: Tue, 24 Sep 2013 17:10:06 -0700

On Sep 23, 2013, at 10:00 PM, Bernard Aboba <[email-masked]> wrote:

> [BA]  I am fairly keen on adding some of this information to ICE, though not to assist DPI.   Rather, my concern is that with SDP being optional in WebRTC, some of the info that would otherwise be exchanged in the signaling channel may not be present, and if present, cannot necessarily be trusted, so that putting this into the ICE exchange has potential security value.  Also, in a situation where TURN servers are rented in the cloud, it can be useful to signal the maximum bandwidth that could be used for a given allocation.  

Yes, bandwidth is part of Microsoft's extensions to TURN as I'm sure you are aware (but others are probably not aware), http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx

The advantage of allowing routers along the path to see the bandwidth is they can influence their routing decisions to put the traffic on a better path (e.g., 3G versus microwave link versus satellite), prioritize the traffic, and do other things.  If the network always has sufficient bandwidth and thus no need to differentiate traffic, I agree there is no value and no purpose to tell the network anything.

> To my mind, the issue to be fixed in the TURN REST API wasn't necessarily the ability to steal credentials, but the ability to misuse those credentials in a way that could impose significant cost on the victim.  The act of mis-using a TURN credential does not by itself impose that cost -- but pumping huge amounts of traffic through it would. 

-d

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 25 Sep 2013 04:56:30 +0000

On desktop OS, it is very hard for an application like a browser to learn any information that was passed via DHCP to the host. This has long been a problem for things like geopriv. 

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. 

On Sep 23, 2013, at 9:58 AM, cb.list6 <[email-masked]> wrote:

> I have not read the draft but would like to make it clear that no 2g/3g/4g provider uses dhcp over the mobile network so this dhcp solution would not apply.
> 
> CB
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 25 Sep 2013 08:15:16 +0200

Thanks for the pointer!

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?

(public-stable, a term I just invented, includes independent RFC, info
RFC and standards-track)

-- 
Surveillance is pervasive. Go Dark.

---

From: Dan Wing <[email-masked]>
Date: Wed, 25 Sep 2013 08:36:31 -0700

On Sep 24, 2013, at 11:15 PM, Harald Alvestrand <[email-masked]> wrote:

> all the SIP channels are encrypted).

An additional difficulty, even if the SIP signaling is un-encrypted, is on complex (enterprise) networks the SIP signaling path and media path may go over different network equipment.  Our existing customers solve that problem by ensuring their network topology forces the paths to be congruent, but forcing such a network topology has other disadvantages (link costs go up, and becomes difficult to design around link failure).

> Is there a chance that we could get

We recently published http://tools.ietf.org/html/draft-martinsen-mmusic-malice which does something similar.  We are not married to those exact bits-on-the-wire, but we see value in the signaling for both the network and the end hosts (such as the TURN server).

-d

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 26 Sep 2013 01:38:20 +0200

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Skickat: den 25 september 2013 06:56
Till: cb.list6
Kopia: Karl Stahl; <[email-masked]>
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of

> On desktop OS, it is very hard for an application like a browser to learn
any information that was passed via DHCP to the host. This has long been a
problem for things like geopriv. 
[Karl] A WebRTC browser must be far beyond "a simple application". How can
it otherwise see and hear us, send RTP over UDP, do ICE and other advanced
stuff? It must already hook deep into the OS, so that in itself cannot be a
problem if the OS would know about such a handy thing as a network provided
TURN server...

[Karl] The problem is how will Network Provider can tell the OS about the
TURN server he provides together with his access: One of our developers
actually came up with a way of doing that WITHOUT my "provided via DHCP (and
maybe RA - Router Advertisement - for IPv6, and the OTT channel in mobiles
have their own method I’ve been told)"! I'll come back tomorrow to explain
(asked him to write a few line so I can convey correctly).

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

On Sep 23, 2013, at 9:58 AM, cb.list6 <[email-masked]> wrote:

> > For NAT/Firewall traversal WebRTC uses ICE, where the browser today 
> > gets the TURN server address from the web application, or gets it 
> > configured by a LAN admin via an “admin policy template”.
> >
> > However, there is a need (motivations below) for the TURN server 
> > address to be provided via DHCP (and maybe RA - Router Advertisement 
> > - for IPv6, and the OTT channel in mobiles have their own method 
> > I’ve been told). Simply put, just as you often get your IP-address, 
> > DNS address, etc. automatically from the network access, you should also
get the TURN server address.
> >
> > I suggest the following is added to the end of use case (which today 
> > is about multiple TURN servers) 3.2.4.  Simple Video Communication 
> > Service, global service provider 3.2.4.1.  Description ...
> > "A network service provider must be able to automatically supply a 
> > TURN server addresses to the browser when accessing a network. The 
> > address may come via DHCP or a similar mechanism (maybe RA - Router 
> > Advertisement - for IPv6, an addition to the IPCP protocol like 
> > RFC1877 for PPPoE, or whatever method the mobile OTT channels use). 
> > The mechanism should be similar to automatically getting the 
> > IP-address, DNS address, etc.. and need extensions to current
recommendations/standards.
> >
> > There are several reasons for a network service provider to supply a 
> > TURN server as part of his offered access:
> > - to keep media paths short, specifically not sending media outside 
> > its own network to some distant application provided TURN server
> > Getting “WebRTC-ready” access and we look forward to telepresence 
> > for everyone.
> >
> > An enterprise network that want to keep a restrictive firewall not 
> > allowing UDP traffic, could provide a real-time path using a TURN 
> > server paralleling the firewall, instead of tunneling RTP through 
> > always open http or https ports resulting in RTP media over TCP – 
> > with severe quality problems from TCP retransmissions of dropped 
> > packets. The TURN server address is most easily provided in the same 
> > way as the IP address and DNS address. (That would also put the 
> > right party in control – The network provider decides what is 
> > allowed on his network.)
> >
> > This browser should select which available TURN server address to 
> > 1) TURN server address configured in the browser by the user 
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via 
> > an “admin policy template”
> > DHCP or a similar mechanism (maybe RA - Router Advertisement - for 
> > IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or 
> > whatever method the mobile OTT channels use). The mechanism should 
> > be similar to automatically getting the IP-address, DNS address, etc..
> > 1) TURN server address configured in the browser by the user 
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via 
> > an “admin policy template”
> > Från: [email-masked] [mailto:[email-masked]] För 
> > Cullen Jennings (fluffy)
> > Ämne: [rtcweb] WGLC of

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 26 Sep 2013 12:45:33 +0200

> problem if the OS would know about such a handy thing as a network provided

All OSes have APIs. These APIs are controlled by the OS vendor.
Most of the information that's common across the relevant platforms is 
the information encapsulated in the POSIX standard (which is the base 
for both *BSD and Linux, which again form the basis for Android, MacOS 
and Linux).

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

Please don't talk about what "must be". Talk about what is. And if you 
don't know what is, ask.

---

From: <[email-masked]>
Date: Thu, 26 Sep 2013 12:06:29 +0000

Hi,

> 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

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 26 Sep 2013 12:59:06 +0000

Hi karl,

>From: Karl Stahl [mailto:[email-masked]]
>Sent: Wednesday, September 25, 2013 4:09 AM
>To: Chenxin (Xin); [email-masked];
>only audio in the application" (as I understand you suggest) 
[Xin] this is the function of PeerConnection API in W3C. 

- Can we trust
>Isn't this a necessary security thing?
[Xin] I agree with you that the app is possible to steal user's video or audio stream. 
But it is still hard to controI if the stream from getUserMedia could be used by other call(peerconnection) as designed in API now.

What I want to say is that the permission to access the device is orthogonal to consent to transmit the media to whom. The first one is for a site. The second one is for a user, it could be guaranteed by other ways, such as identity, media-encryption and so on, which need other consent method. 

 There are some details in http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.2.1

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 26 Sep 2013 17:27:16 +0200

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

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

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 26 Sep 2013 17:47:48 +0200

Hi Xin,
> permission to access the device is orthogonal to consent to transmit the
media to whom....

Thanks for the draft pointer, but what about the common usage that I pass
you a link: "Click here so we can discuss further", You click and run _my_
application och you are prompted by your browser to permit Mic&Camera, and
get no further option at all to restrict to only voice?

Doesn't _the browser_ really have to show an "Only Mic"-permission also,
i.e. three buttons "Deny", "Video Call", "Voice Call"?

/Karl

-----Ursprungligt meddelande-----
Från: Chenxin (Xin) [mailto:[email-masked]] 
Skickat: den 26 september 2013 14:59
Till: Karl Stahl; [email-masked];

Hi karl,

>Subject: SV: [rtcweb] WGLC of 
>Ämne: RE: [rtcweb] WGLC of 
>>>browser for permission to use cameras and microphones, individually 
>>>as input devices. (One must be able to answer with voice only - 
>>>declining
>>video.)
>>[Karl] Try using a WebRTC application with Chrome and you will see: 
>>The Permission/Allowance to use Camera and Microphone comes up at a 
>>bar at the top of the browser window and is the actual answering of a
call.
>
>[Xin] yes, it come up because invoking the getUserMedia API. When we 
>write the webrtc app, we could call getUserMedia API just once and use 
>the same mediaStream later. The webrtc app could decide to send the 
>video stream to the other side or not by configure the signaling(SDP or 
>other).  It is trivial to click the Permission bar at the top every 
>time when I get a call, even terrible when join a p2p conference.
>That is the reason I think the use case you mentioned should not mix 
>with permission, which should be a signaling configuration problem. Now 
>in Chrome,we could control it by using creatOffer or createAnswer and 
>setting the OfferToReceiveVideo constraint.
>
>Thanks,
>   Xin
>[Karl] If you permit the Browser to use the camera, then later "answer 
>with only audio in the application" (as I understand you suggest)

- Can we trust
>I don't think we can trust any video WebRTC application, but will learn 
>to only trust well known browsers not to view us, when we don't want to 
>be seen.
>
[Xin] I agree with you that the app is possible to steal user's video or
audio stream. 
But it is still hard to controI if the stream from getUserMedia could be
used by other call(peerconnection) as designed in API now.

What I want to say is that the permission to access the device is orthogonal
to consent to transmit the media to whom. The first one is for a site. The
second one is for a user, it could be guaranteed by other ways, such as
identity, media-encryption and so on, which need other consent method. 

 There are some details in
http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.2.1

---

From: "cb.list6" <[email-masked]>
Date: Thu, 26 Sep 2013 16:05:56 -0700

> 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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 26 Sep 2013 23:55:45 +0000

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 08:58:25 -0700

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:

> from

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 27 Sep 2013 19:47:08 +0200

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?

/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

> 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

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Fri, 27 Sep 2013 19:44:00 +0000

What is the usual "business model" for this? Assume in most cases the servers are hosted by folks who actually have a revenue stream from the app that is leveraging the servers.

Do we have some idea as to how the browser folks want to pay for the "WebRTC turn tax"?

On Sep 27, 2013, at 11:58 AM, Justin Uberti <[email-masked]> 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:
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 14:42:21 -0700

The business model is the same as for HTTP proxies. ISPs or enterprises
that want to better control their traffic will pay.

On Fri, Sep 27, 2013 at 12:44 PM, Jeremy Laurenson (jlaurens) <
[email-masked]> wrote:

> What is the usual "business model" for this? Assume in most cases the
> servers are hosted by folks who actually have a revenue stream from the app
> that is leveraging the servers.
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 28 Sep 2013 15:53:12 -0700

Actually, Windows does provide an API for this exact purpose, it's just not
particularly well-suited to what geopriv needed, i.e. getting changing
values. It is good enough for the purpose we are taking about. That isn't
much help for other operating systems, I'll concede.

Applications can send their own DHCP requests...maybe. You need to listen
on port 69 (from memory) for which you have to have the usual special
dispensation, and you have to compete with the OS DHCP agent. It's not
pretty either way.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Sep 2013 17:40:46 -0700

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!

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sun, 29 Sep 2013 00:49:40 +0000

Why not have this at least optionally specified in JavaScript in the browser? This way those who "own" the apps have control and aren't relying on correct implementation of others (necessarily)

On Sep 28, 2013, at 8:41 PM, "Bernard Aboba" <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <[email-masked]<mailto:[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

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

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 1 Oct 2013 02:13:15 +0200

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:

is the right way to go.

reinvent this wheel.

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <

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

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

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

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:

/Karl