Subject: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

From: <[email-masked]>
Date: Mon, 3 Oct 2011 11:58:28 +0000

Hi all,

There is one important requirement, which may not be critical today, but will most likely be in the future.

We can assume RTC-Web to be supported in devices like tablets, pads or smartphones, that people carry around. We can also assume that when such devices are carried around, their point of attachement to the Internet will change, even so that the type of access network will change, typically between something like HSPA/LTE and Wi-Fi. Today this will always mean a change of IP address as well. In the future we may have technologies such as (Proxy)Mobile IP in use that will provide IP address preservation, but we can't really count on that.

How does this relate to RTC-Web? Interface switching usually happens at the discretion of the OS or some kind of connection manager. The browser or the web application environment has no control over it. At best it, or the JS application running within, can get some kind of signal of such event happening. For TCP-based client-server things (HTTP, Websocket) it is possible to react to this by re-establishing the lost TCP connections and state on top of them. This is indeed what many (native) apps are able to do today. There can be some smarter ways in the pipeline as well, such as multipath TCP, which would make the process of "transitioning" a TCP connection from one interface/IP to another potentially transparent to the application. But with peer-to-peer and interactive real-time, things get more complicated. It may of course be that the switching happens due to a sudden loss of coverage and is so slow, that voice or video calls are broken anyway. However, in many cases the old interface can be up while the new one is being established, and in principle the total loss of connectivity can be avoided. In such scenarios it would be realistically possible to update the ongoing real-time sessions to a new IP address and port, if there were some kind of end-to-end or server-assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad as a total loss of the session.

What does this mean in terms of requirements?
- The first-order requirement is that the browser and/or the JS app, whoever needs to act, has to be able to get events of interface switching in the same way as native apps can. If it were only the browser who was required to get them, we could set standards aside, and declare that the browser does this as any other app. But if it is the JS app that needs to do something, then we may need something new as a JS API. I have no clue at the moment if the JS apps can learn about this kind of events. And this is clearly not a RTC-Web specific requirement, but a generic one. I do know that browsers or HTTP libraries can re-send requests etc. based on IP address change, but I don't know what a JS Websocket client can do, if anything.
- The second requirement is that the media related APIs and transport protocols (RTP) have to be flexible enough, that they can at least be extended to work so that they do not assume that the session is forever bound to a certain IP address/port in either end. How this affects the system depends on what is actually standardized, for instance if the SDP offer/answer model is included or not. But on the generic level it could be something like this:
	- If the browser/JS app receives signaling/offer from its peer that peer's RTP/UDP IP address/port has changed, it has to be able to set these through the media API and re-run STUN checks or whatever is required at that point. This has to be work so that the media session can be otherwise continued, after the process is completed.
	- If the browser/JS app receives an event that its own IP address/port has changed (or is about to change), it has to be able to re-initialize the RTP/UDP accordingly, re-establish its "signaling connection and state" with its webserver, notify the peer about the change, and re-run STUN checks etc. as needed.

This sounds quite complicated so it may be that we don't want to add this as a Day 1 requirement for RTC-Web. But I believe we should try to design the APIs and protocols in such a way that this kind of thing can be added later on. There could be other ways too, like MPRTP (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look at. 

I suppose the less we standardize about the signaling and offer/answer, the easier it might be to support these kinds of things as add-on. But whatever we standardize, please keep the interface and IP address change in mind. The outcome could be that we declare that transport (MPTCP, MPRTP) has to deal with it, but eventually I think this will have to work one way or the other.

Regards,
	Markus

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 3 Oct 2011 14:05:17 +0200

3 okt 2011 kl. 13:58 skrev <[email-masked]>:

> How does this relate to RTC-Web? Interface switching usually happens at the discretion of the OS or some kind of connection manager. The browser or the web application environment has no control over it. At best it, or the JS application running within, can get some kind of signal of such event happening. For TCP-based client-server things (HTTP, Websocket) it is possible to react to this by re-establishing the lost TCP connections and state on top of them. This is indeed what many (native) apps are able to do today. There can be some smarter ways in the pipeline as well, such as multipath TCP, which would make the process of "transitioning" a TCP connection from one interface/IP to another potentially transparent to the application. But with peer-to-peer and interactive real-time, things get more complicated. It may of course be that the switching happens due to a sudden loss of coverage and is so slow, that voice or video calls are broken anyway. However, in many cases the 
> old interface can be up while the new one is being established, and in principle the total loss of connectivity can be avoided. In such scenarios it would be realistically possible to update the ongoing real-time sessions to a new IP address and port, if there were some kind of end-to-end or server-assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad as a total loss of the session.
> 
That is indeed an important observation.

THe SIP outbound extension has handling of IP address change during a registration/connection. But that doesn't imply IP address change during a call. Software like Asterisk has added protection on the RTP ports so after initial packets (handling symmetric RTP) Asterisk will not accept packets from an unknown IP. I would assume that if we had ICE support, ICE could re-initialize the session and the server could open new connections.

Thanks for this feedback.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Oct 2011 14:24:50 +0200

> - The first-order requirement is that the browser and/or the JS app, whoever needs to act, has to be able to get events of interface switching in the same way as native apps can. If it were only th…

In WebSocket a disconnect() event will be called by JS API if the
connection is terminated (this can occur when the server explicity
terminates the connection or when the WebSocket client tries to send a
message over the WebSocket connection and gets an error because the
connection "does not work anymore"). For the last case, a pinging
mechanism from the client is a good choice.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Oct 2011 14:29:24 +0200

2011/10/3 Olle E. Johansson <[email-masked]>:
> THe SIP outbound extension has handling of IP address change during a registration/connection. But that doesn't imply IP address change during a call.

When a SIP client implementing the outbound extension (RFC 5626)
detects that the TCP (or TLS or WebSocket) connection is
terminated/down, it should re-register and should send a re-INVITE for
established dialogs telling the peer about its new location and SDP
address. In fact, the using RFC 5626 the client does not need to know
its exact local IP:port, as the edge proxy would route back incoming
in-dialog request using the new client connection.

> Software like Asterisk has added protection on the RTP ports so after initial packets (handling symmetric RTP) Asterisk will not accept packets from an unknown IP.

It should allow a change in the source IP:port of the RTP packets in
case a re-INVITE has been sent by the peer.

> I would assume that if we had ICE support, ICE could re-initialize the session and the server could open new connections.

I expect this to be the same: the client would send a re-INVITE after
detecting local address change and Asterisk should accept it and
update the session information.

Regards.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 3 Oct 2011 14:33:22 +0200

> in-dialog request using the new client connection.
Over UDP the client recognizes a new binding using STUN and determines that the connection has failed
and re-initializes.

> case a re-INVITE has been sent by the peer.
Always. Of course. But previously we always accepted it...
> update the session information.
Right.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Oct 2011 14:35:44 +0200

> Over UDP the client recognizes a new binding using STUN and determines that the connection has failed

Right, but being in RtcWeb, I expect that the signaling will always be
carried within a reliable transport (WebSocket or HTTP).

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

---

From: Stefan Håkansson <[email-masked]>
Date: Mon, 3 Oct 2011 14:40:50 +0200

Markus,

in terms of use case and reqs, do you see anything missing if you look 
at 
<http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/>, 
section 4.2.3?

In terms of technology I thought ICE would be able to handle this.

Stefan

On 10/03/2011 01:58 PM, [email-masked] wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 03 Oct 2011 09:29:38 -0400

> We can assume RTC-Web to be supported in devices like tablets, pads or smartphones, that people carry around. We can also assume that when such devices are carried around, their point of attachemen…

If memory serves (and I haven't checked) interface switching is within 
scope from what was discussed at prior IETF meetings, though I don't 
know if it's in any of the current use cases (I think not).  We have not 
discussed any of the specifics of it, however, and should do so, as well 
as decide if it's in-scope for "1.0".  There's certainly a case for it, 
even without mobile devices (switching Wi-Fi hotspots with a laptop, or 
DHCP-caused IP changes).

> 	- If the browser/JS app receives signaling/offer from its peer that peer's RTP/UDP IP address/port has changed, it has to be able to set these through the media API and re-run STUN checks or whate…

Effectively, in SIP/SDP terms, it needs to do a re-INVITE with a new c= 
address (and new port).  The added complication is that the signalling 
channel will be affected as well, so the application needs to 
re-establish the signalling channel *then* re-establish the 
peerconnection and "re-INVITE" to re-establish the media streams.

Note that any "custom" signalling someone designs will need to include 
this ability!   (Something they may not realize and may not handle 
properly...)  But that's a different thread/argument.  ;-)

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Oct 2011 16:03:05 +0200

The media channels in Google's ICE-based offerings (Google Talk Video, 
Google Voice and Hangouts) all are able to survive an interface change 
by utilizing the alternate candidate mechanisms in ICE.

Try this experiment:
- Make sure your laptop has a working wireless connection
- Connect your laptop to wired Ethernet
- Set up a Google Talk Video call with someone
- Yank out the Ethernet cord

If all goes well, you should see exactly how much of a break this causes 
to the call in practice.
(If the call disconnects, please file a bug - I'm sure there are cases 
we don't handle well.)

The control channel needs to be reconnected too, of course, but we're 
not so much in a hurry over that one.

                    Harald

---

From: <[email-masked]>
Date: Mon, 3 Oct 2011 14:40:48 +0000

Hi Harald,

Well, things may already be better than what I expected :)

>The control channel needs to be reconnected too, of course, but we're not so
>much in a hurry over that one.

So you're not signaling anything at the point of the switch, but you have set two alternatives beforehand? In the mobile use case, the available interfaces come and go, so we can't offer all alternate candidates upfront. However, if we can keep the "old" interface up for a while after the "new" one appears, we can add the new candidate at that point. This would be the so called make-before-break switch. The worst case is that we loose the old interface at the same time as new one comes available, so the new alternative can only be sent over the new interface AFTER the signaling has been reconnected. This would be break-before-make. If the underlying OS can handle multi-homing, we should in most cases only need the make-before-break type of switching. However, as we know, a device can run out of Wi-Fi coverate quite abruptly and it is not always clear that the cellular connectivity is fully up at that point.

I don't know all nuances of ICE by heart, but is it so that the alternate candidates can be added in an offer at any point? In that case we should be able to cover most cases quite well.

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Harald Alvestrand
>Sent: 03 October, 2011 17:03
>To: [email-masked]
>Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through
>interface switching
>
>Google Voice and Hangouts) all are able to survive an interface change by
>utilizing the alternate candidate mechanisms in ICE.
>
>Try this experiment:
>If all goes well, you should see exactly how much of a break this causes to the
>call in practice.
>(If the call disconnects, please file a bug - I'm sure there are cases we don't
>handle well.)
>
>The control channel needs to be reconnected too, of course, but we're not so
>much in a hurry over that one.
>
>                    Harald
>
>
>> We can assume RTC-Web to be supported in devices like tablets, pads or
>smartphones, that people carry around. We can also assume that when such
>devices are carried around, their point of attachement to the Internet will
>change, even so that the type of access network will change, typically
>between something like HSPA/LTE and Wi-Fi. Today this will always mean a
>change of IP address as well. In the future we may have technologies such as
>(Proxy)Mobile IP in use that will provide IP address preservation, but we can't
>really count on that.
>>
>> How does this relate to RTC-Web? Interface switching usually happens
>> at the discretion of the OS or some kind of connection manager. The
>> browser or the web application environment has no control over it. At
>> best it, or the JS application running within, can get some kind of
>> signal of such event happening. For TCP-based client-server things
>> (HTTP, Websocket) it is possible to react to this by re-establishing
>> the lost TCP connections and state on top of them. This is indeed what
>> many (native) apps are able to do today. There can be some smarter
>> ways in the pipeline as well, such as multipath TCP, which would make
>> the process of "transitioning" a TCP connection from one interface/IP
>> to another potentially transparent to the application. But with
>> peer-to-peer and interactive real-time, things get more complicated.
>> It may of course be that the switching happens due to a sudden loss of
>> coverage and is so slow, that voice or video calls are broken anyway.
>> However, in many cases th
> e
>>   old interface can be up while the new one is being established, and in
>principle the total loss of connectivity can be avoided. In such scenarios it
>would be realistically possible to update the ongoing real-time sessions to a
>new IP address and port, if there were some kind of end-to-end or server-
>assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad as a
>total loss of the session.
>>
>> - The first-order requirement is that the browser and/or the JS app,
>whoever needs to act, has to be able to get events of interface switching in
>the same way as native apps can. If it were only the browser who was
>required to get them, we could set standards aside, and declare that the
>browser does this as any other app. But if it is the JS app that needs to do
>something, then we may need something new as a JS API. I have no clue at
>the moment if the JS apps can learn about this kind of events. And this is
>clearly not a RTC-Web specific requirement, but a generic one. I do know that
>browsers or HTTP libraries can re-send requests etc. based on IP address
>change, but I don't know what a JS Websocket client can do, if anything.
>> - The second requirement is that the media related APIs and transport
>protocols (RTP) have to be flexible enough, that they can at least be extended
>to work so that they do not assume that the session is forever bound to a
>certain IP address/port in either end. How this affects the system depends on
>what is actually standardized, for instance if the SDP offer/answer model is
>included or not. But on the generic level it could be something like this:
>> 	- If the browser/JS app receives signaling/offer from its peer that
>peer's RTP/UDP IP address/port has changed, it has to be able to set these
>through the media API and re-run STUN checks or whatever is required at that
>point. This has to be work so that the media session can be otherwise
>continued, after the process is completed.
>> 	- If the browser/JS app receives an event that its own IP address/port
>has changed (or is about to change), it has to be able to re-initialize the
>RTP/UDP accordingly, re-establish its "signaling connection and state" with its
>webserver, notify the peer about the change, and re-run STUN checks etc. as
>needed.
>>
>> This sounds quite complicated so it may be that we don't want to add this as
>a Day 1 requirement for RTC-Web. But I believe we should try to design the
>APIs and protocols in such a way that this kind of thing can be added later on.
>There could be other ways too, like MPRTP
>(http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look
>at.
>>
>> I suppose the less we standardize about the signaling and offer/answer, the
>easier it might be to support these kinds of things as add-on. But whatever we
>standardize, please keep the interface and IP address change in mind. The
>outcome could be that we declare that transport (MPTCP, MPRTP) has to deal
>with it, but eventually I think this will have to work one way or the other.
>>
>> Regards,
>> 	Markus

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Oct 2011 16:51:29 +0200

On 10/03/2011 04:40 PM, [email-masked] wrote:
> So you're not signaling anything at the point of the switch, but you have set two alternatives beforehand? In the mobile use case, the available interfaces come and go, so we can't offer all alternate candidates upfront. However, if we can keep the "old" interface up for a while after the "new" one appears, we can add the new candidate at that point.
Section 9 of RFC 5245 is the procedure for adding more candidates during 
the call.
It supports make-before-break:

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.

>   This would be the so called make-before-break switch. The worst case is that we loose the old interface at the same time as new one comes available, so the new alternative can only be sent over the new interface AFTER the signaling has been reconnected. This would be break-before-make. If the underlying OS can handle multi-homing, we should in most cases only need the make-before-break type of switching. However, as we know, a device can run out of Wi-Fi coverate quite abruptly and it is not always clear that the cellular connectivity is fully up at that point.
>

---

From: <[email-masked]>
Date: Tue, 4 Oct 2011 09:53:55 +0000

Hi, 

Iñaki Baz Castillo wrote:
>
>In WebSocket a disconnect() event will be called by JS API if the connection is
>terminated (this can occur when the server explicity terminates the
>connection or when the WebSocket client tries to send a message over the
>WebSocket connection and gets an error because the connection "does not
>work anymore"). For the last case, a pinging mechanism from the client is a
>good choice.
>

Is it possible for the browser to call disconnect() also for more explicit reasons, such that it has itself learned that the current interface/socket has become disconnected? This way the JS application would get the signal immediately rather than having to wait for the next ping. In that case this should be OK. The disconnect() function should then have the code for re-creating the websocket connection, this time over the new (default) interface, and recreating the necessary state on top of it in the application level. This would create a few seconds of disconnect between the client and the server, which might be OK for most apps. Perfect handling of this case, i.e. being able to open the new connection before the old one is lost, would probably require changes in the Websocket API. Or, use of MPTCP.

Markus

---

From: <[email-masked]>
Date: Tue, 4 Oct 2011 10:10:59 +0000

Hi Harald,

I have a few additional questions to make sure this can work.

>Section 9 of RFC 5245 is the procedure for adding more candidates during the
>call.

This seems to be the right mechanism. But this has to be triggered at any time when a new interface becomes available. For instance, when the device enters Wi-Fi coverage and is able to connect to the Wi-Fi network. The browser itself can clearly learn about this through some OS/platform specific APIs. So, if it is the browser who is responsible for sending the new offer, it can do it. If it is the JS application, it would need some event that it knows it should do so. 

Is it then so that the STUN connectivity checks are run for the new candidates as soon as they are added? And if we want to be able to use the new candidates immediately after the old IP/interface has become disconnected, both ends will have to keep the NAT/FW state alive for these candidates as long as they are in the latest offer?

Finally, how does the other peer (who's own connectivity has not changed) know when to start using a new candidate pair? Is it after it starts receiving packets from the other end over that candiate pair? Or is it based on some ICMP error? 

Since media is potentially end-to-end even between service providers, we will have to be careful that things work between two pairs. Including pairs that are e.g. SBC's implementing ICE.

Markus

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Oct 2011 14:09:22 +0200

Hi,
(as individual)

I would like to comment on two things around this with ICE restarts and
what I believe Google Voice Talk does and its relation to the ICE spec.

First of all I understand this being based on that the candidates are
kept alive after the initial nomination so they are always ready. This
is clearly allowed, but will definitely fail if the other part doesn't
keep its ICE candidates alive, and do note that these might include TURN
relay candidates also. Thus this practice is not without some resource
consumption, even if it is only a STUN request every 15 seconds.

Secondly, I understand that the alternative candidates are used without
signaling to the other peer that the ICE connectivity checks and later
nomination happens. This will not work for candidate pairs where the
peer not having interface change happen to it is behind a middlebox with
a address dependent filtering rule, i.e. practically all, unless the
candidate pair hasn't be initially verified to work and kept alive
without nomination due to lower priority for the whole call. Otherwise,
this only works when both sides tries to use their candidates due to ICE
restart signaling message or that the other peer also suspects path
breakage and initiates an ICE restart implicitly based on lack of
feedback and media traffic from peer.

When it comes to handling interface changes in general. I do believe
that we will need to support a signaled ICE restart. If not, the webapp
can anyway emulate this at a higher resource consumption and likely
longer media disruption by opening new peer connections.

Cheers

Magnus

On 2011-10-03 16:51, Harald Alvestrand wrote:
>>> The control channel needs to be reconnected too, of course, but
>>> we're not so much in a hurry over that one.
>> So you're not signaling anything at the point of the switch, but
>> you have set two alternatives beforehand? In the mobile use case,
>> the available interfaces come and go, so we can't offer all
>> alternate candidates upfront. However, if we can keep the "old"
>> interface up for a while after the "new" one appears, we can add
>> the new candidate at that point.
> Section 9 of RFC 5245 is the procedure for adding more candidates
> during the call. It supports make-before-break:
> 
> 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 
>> This would be the so called make-before-break switch. The worst
>> case is that we loose the old interface at the same time as new one
>> comes available, so the new alternative can only be sent over the
>> new interface AFTER the signaling has been reconnected. This would
>> be break-before-make. If the underlying OS can handle multi-homing,
>> we should in most cases only need the make-before-break type of
>> switching. However, as we know, a device can run out of Wi-Fi
>> coverate quite abruptly and it is not always clear that the
>> cellular connectivity is fully up at that point.
>> 
>> I don't know all nuances of ICE by heart, but is it so that the
>> alternate candidates can be added in an offer at any point? In that
>> case we should be able to cover most cases quite well.
>> 
>> Markus
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of ext Harald
>>> Alvestrand Sent: 03 October, 2011 17:03 To: [email-masked] 
>>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work
>>> through interface switching
>>> 
>>> The media channels in Google's ICE-based offerings (Google Talk
>>> Video, Google Voice and Hangouts) all are able to survive an
>>> interface change by utilizing the alternate candidate mechanisms
>>> in ICE.
>>> 
>>> Try this experiment: - Make sure your laptop has a working
>>> wireless connection - Connect your laptop to wired Ethernet - Set
>>> up a Google Talk Video call with someone - Yank out the Ethernet
>>> cord
>>> 
>>> If all goes well, you should see exactly how much of a break this
>>> causes to the call in practice. (If the call disconnects, please
>>> file a bug - I'm sure there are cases we don't handle well.)
>>> 
>>> The control channel needs to be reconnected too, of course, but
>>> we're not so much in a hurry over that one.

-- 

Magnus Westerlund

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

---

From: <[email-masked]>
Date: Thu, 6 Oct 2011 13:04:23 +0000

Hi Stefan,

Stefan Håkansson wrote:
>
>in terms of use case and reqs, do you see anything missing if you look at

I agree ICE has the mechanisms to handle it to some extent, as new candidates can be added on-the-fly, e.g. when a device gets a new IP address via a newly connected interface. I guess the minimum requirement is that the entity generationg the ICE signaling messages needs to be able to learn about the existence of the new candidates immediately, so it can generate the new ICE "offer". I'm not sure where this is supposed to happen, but if it is the JS app that sends the "offers", there is a requirement that there needs to be an event in the API indicating that the set of local candidates has changed.

Markus

---

From: <[email-masked]>
Date: Thu, 6 Oct 2011 13:20:01 +0000

Hi Magnus,

Magnus Westerlund wrote:
>
>Hi,
>(as individual)
>
>I would like to comment on two things around this with ICE restarts and what I
>believe Google Voice Talk does and its relation to the ICE spec.
>
>First of all I understand this being based on that the candidates are kept alive
>after the initial nomination so they are always ready. This is clearly allowed,
>but will definitely fail if the other part doesn't keep its ICE candidates alive,
>and do note that these might include TURN relay candidates also. Thus this
>practice is not without some resource consumption, even if it is only a STUN
>request every 15 seconds.
>

I agree that keeping candidates alive for an interface that is otherwise on stand-by is costly. For instance, if the media flows over Wi-Fi, but the device would like to keep the cellular interface candidates alive in case the user steps out of Wi-Fi coverage, it will be about double the radio power consumption. But there are some situations where doing this smartly might make sense. 

>nomination happens. This will not work for candidate pairs where the peer
>not having interface change happen to it is behind a middlebox with a address
>dependent filtering rule, i.e. practically all, unless the candidate pair hasn't be
>initially verified to work and kept alive without nomination due to lower
>priority for the whole call. 

Right. 

>Otherwise, this only works when both sides tries to
>use their candidates due to ICE restart signaling message or that the other
>peer also suspects path breakage and initiates an ICE restart implicitly based
>on lack of feedback and media traffic from peer.
>
>When it comes to handling interface changes in general. I do believe that we
>will need to support a signaled ICE restart. If not, the webapp can anyway
>emulate this at a higher resource consumption and likely longer media
>disruption by opening new peer connections.
>

Agree. It seems there is some flexibility how to do this, as long as the JS app just gets an event about the connectivity changes. So this seems to be the minimum thing needed.

Markus

>>> So you're not signaling anything at the point of the switch, but you
>>> have set two alternatives beforehand? In the mobile use case, the
>>> available interfaces come and go, so we can't offer all alternate
>>> candidates upfront. However, if we can keep the "old"
>>> interface up for a while after the "new" one appears, we can add the
>>> new candidate at that point.
>> An ICE restart, as the name implies, will cause all previous states of
>>> This would be the so called make-before-break switch. The worst case
>>> is that we loose the old interface at the same time as new one comes
>>> available, so the new alternative can only be sent over the new
>>> interface AFTER the signaling has been reconnected. This would be
>>> break-before-make. If the underlying OS can handle multi-homing, we
>>> should in most cases only need the make-before-break type of
>>> coverate quite abruptly and it is not always clear that the cellular
>>> connectivity is fully up at that point.
>>>
>>>> [mailto:[email-masked]] On Behalf Of ext Harald Alvestrand
>>>> Sent: 03 October, 2011 17:03 To: [email-masked]
>>>> interface change by utilizing the alternate candidate mechanisms in
>>>> ICE.
>>>>
>>>> Try this experiment: - Make sure your laptop has a working wireless
>>>> connection - Connect your laptop to wired Ethernet - Set up a Google
>>>> Talk Video call with someone - Yank out the Ethernet cord
>>>>

---

From: Stefan Håkansson <[email-masked]>
Date: Thu, 6 Oct 2011 15:48:21 +0200

On 10/06/2011 03:04 PM, [email-masked] wrote:
>> <http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-
>> requirements/>, section 4.2.3?
>>
> I agree ICE has the mechanisms to handle it to some extent, as new
> candidates can be added on-the-fly, e.g. when a device gets a new IP
> address via a newly connected interface. I guess the minimum
> requirement is that the entity generationg the ICE signaling messages
> needs to be able to learn about the existence of the new candidates
> immediately, so it can generate the new ICE "offer". I'm not sure
> where this is supposed to happen, but if it is the JS app that sends
> the "offers", there is a requirement that there needs to be an event
> in the API indicating that the set of local candidates has changed.

I agree. For the time being, the requirement is on a higher level - and 
quite badly phrased (I'm to blame):
"It MUST be possible to move from one network interface to another one"
I think it can be better put, and later when the model is decided it can 
be broken down (e.g to an event in the API).

Stefan

>>> There is one important requirement, which may not be critical
>>> today, but will
>> most likely be in the future.
>>>
>> smartphones, that people carry around. We can also assume that when
>> such devices are carried around, their point of attachement to the
>> Internet will change, even so that the type of access network will
>> change, typically between something like HSPA/LTE and Wi-Fi. Today
>> this will always mean a change of IP address as well. In the future
>> we may have technologies such as (Proxy)Mobile IP in use that will
>> provide IP address preservation, but we can't really count on
>> that.
>>>
>>> How does this relate to RTC-Web? Interface switching usually
>>> happens at the discretion of the OS or some kind of connection
>>> manager. The browser or the web application environment has no
>>> control over it. At best it, or the JS application running
>>> within, can get some kind of signal of such event happening. For
>>> TCP-based client-server things (HTTP, Websocket) it is possible
>>> to react to this by re-establishing the lost TCP connections and
>>> state on top of them. This is indeed what many (native) apps are
>>> able to do today. There can be some smarter ways in the pipeline
>>> as well, such as multipath TCP, which would make the process of
>>> "transitioning" a TCP connection from one interface/IP to another
>>> potentially transparent to the application. But with peer-to-peer
>>> and interactive real-time, things get more complicated. It may of
>>> course be that the switching happens due to a sudden loss of
>>> coverage and is so slow, that voice or video calls are broken
>>> anyway. However, in many cases th
>> e
>> principle the total loss of connectivity can be avoided. In such
>> scenarios it would be realistically possible to update the ongoing
>> real-time sessions to a new IP address and port, if there were some
>> kind of end-to-end or server- assisted mechanism for it. Even a cut
>> of 1-2 seconds would not be as bad as a total loss of the session.
>>>
>>> What does this mean in terms of requirements? - The first-order
>>> requirement is that the browser and/or the JS app,
>> whoever needs to act, has to be able to get events of interface
>> switching in the same way as native apps can. If it were only the
>> browser who was required to get them, we could set standards aside,
>> and declare that the browser does this as any other app. But if it
>> is the JS app that needs to do something, then we may need
>> something new as a JS API. I have no clue at the moment if the JS
>> apps can learn about this kind of events. And this is clearly not a
>> RTC-Web specific requirement, but a generic one. I do know that
>> browsers or HTTP libraries can re-send requests etc. based on IP
>> address change, but I don't know what a JS Websocket client can do,
>> if anything.
>> protocols (RTP) have to be flexible enough, that they can at least
>> be extended to work so that they do not assume that the session is
>> forever bound to a certain IP address/port in either end. How this
>> affects the system depends on what is actually standardized, for
>> instance if the SDP offer/answer model is included or not. But on
>> the generic level it could be something like this:
>> peer's RTP/UDP IP address/port has changed, it has to be able to
>> set these through the media API and re-run STUN checks or whatever
>> is required at that point. This has to be work so that the media
>> session can be otherwise continued, after the process is
>> completed.
>> has changed (or is about to change), it has to be able to
>> re-initialize the RTP/UDP accordingly, re-establish its "signaling
>> connection and state" with its webserver, notify the peer about the
>> change, and re-run STUN checks etc. as needed.
>>>
>> a Day 1 requirement for RTC-Web. But I believe we should try to
>> design the APIs and protocols in such a way that this kind of thing
>> can be added later on. There could be other ways too, like MPRTP
>> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we
>> could look at.
>>>
>> easier it might be to support these kinds of things as add-on. But
>> whatever we standardize, please keep the interface and IP address
>> change in mind. The outcome could be that we declare that transport
>> (MPTCP, MPRTP) has to deal with it, but eventually I think this
>> will have to work one way or the other.
>>>
>>> Regards, Markus _______________________________________________
>>> rtcweb mailing list [email-masked]
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 7 Oct 2011 12:46:17 +0200

> I agree. For the time being, the requirement is on a higher 
> level - and quite badly phrased (I'm to blame):
> I think it can be better put, and later when the model is 
> decided it can be broken down (e.g to an event in the API).
> When people end up phrasing something as "It MUST be possible... " what they normally mean is:

"The mechanism MUST support ..."

Rather than

"Implementations MUST support ..."

Or, else some form of use requirement.

But choose which you want.

Regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Håkansson
> Sent: 06 October 2011 14:48
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must 
> work through interface switching
> 
> I agree. For the time being, the requirement is on a higher 
> level - and quite badly phrased (I'm to blame):
> I think it can be better put, and later when the model is 
> decided it can be broken down (e.g to an event in the API).
> 
> Stefan
> 
> >
> > Markus
> >
> >
> >>> There is one important requirement, which may not be 
> critical today, 
> >>> but will
> >>> We can assume RTC-Web to be supported in devices like 
> tablets, pads 
> >>> or
> >> provide IP address preservation, but we can't really count on that.
> >>>
> >>> browser or the web application environment has no control 
> over it. 
> >>> At best it, or the JS application running within, can get 
> some kind 
> >>> of signal of such event happening. For TCP-based client-server 
> >>> things (HTTP, Websocket) it is possible to react to this by 
> >>> re-establishing the lost TCP connections and state on top 
> of them. 
> >>> This is indeed what many (native) apps are able to do 
> today. There 
> >>> can be some smarter ways in the pipeline as well, such as 
> multipath 
> >>> TCP, which would make the process of "transitioning" a TCP 
> >>> connection from one interface/IP to another potentially 
> transparent 
> >>> to the application. But with peer-to-peer and interactive 
> real-time, 
> >>> things get more complicated. It may of course be that the 
> switching 
> >>> happens due to a sudden loss of coverage and is so slow, 
> that voice 
> >>> or video calls are broken anyway. However, in many cases th
> >> e
> >>> old interface can be up while the new one is being 
> established, and 
> >>> in
> >> and declare that the browser does this as any other app. 
> But if it is 
> >> the JS app that needs to do something, then we may need 
> something new 
> >> as a JS API. I have no clue at the moment if the JS apps can learn 
> >> about this kind of events. And this is clearly not a 
> RTC-Web specific 
> >> requirement, but a generic one. I do know that browsers or HTTP 
> >> libraries can re-send requests etc. based on IP address 
> change, but I 
> >> don't know what a JS Websocket client can do, if anything.
> >> protocols (RTP) have to be flexible enough, that they can 
> at least be 
> >> extended to work so that they do not assume that the session is 
> >> instance if the SDP offer/answer model is included or not. 
> But on the 
> >> generic level it could be something like this:
> >> peer's RTP/UDP IP address/port has changed, it has to be 
> able to set 
> >> these through the media API and re-run STUN checks or whatever is 
> >> required at that point. This has to be work so that the 
> media session 
> >> can be otherwise continued, after the process is completed.
> >>> This sounds quite complicated so it may be that we don't 
> want to add 
> >>> this as
> >> (MPTCP, MPRTP) has to deal with it, but eventually I think 
> this will 
> >> have to work one way or the other.
> >>>
> >> _______________________________________________ rtcweb 
> mailing list 
> >> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>