Subject: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

From: Justin Uberti <[email-masked]>
Date: Tue, 3 Jun 2014 08:51:11 -0700

The other thread has been hijacked by an ICE discussion, so reasking here.
Should use of DTLS be indicated by:
- UDP/TLS/RTP/SAVPF on the m= line
- RTP/SAVPF, and presence of an a=fingerprint line

Some have expressed a preference for RTP/SAVPF, as being more backwards
compatible. However, others have expressed a preference for
UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. The last time this came
up, in September 2013, the UDP/TLS/RTP/SAVPF proponents were able to
convince me to include this into jsep-06, so if we want to change it back,
I'd like to see a clear consensus.

On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Miniero <[email-masked]>
wrote:

> On Tue, 03 Jun 2014 10:32:43 +0200
> Sergio Garcia Murillo <[email-masked]> wrote:
>
> > On the other side, keeping "RTP/SAVFP" would have allowed a server
> > (SBC/MCU/etc) to send an offer without knowing in advance if the
> > other side supports SDES or DTLS, by sending both the crypto and
> > fingerprint attributes and let the receiver choose which one to use
> > (as chrome has done until recently). I know that it is not important
> > for webrtc, as DTLS is mandatory and SDES is a must not, but for
> > supporting other legacy clients it may be easier for some of us.
> >
> > Best regards
> > Sergio
> >
>
>
> I guess that was the rationale for having RTP/SAVPF in the first
> place, as initially both SDES and DTLS-SRTP were allowed. There are
> people confused about not having UDP/TLS/RTP/SAVPF now that DTLS-SRTP
> is mandatory (Asterisk developers, for instance, although getting it to
> work from a signalling point of view is a trivial replace matter in
> JavaScript), but I agree it makes sense to keep RTP/SAVPF, if not just
> because all browser implementations right now (the legacy of a few
> months from now on) only accept that, which would render them useless
> having this change.
>
> Lorenzo
>
>
>
> > El 03/06/2014 8:04, Justin Uberti escribió:
> > > I think there is value in specifying UDP/TLS/RTP/SAVPF, in that it
> > > unambiguously indicates the desire to do DTLS-SRTP. Otherwise, one
> > > has to guess at this from the presence of a=fingerprint, which
> > > seems dodgy, given that endpoints are free to ignore SDP attributes
> > > they don't understand.
> > >
> > > The fact that UDP and TLS appear in the m= line is kind of
> > > unfortunate, but I think it can be interpreted as "do DTLS-SRTP".
> > >
> > >
> > > On Mon, Jun 2, 2014 at 11:53 AM, Martin Thomson
> > > <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >     On 2 June 2014 10:13, Harald Alvestrand <[email-masked]
> > >     <mailto:[email-masked]>> wrote:
> > >     > The current implementations both send "RTP/SAVPF" in this
> > >     > field.
> > >     But this
> > >     > usage is not specified by RFC 5764.
> > >
> > >     Sounds easy to me.  The SDP doesn't matter and can say anything.
> > >     "RTP/SAVPF" is as good as any other sequence of octets.
> > >
> > >     I'm sure that JSEP can include a requirement that is directly
> > >     contradictory to an existing RFC.  That happens all the time.
> > > At least this time it can be explicit.
> > >
> > >     _______________________________________________
> > >     rtcweb mailing list
> > >     [email-masked] <mailto:[email-masked]>
> > >     https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 16:20:33 +0000

+1 for “UDP/TLS/RTP/SAVPF on the m= line”

Please don’t treat this like another hijacking attempt ☺ but, unfortunately the rationale for this is somewhat related to the ICE discussion.
RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 5124 mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport as usually UDP (alternative being DCCP).
So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these RFCs. More importantly DTLS-SRTP use of “UDP/TLS/RTP/SAVPF “ is clearly defined in RFC 5764.

Now the case of, “changing from default UDP to final TCP transport or vice-versa” for SRTP has to be handled per ICE RFC rules, which says c/m= lines should be consistent with the default destination. So, using “RTP/SAVPF” to cover all transports does not sound right to me, especially when browser has to update the SDP when final selected candidate and/or transport changes anyway.

http://tools.ietf.org/html/rfc5245#section-8.1.2

                    If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9<http://tools.ietf.org/html/rfc5245#section-9>.

BR
Raju

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Tuesday, June 03, 2014 10:51 AM
To: Lorenzo Miniero
Cc: [email-masked]
Subject: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

The other thread has been hijacked by an ICE discussion, so reasking here. Should use of DTLS be indicated by:
- UDP/TLS/RTP/SAVPF on the m= line
- RTP/SAVPF, and presence of an a=fingerprint line

Some have expressed a preference for RTP/SAVPF, as being more backwards compatible. However, others have expressed a preference for UDP/TLS/RTP/SAVPF, as that is what RFC 5763/4 says. The last time this came up, in September 2013, the UDP/TLS/RTP/SAVPF proponents were able to convince me to include this into jsep-06, so if we want to change it back, I'd like to see a clear consensus.
On Tue, Jun 3, 2014 at 2:08 AM, Lorenzo Miniero <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, 03 Jun 2014 10:32:43 +0200

Lorenzo

> > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >     On 2 June 2014 10:13, Harald Alvestrand <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jun 2014 17:27:12 +0000

+1 for “UDP/TLS/RTP/SAVPF”

Just for clarification, what is meant by “backward compatibility”? Usage of non-secure RTP? I thought we are not going to allow that.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Makaraju, Maridi Raju (Raju)
Sent: 03 June 2014 19:21
To: Justin Uberti; Lorenzo Miniero
Cc: [email-masked]
Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

BR
Raju

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Tuesday, June 03, 2014 10:51 AM
To: Lorenzo Miniero
Cc: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

Lorenzo

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jun 2014 10:26:36 -0700

I don't feel strongly about this either way. The original motivation for the
text in 5764 is that people in MMUSIC (not me particularlly) felt we
should be clear on the profile and that DTLS was a different profile. If
that sentiment has changed I would be happy to use RTP/SAVPF
(which is what FFOX uses now, I believe).

-Ekr

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 3 Jun 2014 20:29:32 +0200

On Tue, 3 Jun 2014 17:27:12 +0000

> Just for clarification, what is meant by “backward compatibility”? Usage of non-secure RTP? I thought we are not going to allow that.

When I mentioned "legacy", I talked about WebRTC implementations out in the wild today, and most importantly browsers. Current up-to-date implementations of Firefox and Chrome, which both use DTLS-SRTP, don't understand UDP/TLS/RTP/SAVPF and so would fail when faced with that in a negotiation. This might sound like a minor point, considering the autoupdate in most browsers that could have them aligned when the time comes, but you'd be surprised about how many older versions are still around that force applications to have to deal with all of them with polyfills and the like. This is especially true if we consider the beta vs. stable versions both Chrome and Firefox are making available.

Anyway, I agree this should not be a motivation for sticking to RTP/SAVPF. After all, the spec is not stable yet and more things are going to change anyway. Besides, most existing deployments still rely on SDES being available in Chrome, and so they'll be forced to update sooner or later when it disappears for good.

Lorenzo

-- 
Lorenzo Miniero, COB

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

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 18:42:00 +0000

> When I mentioned "legacy", I talked about WebRTC implementations out in the
> wild today, and most importantly browsers. Current up-to-date
> implementations of Firefox and Chrome, which both use DTLS-SRTP, don't
> understand UDP/TLS/RTP/SAVPF and so would fail when faced with that in a
> negotiation.

[Raju] 
Can't this be handled by browsers via handling RTP/SAVPF in setRemoteDescription (), in addition to UDP/TLS/RTP/SAVPF, for some more time and phase it out slowly? 

Also, createAnswer() will give back what is in the offer.
createOffer() will use UDP/TLS/RTP/SAVPF.

setLocalDescription () may not have to handle RTP/SAVPF for DTLS as applications typically don't mess with transport.

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 21:22:15 +0200

2014-06-03 18:20 GMT+02:00 Makaraju, Maridi Raju (Raju)
<[email-masked]>:
> Please don’t treat this like another hijacking attempt J but, unfortunately
> the rationale for this is somewhat related to the ICE discussion.
>
> RFC 2327 clearly says transport for RTP/AVP is UDP. RTP/SAVPF RFC 5124
> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport as
> usually UDP (alternative being DCCP).
>
> So, using RTP/SAVPF for DTLS-SRTP does not seem consistent with these RFCs.
> More importantly DTLS-SRTP use of “UDP/TLS/RTP/SAVPF “ is clearly defined in
> RFC 5764.
>
> Now the case of, “changing from default UDP to final TCP transport or
> vice-versa” for SRTP has to be handled per ICE RFC rules, which says c/m=
> lines should be consistent with the default destination. So, using
> “RTP/SAVPF” to cover all transports does not sound right to me, especially
> when browser has to update the SDP when final selected candidate and/or
> transport changes anyway.

I don't like the above, but I strongly agree with it. So:

- Initially use "UDP/TLS/RTP/SAVPF" as the RFC states.

- If the selected candidate (after ICE procedures) has a different
transport, then fire an event to tell the user about it. Something
like:
    onicestatechange(event)  where:
    - event.readyState="open"
    - event.selectedTransport = "TCP/TLS/RTP/SAVPF"
And in case the user calls getLocalDescription() it should retrieve a
SDP with m/c lines matching the transport and address of the selected
local candidate.

(well, I know there is zero interest on implementing that, but the
spec should say something like this in order to make SDP&ICE RFC's
happy).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Jun 2014 07:33:19 +0000

Hi,

>> Please don’t treat this like another hijacking attempt J but, 
>> unfortunately the rationale for this is somewhat related to the ICE discussion.
>>
>> mostly inherits that (and RTP/AVPF RFC 4585) and indicates transport 
>> as usually UDP (alternative being DCCP).
>>
>> More importantly DTLS-SRTP use of “UDP/TLS/RTP/SAVPF “ is clearly 
>> defined in RFC 5764.
>>
>> vice-versa” for SRTP has to be handled per ICE RFC rules, which says 
>> c/m= lines should be consistent with the default destination. So, 
>> using “RTP/SAVPF” to cover all transports does not sound right to me, 
>> especially when browser has to update the SDP when final selected 
>> candidate and/or transport changes anyway.
>
> - If the selected candidate (after ICE procedures) has a different transport, then fire an event to tell the user about it. Something
> like:
> And in case the user calls getLocalDescription() it should retrieve a SDP with m/c lines matching the transport and address of the selected local candidate.

Let's keep in mind that there are also other data (e.g. port) than the transport that may change as part of the ICE procedure.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Wed, 4 Jun 2014 14:48:58 -0700

count me out on this. I see no value in updating the m= line protocol
depending on the active protocol in use (e.g. UDP vs TCP).

I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF,
but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following
5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF
offer remains as an open question.)

On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg <
[email-masked]> wrote:

> SDP with m/c lines matching the transport and address of the selected local
> candidate.
>
> Let's keep in mind that there are also other data (e.g. port) than the
> transport that may change as part of the ICE procedure.
>
> Regards,
>
> Christer
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 4 Jun 2014 23:56:40 +0200

> offer remains as an open question.)

Question: do we have (or will have) a PC event telling us *which* ICE
candidate is the selected one? If so, those who want to play with the
"SDP rules" in RFC 5245 can be notified about the selected candidate
and can even play more by mangling the SDP to "update the default
media address" (after all, I think we all are used to mangle the SDP
with JavaScript...).

Wouldn't that be enough to satisfy all the needs?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jun 2014 15:02:28 -0700

> offer remains as an open question.)

This would be acceptable to me, but we probably should update 5764 to make
RTP/SAVPF legal as well.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jun 2014 00:12:16 +0200

> This would be acceptable to me, but we probably should update 5764 to make

Hi, my previous suggestion includes that the m= protocol field gets
"UDP/TLS/RTP/SAVPF" as defined by RFC 5764.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jun 2014 15:14:40 -0700

> "UDP/TLS/RTP/SAVPF" as defined by RFC 5764.

I prefer Justin's suggestion.

-Ekr

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 4 Jun 2014 22:15:41 +0000

count me out on this. I see no value in updating the m= line protocol depending on the active protocol in use (e.g. UDP vs TCP).
[Raju] I see there is a clear value in doing this:

1.       ICE RFC states c/m= lines should be updated to default destination for initial offer and sub-sequent offer (selected candidate). So, if createOffer() is called after ICE completed then browser has to update SDP to reflect this anyway. So, why not browser update SDP and fire an event about final candidate been selected? It can fire this event always or only when it is different from default candidate that was used on c/m= lines. Existing oniceconnectionstatechange () can be used as a trigger and application can inspect SDP to learn about the selected candidate.

2.       Some applications may want to know the selected candidate and transport for various reasons like:

-          Updating middle boxes for better QoS (not just for selected transport, but for selected ip, port). I believe this is the main reason why ICE RFC says (1) above.

-          Learning about the actual transport that is used, which may give clues about the underlying network (restrictive firewalls? wrong provisioning on home routers to not allow some type of UDP out?).
             Basically, we may come up with various other reasons, but IMHO the main point is, ICE candidate selection
             is an important event and application knowing the selected candidate will help do some interesting
             value added things.

I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are following 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF offer remains as an open question.)
[Raju] I think answer should have UDP/TLS/RTP/SAVPF else it will result in SDP O/A violation.

BR
Raju

---

From: Justin Uberti <[email-masked]>
Date: Wed, 4 Jun 2014 16:29:16 -0700

On Wed, Jun 4, 2014 at 3:15 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> *[Raju] I see there is a clear value in doing this:*
>
> *1.       *ICE RFC states c/m= lines should be updated to default
> destination for initial offer and sub-sequent offer (selected candidate).
> So, if createOffer() is called after ICE completed then browser has to
> update SDP to reflect this anyway. So, why not browser update SDP and fire
> an event about final candidate been selected? It can fire this event always
> or only when it is different from default candidate that was used on c/m=
> lines. Existing oniceconnectionstatechange () can be used as a trigger and
> application can inspect SDP to learn about the selected candidate.
>
> *2.       *Some applications may want to know the selected candidate and
> transport for various reasons like:
>
> -          Updating middle boxes for better QoS (not just for selected
> transport, but for selected ip, port). I believe this is the main reason
> why ICE RFC says (1) above.
>
> -          Learning about the actual transport that is used, which may
> give clues about the underlying network (restrictive firewalls? wrong
> provisioning on home routers to not allow some type of UDP out?).
>
>              Basically, we may come up with various other reasons, but
> IMHO the main point is, ICE candidate selection
>
> You could still do that. The question is whether the m= line needs to
explicitly include the protocol used by the active candidate pair.

> *[Raju] I think answer should have UDP/TLS/RTP/SAVPF else it will result
> in SDP O/A violation.*
>

Can you point me to the text that requires this? I looked in 3264 before,
but didn't see it.

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 4 Jun 2014 21:29:46 -0700

+1 on Justin's suggestion.

On Wed, Jun 4, 2014 at 4:29 PM, Justin Uberti <[email-masked]> wrote:

>> I suggest that we go ahead with Martin's suggestion of offering
>> RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are
>> following 5764 exactly. (What protocol is used in an answer to a
>> UDP/TLS/RTP/SAVPF offer remains as an open question.)
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jun 2014 07:06:09 +0000

Hi,

But, if you change the active protocol, isn’t it likely that you would also change the PORT, which would mean updating the m- line?

Or, is you assumption that you would use the same port for both UDP and TCP?

Also, aren’t there some SDP attributes which are used for TCP, but are not allowed for UDP?

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]]
Sent: 5. kesäkuuta 2014 0:49
To: Christer Holmberg
Cc: Iñaki Baz Castillo; Makaraju, Maridi Raju (Raju); [email-masked]
Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jun 2014 07:20:46 +0000

Hi,

>I suggest that we go ahead with Martin's suggestion of offering RTP/SAVPF, but also accept UDP/TLS/RTP/SAVPF for remote endpoints that are 
>following 5764 exactly. (What protocol is used in an answer to a UDP/TLS/RTP/SAVPF offer remains as an open question.)

I think the protocol used in the answer has to be "UDP/TLS/RTP/SAVPF". 

I think that is what 3264 says (i.e. the transport in in the offer and answer must match).

I also believe we have to keep the transport in any subsequent offer/answer.

Regards,

Christer

On Wed, Jun 4, 2014 at 12:33 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 12:12:07 +0000

You could still do that. The question is whether the m= line needs to explicitly include the protocol used by the active candidate pair.
[Raju1] You meant “you could still do that” using existing procedures? Currently I don’t think Chrome updates c/m= lines ip/port to match with final selected candidate.
Even if Chrome updates c/m= lines ip/port to match with selected candidate before firing oniceconnectionstatechange(), that may only be partially useful as knowing L4 transport protocol (TCP vs. UDP) is also important. I understand that knowing ip, port may allow application to scan candidate lines to find out if the transport is TCP or UDP. This is assuming TCP, UDP ports used are within the same space and unique; but this may not be true always as, unlike Chrome, Firefox (or other implementations) may have different address spaces for TCP, UDP and ports may overlap. In some cases knowing application protocol (SDES vs. DTLS) is also important. But, I agree that for WebRTC since SDES won’t be supported knowing TCP or UDP (for audio, video) is probably sufficient.

Can you point me to the text that requires this? I looked in 3264 before, but didn't see it.
[Raju1] Sorry for the relatively long answer.
I checked the RFC 3264 again looking for the exact requirement for this. You are right, I could not find exact relevant text for it. But, IMHO the matching transport in SDP O/A is so implicit (further explanation below) and looks like it was overlooked.RFC 3264 has this general statement:
6 Generating the Answer
   The answer to an offered session description is based on the offered
   session description.

One critical property of offered SDP is transport protocol. This determines the type of bearer transport (and # of ports) allocated and the application profile to be used on top of that. So, an extreme example of having UDP in offer and TCP in answer won’t work for sure. Or even TCP/MSRP in offer and TCP/TLS/MSRP in answer won’t work. So, IMHO I think a general but not so clearly written rule with SDP is transports have to match. But then none of the (S)AVPF or other RFCs describes any mention of compatible transports *for SDP O/A* when Layer 4 transport is different. RTP/SAVPF RFC http://tools.ietf.org/html/rfc5124#page-6 talks about RTP/SAVP and RTP/SAVPF can be mixed, but here the Layer4 transport is same and the application level RTP feedback profile is backward compatible with RTP. It (or any other RFCs) did not talk about mixing RTP/SAVPF, UDP/TLS/RTP/SAVPF and TCP/RTP/SAVPF. DTLS-SRTP RFC http://tools.ietf.org/html/rfc5763#section-7.1 goes in great lengths to make it a point to negotiate RTP/AVP vs UDP/TLS/RTP/SAVP via a=tcap capability from RFC 5939.

RFC 5939 recognized this problem and tries to solve it via a=tcap:

http://tools.ietf.org/html/rfc5939#section-1

   However, SDP does not address an increasingly important

   problem: the ability to negotiate one or more alternative transport

   protocols (e.g., RTP profiles) and associated parameters (e.g., SDP

   attributes).  This makes it difficult to deploy new RTP profiles such

   as Secure RTP (SRTP) [RFC3711<http://tools.ietf.org/html/rfc3711>], RTP with RTCP-based feedback

   [RFC4585<http://tools.ietf.org/html/rfc4585>], etc.  The problem is exacerbated by the fact that RTP

   profiles are defined independently.  When a new profile is defined

   and N other profiles already exist, there is a potential need for

   defining N additional profiles, since profiles cannot be combined

   automatically.  For example, in order to support the plain and Secure

   RTP version of RTP with and without RTCP-based feedback, four

   separate profiles (and hence profile definitions) are needed: RTP/AVP

   [RFC3551<http://tools.ietf.org/html/rfc3551>], RTP/SAVP [RFC3711<http://tools.ietf.org/html/rfc3711>], RTP/AVPF [RFC4585<http://tools.ietf.org/html/rfc4585>], and RTP/SAVPF

   [RFC5124<http://tools.ietf.org/html/rfc5124>].  In addition to the pressing profile negotiation problem,

   other important real-life limitations have been found as well.

   Keying material and other parameters, for example, need to be

   negotiated with some of the transport protocols, but not others.

   Similarly, some media formats and types of media streams need to

   negotiate a variety of different parameters.

BR
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 12:15:48 +0000

> I also believe we have to keep the transport in any subsequent offer/answer.
[Raju] This is not true. RFC 3264 clearly says transport can be changed in subsequent offer.

8.3.1 Modifying Address, Port or Transport
   The transport for a stream MAY be changed.  The process for doing
   this is identical to changing the port, except the transport is
   updated, not the port.

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jun 2014 15:12:08 +0200

Hi Makaraju,

I would really appreciate if you don't write your text in red color.
Comments inline:

> [Raju1] You meant “you could still do that” using existing procedures?
> Currently I don’t think Chrome updates c/m= lines ip/port to match with
> final selected candidate.

Of course not, and that is why "you could still do that" (in case we
get some PC event firing when the selected ICE candidate is paired, so
*you* can inspect it at JS level and mangle your SDP).

> Even if Chrome updates c/m= lines ip/port to match with selected candidate
> before firing oniceconnectionstatechange(), that may only be partially
> useful as knowing L4 transport protocol (TCP vs. UDP) is also important.

The candidate provides transport info.

> One critical property of offered SDP is transport protocol. This determines
> the type of bearer transport (and # of ports) allocated and the application
> profile to be used on top of that. So, an extreme example of having UDP in
> offer and TCP in answer won’t work for sure. Or even TCP/MSRP in offer and
> TCP/TLS/MSRP in answer won’t work. So, IMHO I think a general but not so
> clearly written rule with SDP is transports have to match.

Let's make things clear:

The m= and c= lines in the SDP was originally designed to indicate the
address, transport and protocol of a media stream within the SDP. The
addition of ICE modifies it because:

- ICE lines already contain transport and address information.

- There maybe multiple ICE candidates with different transports and addresses.

- The only remaining information to be provided is the "protocol",
this is: "RTC", "application", etc.

Said that, the c/m lines are still useful in case peer-A supports ICE
but peer-B does not, so they can perform "legacy" procedures based on
c and m line. THIS IS NOT the case in WebRTC where ICE is a *MUST*.

So honestly I don't think that the W3C should design an API (or make
it more complex) that makes happy old and legacy SDP procedures and
requirements.

In WebRTC, DTLS-SRTP is mandatory (and probably TLS-SRTP will also be
valid soon) so by looking at the ICE candidate transports the receiver
already know if DTLS or TLS is being used (per candidate). We DO NOT
need to signal "DTLS" or "TLS" anywhere else in the SDP, really.

Said that, and after re-thinking all of it a bit, I feel really
comfortable by using "RTP/SAVFP" as that is the *only* information
missing in order to know the nature of the stream: the "protocol". The
transports(s) and the address(es) are already indicated by the
connection parameters: the ICE candidates.

And yes, this "breaks RFC 5764 and 5245". But what it breaks is
useless and legacy and makes no sense in the context of WebRTC. So no
problem.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 13:48:04 +0000

> *you* can inspect it at JS level and mangle your SDP).
[Raju] As I mentioned earlier, how about when TCP and UDP port #s are same? Take a look at the following example. In this case how do you know the exact Layer 4 transport used?

m=audio 58612 RTP/SAVPF 0 100
a=candidate:3275585311 1 udp 2122260223 135.252.136.43 58612 typ host generation 0
a=candidate:2378075119 1 tcp 1518280447 135.252.136.43 58612 typ host generation 0 

>useless and legacy and makes no sense in the context of WebRTC. So no
[Raju] Why intentionally break it and add exceptions?!!
If we go in that direction and set wrong precedence to break RFC rules, then why not do any or all of the following to have a parallel webrtc universe?
- Just use "RTP" instead of "RTP/SAVPF" and assume DTLS-SRTP always.
- For data channel, just use "SCTP" instead of "SCTP/DTLS" and assume "DTLS" always.
We don't want to do that because webrtc respects and takes advantage of existing IETF RFCs.
IHMO, cherry picking is not a good idea... especially here where we don't have a strong case for it. I don't think FF to Chrome interop is a strong reason and I already suggested a way to have backward compatibility. IMHO, FF and Chrome should have used "UDP/TLS/RTP/SAVPF" for DTLS-SRTP from day 1; then we wouldn’t be having this discussion. 
I don't agree with the comment that "it's legacy"; it may not be prefect but since webrtc decided to adapt IETF STUN/ICE/SDP RFCs we should follow them with as few exceptions (zero should be the goal) as possible.

>it more complex) that makes happy old and legacy SDP procedures and
[Raju] As I mentioned before, we are not talking about a new API or making it more complex here. Existing API oniceconnectionstatechange () is sufficient to indicate the application about ICE completion. The extra stuff I am talking about is not API related, rather making SDP consistent with the selected candidate in an unambiguous way. 

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jun 2014 16:06:37 +0200

> a=candidate:2378075119 1 tcp 1518280447 135.252.136.43 58612 typ host generation 0

Assuming PeerConnection fires a new event
"oniceselectedcandidate(event)" and 'event' contains the selected
local ICECandidate, you get your transport from it (tcp or udp).

> [Raju] Why intentionally break it and add exceptions?!!

In some draft-rtcweb-xxxxxx:

"This document updates RFC 5764 and 5245 by stating that the m= line
does not need to indicate the transport but just the protocol (so
RTP/SAVPF) and blablabla".

> If we go in that direction and set wrong precedence to break RFC rules, then why not do any or all of the following to have a parallel webrtc universe?

Where must I sign?

> - Just use "RTP" instead of "RTP/SAVPF" and assume DTLS-SRTP always.

As said before in this thread (or in other), the "RTP/SAVPF" is just a
token. The only we need it to provide is the kind of protocol of the
stream ("RTP", "application"...).

> - For data channel, just use "SCTP" instead of "SCTP/DTLS" and assume "DTLS" always.

OK. But don't assume DTLS, as TLS may also take place.

> We don't want to do that because webrtc respects and takes advantage of existing IETF RFCs.

And that's why we are here talking about useless SDP legacy procedures
and requirements, which really, it is NOT an "advantage".

> IHMO, cherry picking is not a good idea... especially here where we don't have a strong case for it. I don't think FF to Chrome interop is a strong reason and I already suggested a way to have back…

Then the discussion about "updating the m line" would take place (in
case the selected ICE candidate uses TLS instead of DTLS).

The standards are wrong since ICE was added to the SDP. The m line no
longer is able to indicate a "transport", since that is now indicated
and chosen via ICE procedures, and there is zero value in updating a
currently useless field in the SDP legacy syntax.

> I don't agree with the comment that "it's legacy"; it may not be prefect but since webrtc decided to adapt IETF STUN/ICE/SDP RFCs we should follow them with as few exceptions (zero should be the go…

Unfortunately these kinds of "requirements" were not properly reported
when SDP was selected. Otherwise maybe we wouldn't be now debating
about this.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 14:27:33 +0000

Sorry Justin, I think we successfully hijacked your thread once again to make this discussion ICE-centric. :-) But, this time I think we have a more valid reason to do so. Hope you understand.

Please see comments inline.

> > [Raju] As I mentioned earlier, how about when TCP and UDP port #s are
> same? Take a look at the following example. In this case how do you know the
> exact Layer 4 transport used?
> >
[Raju] That's fine with me. But, IMO adding a new event data to oniceselectedcandidate() may be bit more heavier (changing API semantics) than updating the SDP and simply firing the event with no additional data.

But I am sorry, I still don't understand the rationale behind NOT updating local SDP to reflect current selected candidate. To me, this seems more straight forward solution than adding selected candidate to oniceselectedcandidate(). If browser does not update it, not only it violates the mentioned RFCs, but also application has to manipulate the SDP every time createOffer() is done. Why make it complicated for applications which want this consistency? I don't think updating the SDP breaks applications which do not require this consistency though as they don't care if it is RTP/SAVPF or UDP/TLS/RTP/SAVPF anyways.

BR
Raju

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Jun 2014 10:20:59 -0700

On Thu, Jun 5, 2014 at 7:06 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> same? Take a look at the following example. In this case how do you know
> the exact Layer 4 transport used?
> >
> > If we go in that direction and set wrong precedence to break RFC rules,
> then why not do any or all of the following to have a parallel webrtc
> universe?
>
> Where must I sign?
>
>
>

That's not correct. You use DTLS regardless of whether UDP or TCP
is used.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jun 2014 18:35:18 +0000

Hi,

>   this is identical to changing the port, except the transport is

True. I was thinking that the remote endpoint may not support "RTP/SAVPF", and that we for that reason should not change the transport.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 18:48:20 +0000

> True. I was thinking that the remote endpoint may not support "RTP/SAVPF",
> and that we for that reason should not change the transport.
[Raju] If remote endpoint does not support RTP/SAVPF then it will fail that offer then it falls back to having media per earlier successful SDP O/A.

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jun 2014 18:56:58 +0000

Hi,

> Let's make things clear:
>
> The m= and c= lines in the SDP was originally designed to indicate the address, transport and 
> protocol of a media stream within the SDP. The addition of ICE modifies it because:
>
> - The only remaining information to be provided is the "protocol", this is: "RTC", "application", etc.
>
> Said that, the c/m lines are still useful in case peer-A supports ICE but peer-B does not, so they can > perform "legacy" procedures based on c and m line. THIS IS NOT the case in WebRTC where ICE is a > *MUST*.
>
> So honestly I don't think that the W3C should design an API (or make it more complex) that makes > happy old and legacy SDP procedures and requirements.

So, perhaps we shouldn't use SDP in the API to begin with then?

But, wait a minute... We DID discuss that, and the conclusion was that we ARE going to use SDP :)

...

> And yes, this "breaks RFC 5764 and 5245". But what it breaks is useless and legacy and makes no 
> sense in the context of WebRTC. So no problem.

We have made other decisions in order for things to work with "legacy", e.g. by mandating that the first BUNDLE offer is sent with different port number values in each m- line - even when used within the context of WebRTC.

So, I think we should be consistent.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jun 2014 19:00:18 +0000

Hi,

>> True. I was thinking that the remote endpoint may not support 
>> "RTP/SAVPF", and that we for that reason should not change the transport.
>[Raju] If remote endpoint does not support RTP/SAVPF then it will fail that offer then it falls back to >having media per earlier successful SDP O/A.

True. But, what is the offerer going to do then? Send a new offer, with the "legacy" transport value?

That can be avoided by consistently using *A* value.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Jun 2014 20:28:11 +0000

> >[Raju] If remote endpoint does not support RTP/SAVPF then it will fail that
> offer then it falls back to >having media per earlier successful SDP O/A.
> 

[Raju] If the remote endpoint supports a particular transport triggered via ICE procedures then it should also support handling it when the transport is received via SDP offer directly. If the answerer rejects an offer (containing any change, not just transport change) then offerer has no option but to go back to previous state; if no previous state then the call will fail. This is how SDP O/A works and webrtc does support rollbacks too. 

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Jun 2014 07:20:00 +0000

Hi,

>>>[Raju] If remote endpoint does not support RTP/SAVPF then it will 
>>>fail that offer then it falls back to >having media per earlier successful SDP O/A.
>> 
> [Raju] If the remote endpoint supports a particular transport triggered via ICE procedures then it should also support handling it when the 
> transport is received via SDP offer directly. If the answerer rejects an offer (containing any change, not just transport change) then offerer 
> has no option but to go back to previous state; if no previous state then the call will fail. This is how SDP O/A works and webrtc does support rollbacks too. 

I know that, and again: not using "RTP/SAVPF" would prevent the offer from being rejected just because the remote user doesn't support "RTP/SAVPF", but the remote user otherwise DOES support whatever has been negotiated using ICE.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 6 Jun 2014 14:25:16 +0000

> > [Raju] If the remote endpoint supports a particular transport triggered
> via ICE procedures then it should also support handling it when the
> > transport is received via SDP offer directly. If the answerer rejects an
> offer (containing any change, not just transport change) then offerer
> > has no option but to go back to previous state; if no previous state then
> the call will fail. This is how SDP O/A works and webrtc does support
> rollbacks too.
> 
> I know that, and again: not using "RTP/SAVPF" would prevent the offer from
> being rejected just because the remote user doesn't support "RTP/SAVPF", but
> the remote user otherwise DOES support whatever has been negotiated using
> ICE.
[Raju] If WebRTC complies with RFCs and updates the SDP per selected candidate then webrtc compliant implementations (clients or middle boxes) should NOT fail the updated offer as the answerer did indicate earlier that it supports the selected transport (via SDP answer). If they do fail then they are NOT compliant.
Also, from application point of view there is no obligation to send a new updated offer unless the underlying network needs it.

BR
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sat, 7 Jun 2014 13:44:09 +0000

>That's not correct. You use DTLS regardless of whether UDP or TCP
[Raju] I agree with this. Not to nitpick, but I don't think draft-ietf-rtcweb-transports-04 makes this explicit, which says (3.4):
   "If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels."

TCP ICE RFC 6544 talks about doing RTP over TLS or DTLS. The above text simply says "RTP", should it clarify further to make it explicit like "DTLS-RTP"? Further clarification like "If bundling is used then both data channels and DTLS-SRTP may share same DTLS, else separate DTLS associations are used" may be useful.

BR
Raju

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 07 Jun 2014 19:14:54 +0200

> TCP ICE RFC 6544 talks about doing RTP over TLS or DTLS. The above text simply says "RTP", should it clarify further to make it explicit like "DTLS-RTP"? Further clarification like "If bundling is…

Clarification will be done. Proposed language appreciated.

We've all agreed to DTLS for everything since very far back.

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2014 16:41:38 +0200

Before this thread went off into varioius strange corners, I think we 
had consensus on the following:

- It's a token. It's not a specification.
- An ANSWER has the same transport token as the OFFER, if acceptable.
   So UDP/TLS/RTP/SAVPF in the offer gets a reply of UDP/TLS/RTP/SAVPF 
in the answer.
   Ditto for RTP/SAVPF if used.
- An updating OFFER has the same transport token as previously agreed.

so the only question we have is:

What should the initial OFFER sent by an RTCWEB-conformant browser contain?

There's a VERY weak compatibility argument with legacy devices for the 
longer string.
There's a VERY weak compatibility argument with deployed browsers for 
the shorter string.
 From the discussion, I don't see much basis for making choice; when I 
flipped a coin, it came up tails, but I'd forgotten to decide which was 
which.

So should we go with UDP/TLS/RTP/SAVPF, and call it a day?

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 9 Jun 2014 14:57:54 +0000

> So should we go with UDP/TLS/RTP/SAVPF, and call it a day?
+1

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 9 Jun 2014 17:16:18 +0200

On 09/06/14 16:41, Harald Alvestrand wrote:
>   So UDP/TLS/RTP/SAVPF in the offer gets a reply of UDP/TLS/RTP/SAVPF in
> the answer.

And there's a VERY weak compatibility argument with deployed non-browser
endpoints currently interworking with deployed browsers for the shorter
string.

> So should we go with UDP/TLS/RTP/SAVPF, and call it a day?

If there's no compelling reason for changing, can we save ourselves and
other people out there the hassle of fixing their parsers (easy) and
redeploying whatever works today (time-consuming and boring)?

It ain't broken, don't fix it!

Enrico

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Jun 2014 15:50:51 +0000

Hi,

>So should we go with UDP/TLS/RTP/SAVPF, and call it a day?

+1.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jun 2014 10:14:02 -0700

On Mon, Jun 9, 2014 at 7:41 AM, Harald Alvestrand <[email-masked]>
wrote:

> Before this thread went off into varioius strange corners, I think we had
> consensus on the following:
>
> There's a VERY weak compatibility argument with deployed browsers for the
> shorter string.
> I am opposed to this, for two reasons:
1) we aren't doing UDP/TLS/SCTP for data channel, so we're inconsistent
2) we're not going to do TCP/TLS/RTP/SAVPF (right?), so it's possibly
incorrect

RTP/SAVPF is similar in terms of how it describes the protocol to the
DTLS/SCTP format that data channel uses, and, as others have pointed out,
is also what existing browsers/apps are using.

So I would prefer to keep RTP/SAVPF as what WebRTC endpoints generate.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 Jun 2014 13:25:19 -0400

> So I would prefer to keep RTP/SAVPF as what WebRTC endpoints generate.

I would prefer to keep RTP/SAVPF as well - fewer things for me to fix or
worry about on the interop during the browser version transition.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 9 Jun 2014 17:47:20 +0000

>1) we aren't doing UDP/TLS/SCTP for data channel, so we're inconsistent
[Raju] That's because there are many application level protocols on top of SCTP data channels. Where as in case of DTLS-SRTP, there is only one protocol.

>2) we're not going to do TCP/TLS/RTP/SAVPF (right?), so it's possibly incorrect
[Raju] IMO, for TCP we should use something like "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". WebRTC may have to register this as RFC 6544 mentions use of DTLS over TCP but did not do registration.

>RTP/SAVPF is similar in terms of how it describes the protocol to the DTLS/SCTP >format that data channel uses, and, as others have pointed out, is also what existing >browsers/apps are using.
[Raju] IMHO, RTP/SAVPF is meant for a specific SRTP-SDES use of transport over UDP. So, it is not same as DTLS-SRTP over UDP. Existing browser apps are using it because both FF and Chrome started with it. If I understand correctly, one of the (main) reasons for Chrome/FF did that way is for easy negotiation between SRTP-SDES and DTLS-SRTP (or was it a bug? as initially accepted by Chrome). IMHO using the same reason now to keep status quo does not sound like a convincing reason to me.
 
BR
Raju

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2014 20:25:06 +0200

> [Raju] IMO, for TCP we should use something like "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". WebRTC may have to register this as RFC 6544 mentions use of DTLS over TCP but did not do registration.

IMO, we should not.

Repeat:
At the time of SDP negotiation, we have no idea whether a TCP or UDP
candidate will be chosen. The transport token merely serves to verify
that we agree on the transport token.

Renegotiating the transport token because of choices made in ICE is
wasteful and useless.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 9 Jun 2014 18:50:06 +0000

> > [Raju] IMO, for TCP we should use something like "TCP/TLS/RTP/SAVPF" or
> "TCP/DTLS/RTP/SAVPF". WebRTC may have to register this as RFC 6544 mentions
> use of DTLS over TCP but did not do registration.
> 
> IMO, we should not.
> 
> Repeat:
[Raju] Repeat from me as well: Per ICE RFC, the c/m= lines should reflect the default candidate. If default candidate changes later after ICE completion then c/m= lines should reflect this. Please see notes below as it does not mean new end to end SDP O/A for WebRTC use cases.

> Renegotiating the transport token because of choices made in ICE is
[Raju] Sorry, repeat again: I am not suggesting an end to end renegotiation. Rather, after ICE completes browser updates the local SDP c/m= line(s) to reflect the current selected candidate. It's up to the application to act upon transport change to send a new SDP offer or not. For some QoS needs sending new SDP offer, with updated c/m= lines, is the best choice and it adds value; WebRTC framework should allow it.
In earlier posts, I mentioned that such update not only serves the purpose of RFC compliancy but also allows applications to learn final selected candidate.

If we feel WebRTC just needs a token and not worry about compliancy to RFCs then why not simply register "DTLS-SRTP/SAVPF" (for example) and provide clear semantics and tie it to a=candidate lines?! This way, RTP/SAVPF use won't conflict with standard RFC definition of it (meant for SDES-SRTP).

Even if we go in this direction, the PeerConnection API should still allow applications to learn about the selected candidate for various reasons I listed in my earlier post(s).

BR
Raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 09 Jun 2014 21:26:11 +0200

+1

Best regards
Sergio

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jun 2014 19:18:26 -0700

On Mon, Jun 9, 2014 at 10:47 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> [Raju] That's because there are many application level protocols on top of
> SCTP data channels. Where as in case of DTLS-SRTP, there is only one
> protocol.
>

I don't buy this. If we don't care what the underlying transport is for the
data channel, we shouldn't care what it is for media.

However, if we decide that the transport token should reflect the in-use
transport protocol, I don't think that adds any additional signaling - the
app can already decide whether or not it wants to send an updated offer
with the correct default candidate in the m/c lines.

> DTLS/SCTP >format that data channel uses, and, as others have pointed out,
> is also what existing >browsers/apps are using.
> [Raju] IMHO, RTP/SAVPF is meant for a specific SRTP-SDES use of transport
> over UDP. So, it is not same as DTLS-SRTP over UDP. Existing browser apps
> are using it because both FF and Chrome started with it. If I understand
> correctly, one of the (main) reasons for Chrome/FF did that way is for easy
> negotiation between SRTP-SDES and DTLS-SRTP (or was it a bug? as initially
> accepted by Chrome). IMHO using the same reason now to keep status quo does
> not sound like a convincing reason to me.
>
> BR
> Raju
>
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 10 Jun 2014 13:40:48 +0000

>[Raju] That's because there are many application level protocols on top of SCTP data >channels. Where as in case of DTLS-SRTP, there is only one protocol.

>I don't buy this. If we don't care what the underlying transport is for the data >channel, we shouldn't care what it is for media.

[Raju] I agree that we need to be consistent with RTP and data channels.
After reading draft-ietf-mmusic-sctp-sdp-06, it seems to focus on RFC 4347 which uses UDP transport for DTLS/SCTP. The SCTP over TCP transport, especially with RFC 4571 framing, is not (yet) defined in this draft.

IMO, we need to use RTP/SAVPF or SCTP/DTLS per IETF semantics or define brand new WebRTC specific ones and provide transport independent semantics to it. Reuse with different semantics causes confusion and inconsistency.

>However, if we decide that the transport token should reflect the in-use transport >protocol, I don't think that adds any additional signaling - the app can already >decide whether or not it wants to send an updated offer with the correct default >candidate in the m/c lines.

[Raju] Yes, agreed. We also need to agree on a mechanism on when and how such update is done (update local SDP, before onicecandidate(NULL)?).

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jun 2014 13:52:13 +0000

Hi Harald,

>Repeat:
>At the time of SDP negotiation, we have no idea whether a TCP or UDP candidate will be chosen. The transport token merely serves to verify that we agree on the transport token.
>
>Renegotiating the transport token because of choices made in ICE is wasteful and useless.

I asked this before, and I apologized if I missed your reply: do you assume that the same port would be used for UDP and TCP?

If not, you would still have to "renegotiate" due to the port change - even if the transport token doesn't change.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 10 Jun 2014 17:35:44 +0200

> If not, you would still have to "renegotiate" due to the port change - even if the transport token doesn't change.

There is nothing to re-negotiate at signaling level. What for?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jun 2014 18:03:28 +0000

Hi,

>>>Repeat:
>>>At the time of SDP negotiation, we have no idea whether a TCP or UDP candidate will be chosen. >>>The transport token merely serves to verify that we agree on the transport token.
>>>
>> I asked this before, and I apologized if I missed your reply: do you assume that the same port would >> be used for UDP and TCP?
>>

The m= line contains the "transport token" - AND the port number.

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 10 Jun 2014 21:04:26 +0000

On: 09 June 2014 22:18 Justin Uberti Wrote:

> 
> However, if we decide that the transport token should reflect the in-
> use transport protocol, I don't think that adds any additional
> signaling - the app can already decide whether or not it wants to send
> an updated offer with the correct default candidate in the m/c lines.
> 

Totally agree that app needs to be in control of this. If the app does not care it should not have to send an updated offer that would just be very wasteful. If it does care then it should be able to decide to send the updated offer.

Andy

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Jun 2014 23:15:40 +0200

On 10. juni 2014 15:52:13 CEST, Christer Holmberg <[email-masked]> wrote:
>I asked this before, and I apologized if I missed your reply: do you
>assume that the same port would be used for UDP and TCP?
>
>If not, you would still have to "renegotiate" due to the port change -
>even if the transport token doesn't change.
>
>Regards,
>
>Christer

Even if you wanted the ports to be the same it is unlikely that you could get them consistently. Port change must be accommodated.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 10 Jun 2014 23:40:34 +0200

> The m= line contains the "transport token" - AND the port number.

So you are just quoting what the RFC says ("the SDP must be updated
once the stream has a winner ICE candidate"). Some points:

- The above does not require AT ALL that a new "SDP renegotiation" is
needed. In fact, SDP O/A was previously negotiated for ICE to work.
IMHO this is clear.

- The ICE RFC states that the SDP must be updated and so on. OK. It is
clear (IMHO) that the ICE spec should not mention SDP at all. And we
all agree that "sending a new SDP with the updated m/c line" is just
required for some QoS, B2BUAs or similar systems, and we all know that
this may make sense in certain signaling protocols (SIP and others),
but NOT in WebRTC where there is not a defined/mandated "signaling
protocol" at all (so in case the app wants to indicate the server its
winner ICE candidate it can do that in tons of ways).

- And at the end, IMHO it is clear that browser vendors are not going
to implement the "SDP update" mentioned in the ICE RFC because they
find it not useful (as it clearly is).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 11 Jun 2014 00:29:27 +0200

> winner ICE candidate it can do that in tons of ways).

I found this part of the RFC particular insightful:

    This begs the question -- why is the updated offer/answer exchange
    needed at all?  Indeed, in a pure offer/answer environment, it would
    not be.  The offerer and answerer will agree on the candidates to use
    through ICE, and then can begin using them.  As far as the agents
    themselves are concerned, the updated offer/answer provides no new
    information.

Best regards
Sergio

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 10 Jun 2014 23:50:16 +0000

>     themselves are concerned, the updated offer/answer provides no new

[Raju] I certainly don’t want to sound like a broken record  but I did post reasons for such SDP O/A.
I am copying that email here below. I also want to repeat here again that the requirement we impose on WebRTC API is for browser to update the local SDP per selected ICE-candidate and leave it up to the application to decide on sending a new SDP Offer or not. 

<Earlier-Post>
-----Original Message-----
From: Makaraju, Maridi Raju (Raju)
Sent: Tuesday, June 03, 2014 9:16 AM

...

[Raju] Such a new SDP O/A is needed for couple of reasons:
1. QoS: It is true that ICE client can do all inband without additional SDP
O/A.
   But there may be middle boxes in between that may apply QoS per the
changed
   ICE candidate(s). One such example is, when going from WiFi to LTE the
   network may provide better QoS via PCRF/PGW dedicated bearers. It can
only do
   so if it knows about the new media flow. Please note that the new media
flow may
   go thru completely new network elements who may not be aware of the old
   flow at all. Yes, one can provide a "costly" solution to solve this
problem
   by using DPI (and/or SDN), but such a solution is not only costly but
also complex.
   IMHO, webrtc should facilitate achieving necessary QoS desired for
sessions
   in the network. While doing so, I don't see any functionality being lost
at
   WebRTC, rather it's a gain and greater adaption of WebRTC.

   For the same reason, I also agree with the comment that, a new SDP O/A
must be sent
   if the selected candidate is not the one listed in c/m= lines.
   WebRTC should not assume that middle boxes don't exist. Middle boxes do
exist for
   Very valid reasons (not just SIP/IMS, which is only one example).
Especially with
   the trend towards SDN, the control plane and data/user plane are being
separated
   for good and the control plane needs triggers to reconfigure the network
for better
   QoS. Sending new O/A (please do not equate this to SIP, it can be any
signaling
   protocol and even not necessarily SDP format) achieves that.

2. Resource allocation at middle boxes
   In cases like changing transport (not necessarily access network change)
   from UDP to TCP or vice-versa, it is highly desirable to have a new SDP
O/A.
   Without such offer, it is a huge burden on middle boxes to be prepared
   for any kind of mid-session transport (UDP or TCP) changes. Middle boxes
can
   have complex logic to reserve all possible resources and keep them for
any
   future mid-session changes without new SDP O/A. Again, it's not only
inefficient
   but also makes middle boxes logic complicated. Also, as pointed by Emil
Ivov,
   ICE RFC says you MAY free remaining candidates once ICE is completed.
Even if
   an implementation wants to keep ALL the candidates even after ICE is
completed,
   it can't expect the peer to do the same, especially ice lite
implementations
   typically won't keep the remaining candidates.

BR
Raju
</Earlier-Post>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Jun 2014 06:40:45 +0000

Hi,

>>>> If not, you would still have to "renegotiate" due to the port change 
>>>> - even if the transport token doesn't change.
>>>
> So you are just quoting what the RFC says ("the SDP must be updated once the stream has a winner ICE candidate"). 

Correct. And, the reason for that is because we have made a decision to use the mechanism defined in the RFC.

> Some points:
>
> - The above does not require AT ALL that a new "SDP renegotiation" is needed. In fact, SDP O/A was previously negotiated for ICE to work.
> IMHO this is clear.
>
> - The ICE RFC states that the SDP must be updated and so on. OK. It is clear (IMHO) that the ICE spec should not mention SDP at all. And we all agree that "sending a new SDP with the updated m/c line" is just required for some QoS, 
> B2BUAs or similar systems, and we all know that this may make sense in certain signaling protocols (SIP and others), but NOT in WebRTC where there is not a defined/mandated "signaling protocol" at all (so in case the app wants to 
> indicate the server its winner ICE candidate it can do that in tons of ways).

I am not sure what you mean by "NOT in WebRTC". I can use "certain signaling protocols" with WebRTC.

> - And at the end, IMHO it is clear that browser vendors are not going to implement the "SDP update" mentioned in the ICE RFC because they find it not useful (as it clearly is).

JSEP is based on offer/answer,  and a s we have discussed before, all the browser needs to do is to inform the JS App about the update, and the JS App can then do whatever they want.

The point of my comment was that removing "UDP" from the protocol token does not automatically ensure that the m= line is always up to date, as the port may also change.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 11 Jun 2014 11:25:41 +0000

>I'm Javier Cerviño, member of the team that is implementing Licode's MCU >(http://lynckia.com). In our case we're doing some experiments exactly in the terms >you're mention in the thread. In our case we're quite interested in MCU mobility >between server to scale up and down the service. It's crucial for this purpose not to >exchange additional Offer/Answer messages and not to gather again new candidates in >the client side.
 
[Raju] We are NOT talking about new candidate gathering here. 
Please see explanation below.

>Raju, for example, in case of client or MCU mobility, we don't need to exchange media >info again, as it will be exactly the same. In our case we only want to propagate new >ICE candidates to recheck with ICE if there is a different valid pair.  But I think >the solutions commented in the thread are still compatible with your idea. As long as >the first offer/answer messages are still valid you could send them again with the >new candidates to the middle boxes if you need it.

[Raju] 
Hi Javier, Thanks for explaining your MCU use cases.
I wanted to assert again that, I am not advocating for an automatic new SDP O/A. We need to separate updating local SDP from generating new SDP offer. The former has to be done by browser and the latter is up to the application and falls into signaling (which webrtc has left to applications).
At a very high-level, this is how the flow looks like:
1. When ICE is completed, browser will update local SDP 
   c/m= lines with selected candidate for:
   a. Local IP, port
   b. Matching transport (or to indicate the transport 
      selected. TCP or UDP). 
2. Browser calls an API (TBD) like onicecandidate(NULL) 
   to indicate end of ICE.

At this point it is up to the application to use this trigger 
to send an updated offer or not. At this step, we are 
NOT talking about ICE restart or new candidate gathering etc.

BR
raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 11 Jun 2014 13:41:22 +0200

> 2. Browser calls an API (TBD) like onicecandidate(NULL)

Isn't (2) already defined in current api with 
|oniceconnectionstatechange|with state "connected" ? Maybe it would be 
interesting to also add the selected candidate in the event as I see it 
useful for applications.

As a side note, is anyone using ICE TCP at all? Given that we already 
support TURN over TCP/TLS, is it useful for anyone? As I see it it is 
only useful for servers, but locating a TURN server near it would do the 
same trick.

Best regards
Sergio

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 11 Jun 2014 12:08:18 +0000

>Isn't (2) already defined in current api with oniceconnectionstatechange with state >"connected" ? Maybe it would be interesting to also add the selected candidate in the >event as I see it useful for applications.

[Raju] (2) is done at the time of ICE gathering, which happens before initial offer is sent out. But, we need a trigger when ICE is completed, which happens after initial O/A is completed.

Trickle ICE (draft-ietf-mmusic-trickle-ice-01) is another powerful use case of leaving SDP O/A to application, but provide APIs (onicecandidate, addicecandidate) for them to achieve their needs. Trickle ICE is possible because browser gives ICE candidates to app as they are discovered. Most apps just need to know only when gathering is completed. But some delay conscious apps can make use of these candidates to perform trickle ICE. 
IMO, asking for end of ICE trigger and updating c/m= lines falls in to the same category that is already allowed by the APIs.

>As a side note, is anyone using ICE TCP at all? Given that we already support TURN >over TCP/TLS, is it useful for anyone? As I see it it is only useful for servers, but >locating a TURN server near it would do the same trick.

[Raju]
TURN involves an additional element in the network and bearer path; as a result to reduce TURN costs and bearer delay, using ICE-TCP is advised.
draft-ietf-rtcweb-transports-04 says:
   "ICE-TCP candidates [RFC6544] MUST be supported; this may allow
   applications to communicate to peers with public IP addresses across
   UDP-blocking firewalls without using a TURN server."

BR
Raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 11 Jun 2014 16:01:13 +0200

> [Raju] (2) is done at the time of ICE gathering, which happens before initial offer is sent out. But, we need a trigger when ICE is completed, which happens after initial O/A is completed.

I think that's not correct, from the editor's draft:

|oniceconnectionstatechange|of typeEventHandler, This event handler, of 
event handler event type|iceconnectionstatechange 
<http://www.w3.org/TR/webrtc/#event-iceconnectionstatechange>|,/must/be 
fired by all objects implementing the||RTCPeerConnection| 
<http://www.w3.org/TR/webrtc/#idl-def-RTCPeerConnection>|interface. It 
is called any time theiceConnectionStatechanges.

enum RTCIceConnectionState {
     "new",
     "checking",
     "connected",
     "completed",
     "failed",
     "disconnected",
     "closed"
};

That has nothing to do with

enum RTCIceGatheringState {
     "new",
     "gathering",
     "complete"
};

BTW,  as discussed on other email thread, we should add the 
onicegatheringstatechange and remove the onicecandidate(null)

>     UDP-blocking firewalls without using a TURN server."
You haven't tried to use it, right?

https://code.google.com/p/webrtc/issues/detail?id=2320

TURN is bulletproof, but ICE TCP is so seldom used that it is going to 
be very low tested/cared about on browsers implementations, I am afraid.

Best regards
Sergio

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 11 Jun 2014 14:52:19 +0000

>oniceconnectionstatechange of type EventHandler, This event handler, of event handler >event type iceconnectionstatechange, MUST be fired by all objects implementing >the RTCPeerConnection interface. It is called any time >the iceConnectionState changes.

>enum RTCIceGatheringState {

[Raju] You are right. I overlooked; iceconnectionstatechange() does indicate end of ICE. The missing part then is to update the SDP or to indicate the selected candidate. Thanks for pointing it out.

>BTW,  as discussed on other email thread, we should add the onicegatheringstatechange >and remove the onicecandidate(null)

[Raju] Yes. I agree onicegatheringstatechange() is more appropriate for end of ice candidates.

>TURN is bulletproof, but ICE TCP is so seldom used that it is going to be very low >tested/cared about on browsers implementations, I am afraid.

[Raju] I don't think it is really about if the implementation is stable or not as implementations do get stable over time. But the real question is what is webrtc implementations required to do? The spec clearly says "MUST".

BR
Raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 11 Jun 2014 18:11:47 +0200

> [Raju] I don't think it is really about if the implementation is stable or not as implementations do get stable over time. But the real question is what is webrtc implementations required to do? Th…

My point was if that "MUST" was really needed at all.

Best regards
Sergio

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 11 Jun 2014 18:57:38 +0200

The MUST was a consensus call in London. See the minutes for numbers. I was one of the ones who were surprised at the strength of the consensus.

On 11. juni 2014 18:11:47 CEST, Sergio Garcia Murillo <[email-masked]> wrote:
>>> TURN is bulletproof, but ICE TCP is so seldom used that it is going
>to be very low >tested/cared about on browsers implementations, I am
>afraid.
>> [Raju] I don't think it is really about if the implementation is
>stable or not as implementations do get stable over time. But the real
>question is what is webrtc implementations required to do? The spec
>clearly says "MUST".
>>
>>
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 11 Jun 2014 18:38:55 +0000

>The MUST was a consensus call in London. See the minutes for numbers. I was one of >the ones who were surprised at the strength of the consensus.
[Raju] I thought one of the implicit (may be explicit in draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is "implementations should work right out of the box without extra boxes (e.g. TURN) in between under UDP restrictive firewalls".
Then I see the following requirement in draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of TURN in the text.

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

BR
Raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 11 Jun 2014 21:33:23 +0200

I am late then.. :)

El 11/06/2014 18:57, Harald Alvestrand escribió:
> The MUST was a consensus call in London. See the minutes for numbers. 
> I was one of the ones who were surprised at the strength of the consensus.
>
>             TURN is bulletproof, but ICE TCP is so seldom used that it
>             is going to be very low >tested/cared about on browsers
>             implementations, I am afraid. 
>
>         [Raju] I don't think it is really about if the implementation
>         is stable or not as implementations do get stable over time.
>         But the real question is what is webrtc implementations
>         required to do? The spec clearly says "MUST".
>
>
>
>
>     ------------------------------------------------------------------------
>
>     rtcweb mailing list
>     [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 06:17:05 +0200

> [Raju] I thought one of the implicit (may be explicit in draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is "implementations should work right out of the box without extra b…
Unfortunately, nobody's found a way to make that true even for all 
common NATs/firewalls that want to permit the communication.

TURN servers are the least obnoxious way to make sure apps can work in 
the presence of symmetric NATs.
We could wish that this wasn't so, but we could also wish that NATs 
would go away and everyone would run IPv6; neither is likely to happen 
this year.

Of course, in the presence of firewalls where the admin does *not* want 
to permit the communication, we neither can nor should make 
communication work.

>             Firewalls that block UDP traffic.

Yes. Using TURN servers is the way in which it is possible to fulfil 
this requirement.

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 12 Jun 2014 11:58:15 +0200

>Yes. Using TURN servers is the way in which it is possible to fulfil this
requirement.

Further in draft-ietf-rtcweb-use-cases-and-requirements-14: 
"the straddling TURN server ... It must be
   possible to configure the browsers used in the enterprise with
   network specific STUN and TURN servers.  This should be possible to
   achieve by auto-configuration methods."
F20     The browser must support the use of STUN and TURN
           servers that are supplied by entities other than
           the web application (i.e. the network provider).

This is a TURN server with one interface on the Enterprise LAN where the
browser 
simple shall place the WebRTC media. (The other interface should be public.)

The way for the browser to autodiscover such network provided (from the
enterprise and ISP) TURN server is being worked in
draft-patil-tram-turn-serv-disc-01.txt.

This resolves any firewall restriction not allowing WebRTC media (by
paralleling the firewall with the TURN server), and also allows the
enterprise or ISP to point out a better path for the WebRTC media (instead
of through the often data crowded firewall default gateway).
(This will also be needed with IPv6.)

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Harald Alvestrand
Skickat: den 12 juni 2014 06:17
Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cerviño
Kopia: [email-masked]
Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to
UDP?

On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote:
>> The MUST was a consensus call in London. See the minutes for numbers. I
was one of >the ones who were surprised at the strength of the consensus.
> [Raju] I thought one of the implicit (may be explicit in
draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is
"implementations should work right out of the box without extra boxes (e.g.
TURN) in between under UDP restrictive firewalls".
Unfortunately, nobody's found a way to make that true even for all common
NATs/firewalls that want to permit the communication.

TURN servers are the least obnoxious way to make sure apps can work in the
presence of symmetric NATs.
We could wish that this wasn't so, but we could also wish that NATs would go
away and everyone would run IPv6; neither is likely to happen this year.

Of course, in the presence of firewalls where the admin does *not* want to
permit the communication, we neither can nor should make communication work.

> Then I see the following requirement in
draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of
TURN in the text.
>             Firewalls that block UDP traffic.

Yes. Using TURN servers is the way in which it is possible to fulfil this
requirement.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 12 Jun 2014 11:30:52 +0000

> (This will also be needed with IPv6.)

I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up the appropriate ports in the firewall towards the TURN server.  They could then allow only UDP to allow for DPI and see that it is actually RTP traffic flowing. 

Having a TURN server supporting UDP/TCP/TLS as communication between the client and TURN server would solve almost all connectivity problems. We should, as Harald also pointed out, not try to force us throughout the FW if the admin do not want the traffic to go through. 

.-.
Pål-Erik

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 12 Jun 2014 12:12:09 +0000

Since we are digressing a lot I changed the subject.

> the presence of symmetric NATs.

[Raju] Agreed. However, if there is no symmetric NAT(s) in the path webrtc can find a connection without the TURN servers. I think, that is highly preferred and thus explains the "MUST" for TCP-ICE requirement. No matter how much we trust a TURN server, it is still a *middle box* and there will be privacy concerns with it!!

> > Then I see the following requirement in draft-ietf-rtcweb-use-cases-and-
> requirements-14. It did not mention use of TURN in the text.
> >
[Raju] Yes, I think use of STUN servers only if direct connection using TCP ICE is not possible (due to symmetric NATs). Due to various issues with TURNs or middle boxes (latency, cost of service, increased loss of packets) ICE RFC recommends the following priorities for ICE candidates. I don't see webrtc has an overriding requirement for this. At the end, it's always application/user choice to use or not use TURN or other middle boxes. To facilitate this, IMHO browser requirement of MUST for TCP-ICE is justified.

http://tools.ietf.org/html/rfc5245#section-4.1.2.2
   If these concerns are important, the
   type preference for relayed candidates SHOULD be lower than host
   candidates.  The RECOMMENDED values are 126 for host candidates, 100
   for server reflexive candidates, 110 for peer reflexive candidates,
   and 0 for relayed candidates.

BR
Raju

---

From: Ca By <[email-masked]>
Date: Thu, 12 Jun 2014 05:37:39 -0700

> >> Yes. Using TURN servers is the way in which it is possible to fulfil
this
> I have problems understanding how this solves any issues. I doubt many
enterprise network managers would install a TURN server in parallel with
their FW. Would be fair easier and safer to open up the appropriate ports
in the firewall towards the TURN server.  They could then allow only UDP to
allow for DPI and see that it is actually RTP traffic flowing.

I believe they will install a TURN server in parallel to a firewall, like
many enterprises install SBCs in parallel to firewalls. Enterprise
firewalls are generally not optimized for multimedia traffic.

CB
> Having a TURN server supporting UDP/TCP/TLS as communication between the
client and TURN server would solve almost all connectivity problems. We
should, as Harald also pointed out, not try to force us throughout the FW
if the admin do not want the traffic to go through.
> >>> The MUST was a consensus call in London. See the minutes for numbers.
I
> > Unfortunately, nobody's found a way to make that true even for all
common
> > TURN servers are the least obnoxious way to make sure apps can work in
the
> > We could wish that this wasn't so, but we could also wish that NATs
would go
> > Of course, in the presence of firewalls where the admin does *not* want
to
> > Yes. Using TURN servers is the way in which it is possible to fulfil
this

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 16:57:42 +0200

> I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up t…

That is actually a very convenient way to (logically) install a TURN 
server in parallel with your firewall.
They don't have to be on the same physical segments to be in parallel.

The important thing that Cullen (I think it was Cullen) pointed out when 
we discussed this requirement is that the TURN server is designated by 
the local network administrator, not by the entity responsible for the 
Web application that uses WebRTC.

Thus, some way for the browser to find this TURN server is needed.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 12 Jun 2014 17:18:04 +0200

2014-06-12 16:57 GMT+02:00 Harald Alvestrand <[email-masked]>:
> The important thing that Cullen (I think it was Cullen) pointed out when we
> discussed this requirement is that the TURN server is designated by the
> local network administrator, not by the entity responsible for the Web
> application that uses WebRTC.
>

This topic has been discussed many times (and IMHO it deserves a
separate thread). Basically, we need per-browser TURN settings. They
may be global or per-origin (which overrides the global ones).

And then we need an API to get it:

var turnServers = navigator.getTurnServers()
// now pass turnServers to PeerConnection as usual.

but... that means that all the web applications must add the above
code into their webs. It may also be "transparent", this is, if the
PeerConnection is not provided with TURN servers it may internally
retrieve them from the browser. But probably that would fail if the
web developer set his own TURN servers and the "corporative firewall"
block them. So we probably also need a "Force TURN servers
[true/false]" within the browser TURN serttins (again global and
per-origin).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Jun 2014 13:51:04 -0400

On the related note, is there TLS-ICE? Would not it be simpler to open a
TLS connection to the server with provided fingerprint validation and use
RFC 4571 framing with plain RTP? This will also have a higher chance of
traversing firewalls then plain TCP. Even if DTLS is used over this TLS
connection, it would still make sense to use TLS instead of TCP for better
firewall traversal.

_____________
Roman Shpount

On Thu, Jun 12, 2014 at 8:12 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> [Raju] Agreed. However, if there is no symmetric NAT(s) in the path webrtc
> can find a connection without the TURN servers. I think, that is highly
> preferred and thus explains the "MUST" for TCP-ICE requirement. No matter
> how much we trust a TURN server, it is still a *middle box* and there will
> be privacy concerns with it!!
>
>
> draft-ietf-rtcweb-use-cases-and-
> [Raju] Yes, I think use of STUN servers only if direct connection using
> TCP ICE is not possible (due to symmetric NATs). Due to various issues with
> TURNs or middle boxes (latency, cost of service, increased loss of packets)
> ICE RFC recommends the following priorities for ICE candidates. I don't see
> webrtc has an overriding requirement for this. At the end, it's always
> application/user choice to use or not use TURN or other middle boxes. To
> facilitate this, IMHO browser requirement of MUST for TCP-ICE is justified.
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Jun 2014 14:04:26 -0400

> firewalls are generally not optimized for multimedia traffic.
May I remind that SBCs installed in parallel to firewalls are usually
called SIP ALGs and they are mostly broken (
https://wiki.freeswitch.org/wiki/ALG)?

I am afraid that most of the locally provided TURN servers will be terribly
mis-configured, used when they should not, and generally cause more harm
then good. For local TURN servers to work correctly you would need local
network administrators which are educated in correct WebRTC setup and who
are interested in spending time to make their setup to work correctly. In
most cases this would be highly unlikely. All an administrator would do is
turn on some setting in their firewall labeled "Enable WebRTC TURN" which
would more likely turn on something no one will understand and cause all
types of havoc. Based on our experience with SIP, expecting local network
administrators to provide any working solution for NAT traversal is
extremely optimistic.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 12 Jun 2014 20:07:36 +0000

>On the related note, is there TLS-ICE? Would not it be simpler to open a TLS connection >to the server with provided fingerprint validation and use RFC 4571 framing with plain >RTP? This will also have a higher chance of traversing firewalls then plain TCP. Even if >DTLS is used over this TLS connection, it would still make sense to use TLS instead of >TCP for better firewall traversal.

[Raju] ICE TCP RFC 6544 does cover both TLS and DTLS. Please see page 6 http://tools.ietf.org/html/rfc6544#section-3 
Yes, you can run plain RTP on top of TLS-ICE, but for webrtc use it was already decided to use DTLS-SRTP even for TCP.

BR
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 12 Jun 2014 20:17:51 +0000

>>I believe they will install a TURN server in parallel to a firewall, like many >>enterprises >>install SBCs in parallel to firewalls. Enterprise firewalls are generally >>not optimized >>for multimedia traffic.
>May I remind that SBCs installed in parallel to firewalls are usually called SIP ALGs and >they are mostly broken (https://wiki.freeswitch.org/wiki/ALG)

[Raju] What's broken is SIP ALG inside a NAT/router. For bearer functionality point of view, SBCs are standalone servers and very much analogous to TURN servers (actually more transparent than TURN servers). SBCs have added functionality of signaling anchoring so that the signaling content (e.g. SDP) can be modified as appropriately. Such SBCs are NOT broken (works with encryption) and is a critical and invaluable component for services like VoLTE.
The SBCs enterprises use fall into non-NAT/router implementations.

BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Jun 2014 17:16:08 -0400

On Thu, Jun 12, 2014 at 4:07 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> TLS connection >to the server with provided fingerprint validation and use
> RFC 4571 framing with plain >RTP? This will also have a higher chance of
> traversing firewalls then plain TCP. Even if >DTLS is used over this TLS
> connection, it would still make sense to use TLS instead of >TCP for better
> firewall traversal.
>
> [Raju] ICE TCP RFC 6544 does cover both TLS and DTLS. Please see page 6
> http://tools.ietf.org/html/rfc6544#section-3
> Yes, you can run plain RTP on top of TLS-ICE, but for webrtc use it was
> already decided to use DTLS-SRTP even for TCP.
>
>
I am not sure this is right since TLS or DTLS are supposed to run on top of
RFC 4571 on top of TCP. What I was asking about was RTP on top of RFC 4571
on top of TLS.
_____________
Roman Shpount

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 13 Jun 2014 14:54:48 +0200

Below I am agreeing with Harald that WebRTC browsers need to auto-discover
and use network provided TURN servers in favor of application provided TURN
servers (that will still remain with its hassles and limitations, for some
time of course). -->

/Karl

-----Ursprungligt meddelande-----
Från: Harald Alvestrand [mailto:[email-masked]] 
Skickat: den 12 juni 2014 16:58
Till: Pal Martinsen (palmarti); Karl Stahl
Kopia: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cerviño;
[email-masked]

On 06/12/2014 01:30 PM, Pal Martinsen (palmarti) wrote:
>> This is a TURN server with one interface on the Enterprise LAN where 
>> the browser simple shall place the WebRTC media. (The other interface 
>> should be public.)
>>
>> The way for the browser to autodiscover such network provided (from 
>> the enterprise and ISP) TURN server is being worked in 
>> enterprise or ISP to point out a better path for the WebRTC media 
>> (instead of through the often data crowded firewall default gateway).
enterprise network managers would install a TURN server in parallel with
their FW. Would be fair easier and safer to open up the appropriate ports in
the firewall towards the TURN server.  They could then allow only UDP to
allow for DPI and see that it is actually RTP traffic flowing.

That is actually a very convenient way to (logically) install a TURN server
in parallel with your firewall.
They don't have to be on the same physical segments to be in parallel.

[Karl] I fully agree with this - The WebRTC application should be off-loaded
of having to provide a TURN-server to allow usage behind (some)
NAT/firewalls (and we should not put that burden on the peer either). This
is something we do today to get something going (but still don't succeed
with the most restrictive firewalls), but hopefully don't have to do in the
future on "WebRTC-ready" accesses. Such accesses simply put ICE initiated
real-time traffic through the TURN server, while data goes as usual through
the default gateway (in a future clever firewall/NAT this can be the same
default gateway IP-address).

[Karl] Yes, let's hope for network provided turn servers, which could be
boxes in parallel with existing firewalls or built into the firewall. (A
turn server is much cleaner and better standardized to integrate, than
non-working SIP ALGs, where we instead put SBCs in parallel with firewalls
just to get SIP voice through (and with quality)). 

[Karl] Also consider all triple play (surf/telephony/IP-TV) broadband
accesses, that have a quality pipe just to cope with voice. A turn server in
such CPE will be required to place demanding WebRTC media on the pipe that
can handle WebRTCs real-time traffic. Separate pipes are also often deployed
e.g. for SIP trunking enterprise voice (PBXs and UC) paralleling the
firewall. A local turn server could similarly feed WebRTC media into such
pipes, then bypassing the ordinary firewall (that may be too restrictive to
allow real-time traffic or just is too data crowded to cope with WebRTC
media - NAT/Firewalls are typical congestion points).

Harald> Thus, some way for the browser to find this TURN server is needed.

[Karl] Auto discovered, network provided (enterprise or ISP) turn servers
are being done in draft-patil-tram-turn-serv-disc-01.txt. I favor the
anycast method suggested. Will WebRTC browsers implement all auto discovery
methods suggested there?

[Karl] Network provided turn servers available for the network users, need
no authentication - The WebRTC browser can just use them as part of the
Internet access (you get an IP address, a default gateway and a turn server
address to simply use). Those turn servers are required/can solve both
traversal and quality problems of many internet accesses.

client and TURN server would solve almost all connectivity problems. We
should, as Harald also pointed out, not try to force us throughout the FW if
the admin do not want the traffic to go through.
>> Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or 
>> not to UDP?
>>
>> draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for 
>> WebRTC is "implementations should work right out of the box without extra
boxes (e.g.
>> TURN servers are the least obnoxious way to make sure apps can work 
>> in the presence of symmetric NATs.
this year.
>>
>> Of course, in the presence of firewalls where the admin does *not* 
>> want to permit the communication, we neither can nor should make
communication work.
>> draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention 
>> use of TURN in the text.

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 13 Jun 2014 14:56:20 +0200

WebRTC media over TCP/TLS (always open port 80 or 443) must also be considered a “workaround” to get WebRTC connectivity through a few more restrictive NAT/firewalls – It will not cope with the most restrictive firewalls having HTTP(S) proxies (discussed/worked on at the pnta-list, wasn’t it).

Also, in general, it is bad to put quality demanding WebRTC media over a retransmitting TCP connection, especially through the firewall that often is a data crowded congestion point.

/Karl

Från: rtcweb [mailto:[email-masked]] För Roman Shpount
Skickat: den 12 juni 2014 23:16
Till: Makaraju, Maridi Raju (Raju)
Kopia: [email-masked]; Javier Cerviño
Ämne: Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?)

I am not sure this is right since TLS or DTLS are supposed to run on top of RFC 4571 on top of TCP. What I was asking about was RTP on top of RFC 4571 on top of TLS.

_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 13 Jun 2014 18:18:49 +0000

>WebRTC media over TCP/TLS (always open port 80 or 443) must also be considered a >“workaround” to get WebRTC connectivity through a few more restrictive NAT/firewalls – It >will not cope with the most restrictive firewalls having HTTP(S) proxies (discussed/worked >on at the pnta-list, wasn’t it).

[Raju] To get thru these very restrictive firewalls that allow HTTP only, using TCP/TLS with HTTP fallback is an option. But the restrictive firewalls may even go great lengths to limit the duration of the connection and/or size of the data (in case of TLS). 
With either HTTP fallback option or otherwise, doing TLS below RFC 4571 framing has following implications for webrtc use case; a single transport connection need to allow following 3 types of data to be multiplexed/bundled:
1. Sending STUN req before DTLS is established; unless STUN succeeds there is no point
   in setting up DTLS/TLS.
2. Sending DTLS-SRTP. This requires the RTP headers to be in clear text (i.e. not encrypted) while only the payload is encrypted.
3. Setting up SCTP on top of DTLS.

If TLS is run below RFC 4571 then (1) and (2) can't be achieved.

BR
Raju

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Jun 2014 11:24:49 -0700

ICE-TLS doesn't really make sense since you don't have a DNS name for the
remote side, just an IP, which makes certificate management very difficult.

ICE-TCP is a nice optimization for services that don't want to stand up
both a gateway and a TURN server.

On Fri, Jun 13, 2014 at 11:18 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> >WebRTC media over TCP/TLS (always open port 80 or 443) must also be
> considered a >“workaround” to get WebRTC connectivity through a few more
> restrictive NAT/firewalls – It >will not cope with the most restrictive
> firewalls having HTTP(S) proxies (discussed/worked >on at the pnta-list,
> wasn’t it).
>
> [Raju] To get thru these very restrictive firewalls that allow HTTP only,
> using TCP/TLS with HTTP fallback is an option. But the restrictive
> firewalls may even go great lengths to limit the duration of the connection
> and/or size of the data (in case of TLS).
> With either HTTP fallback option or otherwise, doing TLS below RFC 4571
> framing has following implications for webrtc use case; a single transport
> connection need to allow following 3 types of data to be
> multiplexed/bundled:
> 2. Sending DTLS-SRTP. This requires the RTP headers to be in clear text
> (i.e. not encrypted) while only the payload is encrypted.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Jun 2014 14:52:31 -0400

> remote side, just an IP, which makes certificate management very difficult.

We have a fingerprint in SDP which can be used to verify the certificates.

> both a gateway and a TURN server.

Agreed
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Jun 2014 16:34:30 -0700

> We have a fingerprint in SDP which can be used to verify the certificates.

Not without crossing layers; also, the fingerprint is in the SDP answer,
which means that ICE-TLS couldn't start until the answer is received.

Generally, I think ICE-TCP to 443 should work fine in most cases, and for
the cases where DPI prevents this, it's not clear the DPI wouldn't also
stop ICE-TLS.