Subject: [rtcweb] Where to specify ICE usage and the common transport

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Jul 2012 09:00:57 +0200

WG,

We chairs have identified that we currently we are missing specification
text for one of the key components of RTCWEB. This component is how
WebRTC uses ICE and defines the datagram transport that both the
DTLS/SCTP data channel uses and the RTP session.

Such a specification would most likely contain the following:

- How ICE is used in the WebRTC context
- Inclusion of STUN, TURN, TURN-TCP
- Inclusion of any defined "HTTP fallback"
- Description of the data transport in general and specifically how one
  can separate the traffic from the data channel and RTP session.
- Requirements on the signalling and API and what configuration data is
  needed.

My personal view is that this is best served by having its own
specification. Alternatives that exist is to include it either in the
data channel or RTP usage specifications.

Thus we chairs would appreciate feedback on at least two things:

- Is specifying this in its own specification the most suitable approach

- Do we have any volunteers for writing such a specification?

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: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 4 Jul 2012 07:36:33 +0000

|- Is specifying this in its own specification the most suitable 
|approach

Yes, IMO. I think it would ensue we get enough focus on this key component.

|- Do we have any volunteers for writing such a specification?

Please count me in. I think it makes sense to merge the consent freshness specification (draft-muthu-behave-consent-freshness) with the ICE usage for WebRTC.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
|Sent: Wednesday, July 04, 2012 12:31 PM
|To: [email-masked]
|Subject: [rtcweb] Where to specify ICE usage and the common transport
|
|WG,
|
|We chairs have identified that we currently we are missing specification
|text for one of the key components of RTCWEB. This component is how
|WebRTC uses ICE and defines the datagram transport that both the
|DTLS/SCTP data channel uses and the RTP session.
|
|Such a specification would most likely contain the following:
|
|- How ICE is used in the WebRTC context
|- Inclusion of STUN, TURN, TURN-TCP
|- Inclusion of any defined "HTTP fallback"
|- Description of the data transport in general and specifically how one
|  can separate the traffic from the data channel and RTP session.
|- Requirements on the signalling and API and what configuration data is
|  needed.
|
|My personal view is that this is best served by having its own
|specification. Alternatives that exist is to include it either in the
|data channel or RTP usage specifications.
|
|Thus we chairs would appreciate feedback on at least two things:
|
|- Is specifying this in its own specification the most suitable approach
|
|- Do we have any volunteers for writing such a specification?
|
|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]
|----------------------------------------------------------------------
|
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jul 2012 09:44:19 -0700

Reading the message below, it is not clear to me whether the items described fit into a single document. 

I could see a document relating to ICE in the WebRTC context.  This would include material on liveness, consent, STUN/TURN/TURN-TCP, and HTTP fallback.  I would also like to see it cover a bit about flag usage, and perhaps an analysis of some of the ICE security issues that Eric brought up at the Interim.  

Overall, the document should retain compatibility with RFC 5245 as much as possible, not defining new (and non-backward compatible) functionality. 

If the material about data transport is unrelated to ICE, then it might better belong in the data channel document. 

Similarly with respect to API, signaling or configuration material.  

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 6 Jul 2012 05:29:59 +0000

> On 04/07/12 1:06 PM, "Muthu Arul Mozhi Perumal (mperumal)"
><[email-masked]> wrote:

>Please count me in. I think it makes sense to merge the consent freshness
>specification (draft-muthu-behave-consent-freshness) with the ICE usage
>for WebRTC.

Please count me also in. As one of the authors of consent draft even I
would also be interested in seeing a specification on ICE usage for webRTC.

Regards,
Ram

---

From: "Sunyang (Eric)" <[email-masked]>
Date: Fri, 6 Jul 2012 06:25:35 +0000

Do we really need this?
If we start a new specification about ICE, do we need integrate the final part of ICE specification with JSEP, this will need extra work to make them meet.

Yang
Huawei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Ram Mohan R (rmohanr)
发送时间: 2012年7月6日 13:30
收件人: Muthu Arul Mozhi Perumal (mperumal); Magnus Westerlund; [email-masked]
主题: Re: [rtcweb] Where to specify ICE usage and the common transport

Regards,
Ram

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Jul 2012 09:29:50 +0200

> Do we really need this? 

That is part of what I am trying to determine.

> If we start a new specification about ICE, do
> we need integrate the final part of ICE specification with JSEP, this
> will need extra work to make them meet.

My personal understanding of the relations are the following

The basic functionality is to establish functional datagram transport
flow or flows (depending on signalling) between WebRTC peers. The
established datagram transport flow is used by the RTP session(s),
DTLS-SRTP key-management establishment and SCTP over DTLS.

The last part points to that we have 2 or 3 (depending on how you see
DTLS-SRTP) users of the datagram transport flow. As co-author of one of
those documents I would like to have a single point to reference.

There is also the issue of ensuring that they can all operate on the
same datagram flow. This however has been reduced to be STUN, RTP and
DTLS. Where DTLS must separate DTLS-SRTP messages from the regular DTLS
protected data flow which contains SCTP packets. But, the first is
actually well described in the DTLS-SRTP spec.

When it comes to JSEP it clearly is the signalling part that enables the
establishment of the datagram transport flow. It is also crucial in the
maintenance of it, for example re-establishing in case of used
interfaces going down etc.

In this we also have the question about the ICE variant we intended to
use which supports trickle candidates. There are no IETF specification
for it. That appears to be needed to be created. This is not work for
this WG. The appropriate home for such work is most likely MMUSIC.

In addition we still have the need for someone to define what ICE and
what additional tools we need. We also have certain API requirements
from this. Like the configuration of STUN and TURN and any additional
relay like solution we have for the HTTP fallback.

It could be that JSEP spec is a good enough home for this. It might be
that we would get a better separation of work and cleaner referencing if
we create a separate specification.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Jul 2012 16:02:42 -0700

> this WG. The appropriate home for such work is most likely MMUSIC.

I fear that this is the case...

I don't think we actually need a new specification that defines
the consent testing, since AFAICT these are just configurable
parameters in the ICE spec. That said, we do need to write
a profile of that somewhere? Maybe we could turn draft-mutha
into that?

> relay like solution we have for the HTTP fallback.

Right. The API obviously has some support for the first two of these,
but any thoughts about how we would define the second from
a spec perspective? Is there a doc for it?

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jul 2012 21:31:32 -0700

> those documents I would like to have a single point to reference.

Why does your document need a reference to something that says if we have a UDP over HTTP mechanism or not? I'm worried that we are creating some ugly interdependencies in the layering that are not needed. 

I agree work is needed in MMUSIC for trickle ICE, but I'm still not seeing the rest of this. 

Obviously doing a UDP over HTTP or doing a TURN that looks like HTTP thing would need a spec. That will be highly controversial at IETF given it is fundamentally about doing something through a firewall that directly go against the wishes of the firewall administrator.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Jul 2012 10:36:54 +0200

Hi,

BUNDLE is going to contain some ICE text, related to multiplexing.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Thursday, July 12, 2012 7:31 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [rtcweb] Where to specify ICE usage and the common transport

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 12 Jul 2012 11:22:39 +0200

Il giorno Wed, 11 Jul 2012 21:31:32 -0700
Cullen Jennings <[email-masked]> ha scritto:

> > The last part points to that we have 2 or 3 (depending on how you
> > see DTLS-SRTP) users of the datagram transport flow. As co-author
> > of one of those documents I would like to have a single point to
> > reference.
> 
> Why does your document need a reference to something that says if we
> have a UDP over HTTP mechanism or not? I'm worried that we are
> creating some ugly interdependencies in the layering that are not
> needed. 
> 
> Obviously doing a UDP over HTTP or doing a TURN that looks like HTTP
> thing would need a spec. That will be highly controversial at IETF
> given it is fundamentally about doing something through a firewall
> that directly go against the wishes of the firewall administrator. 
> 

Not necessarily: the spec may involve some stuff to allow
network/firewall administrators to tell if that's RTP over HTTP or
not. It doesn't have to be sneaky.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Jul 2012 12:02:21 +0200

> creating some ugly interdependencies in the layering that are not

I want to have something to reference that defines the datagram
transport the RTP uses. Independently if the actual datagrams are direct
ICE establish path or over any variety or combination of relays over
HTTP or not.

I personally think we do need something that sufficiently describing and
normatively specifying the datagram transport that both RTP and
DTLS/SCTP uses. This is after all usage of ICE, likely variant. The
requirement to support STUN and some TURN version. The requirement to
handle a varaint of the demultiplexing that DTLS-SRTP discusses due to
the simultanous occurrance of STUN, RTP and DTLS packets at the same
level in the stack.

Cheers

Magnus Westerlund