Subject: RE: [MMUSIC] ICE Issue: mid-session connectivity checks

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Oct 2004 21:04:12 -0400

I vote for 1.

Note that 1 could be dealt with at the application layer. So while it does
indeed
mean that the session would be re-established, it doen't NECESSARILY mean
that 
the use would hang-up the call. You could in theory re-establish it without
hanging-up.

So instead of saying "Recovery would require re-establishing the call" I'd
say
"Recovery would require re-establishing the session".

In fact, couldn't we just do a new Offer/Answer?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, October 20, 2004 05:46
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE Issue: mid-session connectivity checks
> 
> 
> Folks,
> 
> One of the big changes in the -02 ICE spec was the addition of 
> mid-session connectivity checks. These checks served several purposes:
> 
> 1. detection of a network failure that causes an interface to become 
> unreachable
> 
> 2. in the case of a failure of a nat in the middle of the network, if 
> the nat recovers, or a backup takes its place, a new binding will get 
> assigned, and it can be discovered
> 
> 
> The particular motivating use case for 2 is an enterprise that is 
> multihomed. It has a NAT on each of its two interfaces to its 
> providers. 
> The enterprise uses the address prefix provided from provider A, and 
> advertises reachability to this prefix into provider B. A 
> client within 
> the enterprise makes a call. The NAT and/or connection to provider A 
> fails. Routing now causes outbound UDP packets to go over the 
> interface 
> to provider B. So, outbound UDP packets from the client now 
> go through 
> this other NAT. It assigns a new binding. With mid-session 
> checks, the 
> new binding can be learned by the peer, and communications 
> established 
> using it.
> 
> Now, the trick is that, if we are interested in VoIP as a driving use 
> case for this, the amount of time to discover this has to be 
> relatively 
> short. If it takes 30 seconds, the users in the call would 
> have already 
> hung up. That requires the connectivity checks to be sent at a rapid 
> clip. Furthermore, in the case of such a failure, signaling 
> would fail 
> too in all likelihood (depending where the servers are), which would 
> require some SIP operations.
> 
> So, the issue is, is it worth it? I have gotten a few 
> complaints about 
> the complexity introduced by the mid-session checks. Thus, we 
> have three 
> choices as I see it:
> 
> 1. remove the checks completely
> 
> ICE runs only on setup, to do an initial check. RTCP would, 
> for example, 
> allow you to detect some of these failure situations 
> mid-call. Recovery 
> would require re-establishing the call.
> 
> 2. keep the checks
> 
> THe draft stays as is
> 
> 3. Allow for the usage of the checks to be negotiated
> 
> In case a client doesn't want to implement support for the 
> mid-session 
> checks, we make them optional and allow it to be signaled.
> 
> 
> I'd prefer NOT to do 3, in the interest of avoiding protocol options. 
> The argument in favor of 1 is primarily one of 
> simplification, and that 
> you will have to make these connectivity checks really fast 
> in order to 
> be responsive enough to really recover from a failure, which 
> could be a 
> problem.
> 
> As I constantly hear these days that "ICE is too complicated", in the 
> interests of simplification, I'd be game to remove the 
> feature. It could 
> be added back in as an extension later if needed.
> 
> Comments?
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                        FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Aron Rosenberg <[email-masked]>
Date: Wed, 20 Oct 2004 22:52:28 -0700

Jonathan,

    I agree with you that we should remove the mid-call checks. In 
addition to points that you raised, they also make running ICE with non 
RTP media protocols much cleaner.

Aron Rosenberg
Founder and CTO
SightSpeed Inc.

>In case a client doesn't want to implement support for the mid-session 
>The argument in favor of 1 is primarily one of simplification, and that 
>you will have to make these connectivity checks really fast in order to 
>be responsive enough to really recover from a failure, which could be a 
>problem.
>
>interests of simplification, I'd be game to remove the feature. It could