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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 02 Jun 2014 19:13:43 +0200

I believe this has been discussed before, but I can't find the 
discussion...... so I'm re-raising it.
(it may have happened here, or on MMUSIC, but I can't find it in either 
place).

I believe this WG has consensus that ICE is used, that ICE-TCP 
candidates are permitted (indeed, required to be supported), and that 
TURN over TCP is permitted; in the latter two cases, RFC 4571 framing is 
used, but SRTP is used, not TLS.

Given the nature of ICE, flows may shift back and forth between TCP 
candidates and UDP candidates over the lifetime of the flow, without any 
new SDP negotiation being invoked.

A bug has been raised about what protocol field to be used in the SDP 
for these flows.

RFC 5764 says:

8.  Session Description for RTP/SAVP over DTLS

    This specification defines new tokens to describe the protocol used
    in SDP media descriptions ("m=" lines and their associated
    parameters).  The new values defined for the proto field are:

    o  When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
       DTLS with the Datagram Congestion Control Protocol (DCCP), then
       the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
       respectively.

    o  When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
       UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
       respectively.

    The "fmt" parameter SHALL be as defined for RTP/SAVP.

    See [RFC5763] for how to use offer/answer with DTLS-SRTP.

    This document does not specify how to protect RTP data transported
    over TCP.  Potential approaches include carrying the RTP over TLS
    over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that
    in this document over TCP, either via TLS or DTLS, with DTLS being
    used for consistency between reliable and unreliable transports. In
    the latter case, it would be necessary to profile DTLS so that
    fragmentation and retransmissions no longer occurred.  In either
    case, a new document would be required.

The current implementations both send "RTP/SAVPF" in this field. But 
this usage is not specified by RFC 5764.

Using the specified token, UDP/TLS/RTP/SAVPF, speaks a partial untruth, 
in that sometimes, UDP is not used. But it is a token people have seen 
before.

What says the wisdom of the group? What shall we put in the spec?

Harald

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Jun 2014 11:53:57 -0700

On 2 June 2014 10:13, Harald Alvestrand <[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.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 2 Jun 2014 21:51:08 +0200

2014-06-02 19:13 GMT+02:00 Harald Alvestrand <[email-masked]>:
> Using the specified token, UDP/TLS/RTP/SAVPF, speaks a partial untruth, in
> that sometimes, UDP is not used. But it is a token people have seen before.
>

I don't think SDP is ready or enough powerful to allow this case in
which different transports can be used. The "UDP/TLS/RTP/SAVPF" token
is just that: a token. And there is no reason at all to mandate that
the m= line defines the transport to use given that, at least in
WebRTC, the transport is determined by the ICE candidates. The
"transport" in the m= line is as useless as the "port" field in the m=
line when ICE is mandated.

RFC 5764 "DTLS Extension to Establish Keys for SRTP" clearly states
that "there is no chance" to allow two different transports for the
same media:

-----------------------------
8.  Session Description for RTP/SAVP over DTLS

   o  When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
      UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
      respectively.
------------------------------

So basically SDP is not valid for WebRTC, but since it has been forced
to be valid we need a workaround to hide this fact. I would propose
that the m= line "transport" for WebRTC MUST always be the token
"UDP/TLS/RTP/SAVPF" regardless the nature of transports in the ICE
candidates (so basically it becomes a useless but mandatory field in
the SDP, as many others already). Said that I would also be happy if
the chosen token is "CHICKEN".

Regards.

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jun 2014 23:04:20 -0700

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]>
wrote:

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 03 Jun 2014 10:32:43 +0200

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

El 03/06/2014 8:04, Justin Uberti escribió:
> 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:
>     [email-masked] <mailto:[email-masked]>

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 3 Jun 2014 11:08:07 +0200

On Tue, 03 Jun 2014 10:32:43 +0200
Sergio Garcia Murillo <[email-masked]> wrote:

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

> > 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 current implementations both send "RTP/SAVPF" in this
> >     > field.
> >     But this
> >     contradictory to an existing RFC.  That happens all the time.
> > At least this time it can be explicit.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jun 2014 09:16:06 +0000

Hi Harald,

>Given the nature of ICE, flows may shift back and forth between TCP candidates and UDP candidates over the lifetime of the flow, without any new SDP negotiation being invoked.

Is that really true?

1) When the selected candidates have been chosen, and updated offer is sent where the c/m- lines represent the selected candidates

2) Media is sent only using the selected candidates

3) Keep-alives etc are sent only using the selected candidates (which means that switching to other candidates "on the fly" may not even work)

4) If you want to change the selected candidates, you need to do an ICE restart, new candidate nominations, and new selected (which means a new offer).

Or, did I misunderstand what you said? :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 11:35:03 +0200

> 4) If you want to change the selected candidates, you need to do an ICE restart, new candidate nominations, and new selected (which means a new offer).

Please, may we forget this constrain/requirement in RFC 5245 that is
100% useless?

By following ICE procedures both peers agree on which candidate-pair
to use, and there is no need at all to force a "new SDP offer"
indicating the selected pair since both peers already know that.

And to prove it, let's take a look to WebRTC browsers as none of them
"generates a new SDP offer if the winning ICE candidate-pair does not
match the candidate in the m= line".

Best regards.

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 03 Jun 2014 12:51:07 +0300

> match the candidate in the m= line".

I believe Christer was talking about the need to send a new offer when 
you do an ICE restart. I don't think was about the part in RFC5245 that 
tells you to send a new offer once ICE is ready and that is only 
necessary for the benefit of signalling intermediaries.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 12:14:19 +0200

2014-06-03 11:51 GMT+02:00 Emil Ivov <[email-masked]>:
> I believe Christer was talking about the need to send a new offer when you
> do an ICE restart.

Once a candidate-pair is selected and used to transmit media, a device
may check (after some time) the same candidate-pairs. And if it finds
a better pair it may select it. There may be no need for a new SDP O/A
in this case.
Of course, in the case of mobility, interface changes, etc, signaling
the ICE candidates from scratch is needed.

> I don't think was about the part in RFC5245 that tells
> you to send a new offer once ICE is ready and that is only necessary for the
> benefit of signalling intermediaries.

That is 100% focused on SIP.

Regards.

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 3 Jun 2014 14:34:48 +0300

> > I believe Christer was talking about the need to send a new offer when
you
> a better pair it may select it. There may be no need for a new SDP O/A

That wouldn't work with current  RFC5245 implementations (and I believe
would cause problems) but if you want to make a proposal, mmusic would be
the right place.

> That is 100% focused on SIP.

Yes, correct

Emil

--sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jun 2014 11:56:59 +0000

Hi,

>>> a better pair it may select it. 

Nobody can of course prevent implementations from checking whether previously nominated (but not selected) candidates still work. However, I am not sure whether entities e.g. must respond to connectivity checks from such entities.

>>> There may be no need for a new SDP O/A
>>> in this case.
>>>
>>> That wouldn't work with current  RFC5245 implementations (and I believe would cause problems) but if you want to make a proposal, mmusic would be the right place.

It is focused on environments where intermediaries make media decisions based on the signaling. SIP is of course an obvious example.

But, never the less, as far as I know we have adopted RFC5245 - not a profile of RFC5245 - which means:

1) ICE restart in case you want to change the selected candidate pair; and

2) sending a new offer if a new candidate pair is chosen as the selected

*IF* we decide to change it, then it should be properly documented.

Regards,

Christer

---

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

Hi,

> I believe Christer was talking about the need to send a new offer when you do an ICE restart. I don't think was about the part in RFC5245 that tells you to send a 
> new offer once ICE is ready and that is only necessary for the benefit of signalling intermediaries.

I guess I was talking about both :)

(Of course, if the current c/m- line data match the selected candidate data, there is no need to send an offer)

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Jun 2014 14:16:51 +0200

> 2) sending a new offer if a new candidate pair is chosen as the selected

Does it?

11.1.3.  Procedures for All Implementations

    ICE has interactions with jitter buffer adaptation mechanisms. An
    RTP stream can begin using one candidate, and switch to another one,
    though this happens rarely with ICE.  The newer candidate may result
    in RTP packets taking a different path through the network -- one
    with different delay characteristics.  As discussed below, agents are
    encouraged to re-adjust jitter buffers when there are changes in
    source or destination address of media packets.  Furthermore, many
    audio codecs use the marker bit to signal the beginning of a
    talkspurt, for the purposes of jitter buffer adaptation.  For such
    codecs, it is RECOMMENDED that the sender set the marker bit
    [RFC3550] when an agent switches transmission of media from one
    candidate pair to another.

11.2.  Receiving Media

    ICE implementations MUST be prepared to receive media on each
    component on any candidates provided for that component in the most
    recent offer/answer exchange (in the case of RTP, this would include
    both RTP and RTCP if candidates were provided for both).

    It is RECOMMENDED that, when an agent receives an RTP packet with a
    new source or destination IP address for a particular media stream,
    that the agent re-adjust its jitter buffers.

I would never want to call RFC 5245 a model of clarity, but it seems to 
me that this language was written in the expectation that a sender might 
choose to switch to a different pair at any time.

I can't find the corresponding paragraph that says when the sender might 
do so, though.

---

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

2014-06-03 14:16 GMT+02:00 Harald Alvestrand <[email-masked]>:
> I would never want to call RFC 5245 a model of clarity, but it seems to me
> that this language was written in the expectation that a sender might choose
> to switch to a different pair at any time.

+1

> I can't find the corresponding paragraph that says when the sender might do
> so, though.

IMHO if it's not defined when it can do that then it MUST be able to
do that at any time.

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

---

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

Hi,

>>>>> Once a candidate-pair is selected and used to transmit media, a 
>>>>> device may check (after some time) the same candidate-pairs. And if 
>>>>> it finds a better pair it may select it.
>>>>> There may be no need for a new SDP O/A in this case.
>>>>>

I guess this could happen during session establishment if you use aggressive nomination, where you may indicate a candidate pair as selected, but then switch to another. But, the RFC still says that you send a new offer when such switch occur.

> I would never want to call RFC 5245 a model of clarity, but it seems to me that this language was written in the expectation that a sender might choose to switch to a different pair at any time.
>
> I can't find the corresponding paragraph that says when the sender might do so, though.

Perhaps what you are talking about is related to the MICE work?

It's a while since I read the MICE draft, so I don't remember the details. There, I think you can use multiple candidate pairs alive, but I don't remember whether you can switch without sending a new offer.

In any case, if there is something unclear about ICE, I guess we should bring it to MMUSIC :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 14:31:28 +0200

2014-06-03 14:26 GMT+02:00 Christer Holmberg <[email-masked]>:
> But, the RFC still says that you send a new offer when such switch occur.

Yes, for making SIP B2BUAs happy ;)

May we just ignore that? :)

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

---

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

Hi,

>> I would never want to call RFC 5245 a model of clarity, but it seems 
>> to me that this language was written in the expectation that a sender 
>> might choose to switch to a different pair at any time.
>
> +1

We can ask MMUSIC about that.

> IMHO if it's not defined when it can do that then it MUST be able to do that at any time.

It still says that you must send an offer, so that the c/m- lines match the candidates.

And, in general, I think we should be really careful about making implicit assumptions. If something is unclear, bring it to MMUSIC :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Tue, 03 Jun 2014 15:35:53 +0300

> choose to switch to a different pair at any time.

I agree with Christer that the intention here was likely to make that 
possible while ICE processing is still ongoing.

Note how section 8.3.1 says:

    Once ICE processing
    has reached the Completed state for all peers for media streams using
    those candidates, the agent SHOULD wait an additional three seconds,
    and then it MAY cease responding to checks or generating triggered
    checks on that candidate.  It MAY free the candidate at that time.
    Freeing of server reflexive candidates is never explicit; it happens
    by lack of a keepalive.  The three-second delay handles cases when
    aggressive nomination is used, and the selected pairs can quickly
    change after ICE has completed.

8.3.2. Lite Implementation Procedures

    A lite implementation MAY free candidates not selected by ICE as soon
    as ICE processing has reached the Completed state for all peers for
    all media streams using those candidates.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 03 Jun 2014 15:35:57 +0300

> May we just ignore that? :)

B2BUAs may have very valid reasons for requiring this. Typically, some 
would add relay candidates as a fall back and they need to know when and 
where to release them.

Emil

-- 
https://jitsi.org

---

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

Hi,

> May we just ignore that? :)

If we reference a specification, we shall not ignore the procedures. That will only cause interop problems etc in future.

Again, if we want to change something, let's discuss it, and based on the outcome properly document whatever changes are needed.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 14:43:37 +0200

> We can ask MMUSIC about that.

I strongly don't agree that any pure network-based feature requires
MMUSIC (SDP) to accept it.

Now: imagine a WebRTC device (a mobile) running a audio/video session.
The user walks, looses WiFi and connects to 3G. The WebRTC application
is probably notified about "network changed" and could restart ICE
without the need of signaling a new SDP offer (it may signal it if it
wants). Why do we need to mandate the new SDP O/A?

ICE protocol should have been defined as a separate pure network
protocol (a pure STUN usage) without involving SIP and SDP at all. And
SIP should have its own MMUSIC RFC "ICE usage for SIP and SDP". And we
wouldn't be here debating about the need of sending a fake SDP offer
just because ICE does it work in background.

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

---

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

Hi,

>>>> to me that this language was written in the expectation that a 
>>>> sender might choose to switch to a different pair at any time.
>>>
>>> +1
>>
> I strongly don't agree that any pure network-based feature requires MMUSIC (SDP) to accept it.
>
> The user walks, looses WiFi and connects to 3G. The WebRTC application is probably notified about "network changed" and could 
> restart ICE without the need of signaling a new SDP offer (it may signal it if it wants).

Isn't that what the MICE draft is about?

> Why do we need to mandate the new SDP O/A?

Because the RFC says so :)

Seriously, people base implementations, tests etc on the specifications. So, if we think something in a specification is not needed, we should try to change it.

>ICE protocol should have been defined as a separate pure network protocol (a pure STUN usage) without involving SIP and SDP at all. 

Well, that's what people tried to do in the beginning, and what I believe people now try to do in 5245bis.

>And SIP should have its own MMUSIC RFC "ICE usage for SIP and SDP". And we wouldn't be here debating about the need of sending a fake SDP offer just because ICE does it work in background.

If your browser does not use SIP/SDP on the wire, you don't have to send the offer. You do whatever your wire protocol specifies.

Regards,

Christer

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 3 Jun 2014 13:08:13 +0000

> wants). Why do we need to mandate the new SDP O/A?
If there are NATs and FWs involved and you change your IP address there is a good chance you need connectivity checks from both sides to get through all the NATs. To do that you need to send your candidates to the remote side so he can start doing the ICE magic.

There is the MICE draft discussing how that can be done. Trickle ICE also have the potential to better handle those mobility scenarios. But this needs more work to iron out all the corner cases.

> just because ICE does it work in background.
That is work in progress within the MMUSIC.

.-.
Pål-Erik

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 14:16:27 +0000

Strong "+1" for Christer's comments on taking it to MMUSIC.
Please see my comments inserted below.

> > wants). Why do we need to mandate the new SDP O/A?

[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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 16:38:24 +0200

2014-06-03 16:16 GMT+02:00 Makaraju, Maridi Raju (Raju)
<[email-masked]>:

>    network may provide better QoS via PCRF/PGW dedicated bearers.

If you are talking about "middle boxes" then you mean a fixed and
specific *signaling* protocol, right? even more, you probably mean
SIP.
Given the fact that WebRTC is supposed to be "signaling protocol"
agnostic I don't buy your rationale.

>    if the selected candidate is not the one listed in c/m= lines.

I'm glad that that does not occur now, and no one WebRTC browser cares
about that.

>    protocol and even not necessarily SDP format) achieves that.

If so it can be signaled *anyhow* (up to the specific application /
vendor), but we are discussing here about the requirement of signaling
a new SDP (as the RFC mandates).

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jun 2014 15:10:06 +0000

Hi,

>If so it can be signaled *anyhow* (up to the specific application / vendor), but we are discussing >here about the requirement of signaling a new SDP (as the RFC mandates).

Whatever is signalled on the wire is outside the scope of our work. It's a JavaScript implementation issue.

What IS within our scope is what the WebRTC browser is allowed to do internally (e.g. switch from one candidate pair to another "on the fly"), and how it informs the JS App about such switch (in order for the JS App to e.g. generate and send a new offer reflecting the switch).

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 15:14:29 +0000

> specific *signaling* protocol, right? even more, you probably mean

[Raju] No, I didn't mean SIP. Mention of "middle boxes" do not translate to SIP!
One can send your SDP in a totally different format in a totally 
different signaling protocol (XMPP or XYZ). A simple case for a middle box
could be a conf bridge.

> agnostic I don't buy your rationale.

[Raju] Yes, WebRTC is signaling protocol agnostic. I do realize there is some confusion about mixing signaling protocol O/A with new SDP offer at WebRTC client.
That's not what we are talking about here. I am talking about a need for WebRTC to "trigger" a new O/A under certain conditions (e.g. c/m= lines do not match with selected candidate) so that it allows underlying network to reconfigure itself for the new flow. PeerConnection (PC) API should allow such triggers to be delivered to the application. Then, it's up to the application (and the service provider) to handle it appropriately to either initiate a new SDP O/A with its favorite signaling protocol or simply discard it.

> I'm glad that that does not occur now, and no one WebRTC browser cares

[Raju] A SDP O/A for simple changes like default candidate changed is not needed for all applications. But in some cases (e.g. PCRF dedicated bearers or using RSVP) having a new SDP O/A allows providing better QoS. If a service/app provider wants to go that extra mile then WebRTC should probably allow it.

> a new SDP (as the RFC mandates).

[Raju] Yes, it is up to the specific application/vendor. But, to achieve this underlying PC/JSEP API should provide mechanisms to:
1. Inform application when default candidate changes/selected. So, that application
   can do whatever it wants to do with that info.
2. Make sure c/m= lines are formatting is consistent with the default/selected
   candidate. That means using of RTP/AVPF independent of actual transport is 
   not correct.
Existing PC callback oniceconnectionstatechange() may be used to solve both of these.
However, createOffer() called after this callback should have the updated c/m=
lines per the selected candidate(s). Not sure if browsers do either or both of these today?! Without clear requirements browsers may not implement this trigger. I think, this is what we need from the PC API and browsers so that some applications can take advantage of this for better QoS or other reasons.

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 17:19:47 +0200

2014-06-03 17:14 GMT+02:00 Makaraju, Maridi Raju (Raju)
<[email-masked]>:

> Yes, it is up to the specific application/vendor. But, to achieve this underlying PC/JSEP API should provide mechanisms to:

>    can do whatever it wants to do with that info.

OK

>    candidate. That means using of RTP/AVPF independent of actual transport is

OK

> lines per the selected candidate(s). Not sure if browsers do either or both of these today?! Without clear requirements browsers may not implement this trigger. I think, this is what we need from t…

My main concern is about whether a ICE endpoint should allow
"on-the-fly" candidate-pair changes when such a new SDP O/A does not
take place. That is what worries me, and the RFC is not clear about
that.

Regards.

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

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 16:25:33 +0000

> > lines per the selected candidate(s). Not sure if browsers do either or
> both of these today?! Without clear requirements browsers may not implement
> this trigger. I think, this is what we need from the PC API and browsers so
> that some applications can take advantage of this for better QoS or other
> reasons.
> 
[Raju] Let's define "on-the-fly" as changing candidate pair after ICE is "completed", i.e. a final candidate has been selected and nominated (via STUN USE-CANDIDATE-ATTRIBUTE). In such a case ICE RFC 5245 "9.1.2.2. Existing Media Streams with ICE Completed" says:

<RFC 5245 excerpt>
   9.1.2.2.  Existing Media Streams with ICE Completed
   ...
   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the default
   destination for media to equal the destination ICE has selected for
   media.
   The agent MUST include candidate attributes for candidates matching
   the default destination for each component of the media stream, and
   MUST NOT include any other candidates.
</RFC 5245 excerpt>

So, no new candidates can be added when in "completed" state (without ICE restart).

If ICE is in running state, then new candidates can be added. But for such
new offers RFC says c/m= line must match with default candidate/destination.

<RFC 5245 excerpt>
   9.1.2.1.  Existing Media Streams with ICE Running
   ...
   The component ID MUST remain the same.  The agent
   MAY include additional candidates it did not offer previously, but
   which it has gathered since the last offer/answer exchange, including
   peer reflexive candidates.
   The agent MAY change the default destination for media.  As with
   initial offers, there MUST be a set of candidate attributes in the
   offer matching this default destination.

</RFC 5245 excerpt>

To add a new ICE candidate in ICE completed state ICE Restarts must be done. ICE restart preserves existing media and tries to find best new candidate pair.

<RFC 5245 excerpt>
   9.1.1.1.  ICE Restarts

   An agent MAY restart ICE processing for an existing media stream.  An
   ICE restart, as the name implies, will cause all previous states of
   ICE processing to be flushed and checks to start anew.  The only
   difference between an ICE restart and a brand new media session is
   that, during the restart, media can continue to be sent to the
   previously validated pair.
   An agent MUST restart ICE for a media stream if:

   o  The offer is being generated for the purposes of changing the
      target of the media stream.  In other words, if an agent wants to
      generate an updated offer that, had ICE not been in use, would
      result in a new value for the destination of a media component

</RFC 5245 excerpt>

So, if a user moves to a new access network (e.g. LTE to WiFi) then assuming ICE is already completed, ICE must be restarted, thus a new SDP O/A must be done. This is also obvious from that fact that new local candidates for the access network must be conveyed to the peer so that ICE connectivity checks start and succeed.

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Jun 2014 18:37:43 +0200

2014-06-03 18:25 GMT+02:00 Makaraju, Maridi Raju (Raju)
<[email-masked]>:
> So, if a user moves to a new access network (e.g. LTE to WiFi) then assuming ICE is already completed, ICE must be restarted, thus a new SDP O/A must be done.

All the above can be summarized as: "RFC 5245 mandates a new SDP O/A
if the selected candidate-pair does not match the address in the c/m
lines".
Well, I already know that, it is written in the RFC. The point is that
the above is useless and a requirement that should not be added by a
network protocol that defines a STUN usage.

> This is also obvious from that fact that new local candidates for the access network must be conveyed to the peer so that ICE connectivity checks start and succeed.

Not so obvious. If the mobile is talking to a peer which has public IP
(and peer is a full or lite ICE implementation) then a new SDP O/A is
useless. At the end, and regardless what the initial SDP Offer said,
the peer will discover the new reflexive candidates from the mobile
"on-the-fly" (as the ICE protocol states).

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

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 3 Jun 2014 17:15:47 +0000

> network protocol that defines a STUN usage.

[Raju] Correct. I think we are on the same page. As we discussed earlier, what applies to WebRTC is for the browser to update the SDP and notify the application of these events. Then it is up to the application to handle them anyway it wants. 

> > This is also obvious from that fact that new local candidates for the
> access network must be conveyed to the peer so that ICE connectivity checks
> start and succeed.
> 

[Raju] Implementation MUST not assume peer having a public IP.

> "on-the-fly" (as the ICE protocol states).

[Raju] I don't think peer discovering new reflexive candidates can happen after ICE is completed. First, without ICE restart the mobile which detected a new local candidate (WiFi) can't send ICE connectivity checks on it if the ICE state is completed (this is written in the same RFC). So, even if there is a NAT in between and peer may treat this new candidate as peer reflexive candidate, local side can't send STUN. Also, implementations should not assume NAT being present locally.

BR
Raju