Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)

From: "Elwell, John" <[email-masked]>
Date: Mon, 7 Feb 2011 16:02:29 +0100

In response to Gonzalo's request for a better understanding  of the issues that keep ICE from being widely deployed, I have submitted a new I-D on problems arising from the updated SDP offer that ICE requires under some circumstances:
https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/

Comments welcome.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 04 December 2010 20:33
> To: Flemming Andreasen
> Cc: [email-masked]; Kaynam Hedayat; 
> [email-masked]; mmusic
> Subject: [MMUSIC] Yet another alternative to ICE WAS (Re: 
> draft-ietf-mmusic-media-loopback-14 review and comments)
> 
> Hi,
> 
> >> - NAT Traversal and usage of ICE
> >>
> >> [Authors] As Hadriel mentioned, if you have ICE you don't need the
> >> loopback primer. As he also clarified, the loopback situation is
> >> different from standard calls because the mirror will never send a
> >> packet until it receives something from the source. This 
> is certainly
> >> possible for a regular call and calls may fail for that reason, but
> >> the loopback draft is dead without a solution for this problem.
> >> Remember that the primary use case for this draft is 
> service providers
> >> wanting to test to subscriber devices that are almost always behind
> >> NATs. The proposed solution meets the requirements for the dominant
> >> use case and while standard solutions are certainly usable 
> when they
> >> are available, the unfortunate reality is that most of them are not
> >> implemented. We can add clarification text that if available ICE
> >> should be used instead of the loopback primer method.
> >>
> > Thanks. The draft will also need to clearly explain how the loopback
> > primer would work, and in particular what the underlying 
> assumptions are
> > (e.g. latching) as well as when it will not work (e.g. when 
> both source
> > and mirror are behind a NAT, when you have overlapping 
> IP-addresses and
> > ports, etc). In short, the limitations of this approach 
> must be clearly
> > documented.
> > 
> > I will also check with our AD as to whether there are any additional
> > concerns with specifying such a solution when we already 
> have ICE as the
> > Standard.
> 
> as you all know, there have been a number of proposals to standardize
> simpler-than-ICE NAT traversal solutions that would only work 
> in certain
> scenarios or circumstances. There have been a lot of 
> discussions around
> them. A couple of IETFs ago there was even a bar BOF where 
> people tried
> to understand the issues that kept folks from deploying ICE in some
> scenarios. I know there have been off-list follow ups on those
> discussions but no draft have been submitted yet, AFAIK.
> 
> So, we need to frame this discussion taking into account the 
> big picture
> of NAT traversal and ICE. In this case, we need to understand 
> the issues
> that keep ICE from being widely deployed and, if needed, specify a
> general solution to address those issues. Coming up with several
> different NAT traversal mechanisms that only work in specific 
> conditions
> does not seem like the best outcome we can wish for.
> 
> I encourage people who are working on those ICE-related issues to
> participate in this discussion because this is an important area.
> 
> Thanks,
> 
> Gonzalo
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Feb 2011 14:52:49 +0100

Hi John,

Wouldn't the usage of RFC 3262 be a potential solution also for the fax case, if it would be able to send the candidate update before 200 OK?

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 7. helmikuuta 2011 17:02
> To: mmusic
> Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet 
> another alternative to ICE)
> 
> In response to Gonzalo's request for a better understanding  
> of the issues that keep ICE from being widely deployed, I 
> have submitted a new I-D on problems arising from the updated 
> SDP offer that ICE requires under some circumstances:
> > simpler-than-ICE NAT traversal solutions that would only work in 
> > certain scenarios or circumstances. There have been a lot of 
> > discussions around them. A couple of IETFs ago there was even a bar 
> > BOF where people tried to understand the issues that kept 
> folks from 
> > deploying ICE in some scenarios. I know there have been off-list 
> > follow ups on those discussions but no draft have been 
> submitted yet, 
> > AFAIK.
> > 
> > So, we need to frame this discussion taking into account the big 
> > picture of NAT traversal and ICE. In this case, we need to 
> understand 
> > the issues that keep ICE from being widely deployed and, if needed, 
> > specify a general solution to address those issues. Coming up with 
> > several different NAT traversal mechanisms that only work 
> in specific 
> > conditions does not seem like the best outcome we can wish for.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 9 Feb 2011 18:38:54 +0100

I am not sure it would work in all circumstances - the UAS might send the 200 OK before the UPDATE request reaches the UAS. It seems RFC 3262 just adds its own complications - something ICE was trying to avoid, don't forget. ICE does not mandate RFC 3262 support.

John

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 08 February 2011 13:53
> To: Elwell, John; mmusic
> Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: 
> Yet another alternative to ICE)
> 
> 
> Hi John,
> 
> Wouldn't the usage of RFC 3262 be a potential solution also 
> for the fax case, if it would be able to send the candidate 
> update before 200 OK?
> 
> Regards,
> 
> Christer
>  
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Feb 2011 07:47:32 +0100

Hi John, 

>I am not sure it would work in all circumstances - the UAS 
>might send the 200 OK before the UPDATE request reaches the 
>UAS.

Well, to avoid that you have the preconditions mechanism. Ie you don't indicate that preconditions have been met until ICE is done, which means the UAS user won't even be alarmed before ICE is done.

>It seems RFC 3262 just adds its own complications - 
>something ICE was trying to avoid, don't forget. ICE does not 
>mandate RFC 3262 support.

I know.

I was just thinking that, since you use RFC 3262 as an alternative in section 3, it would also work for section 2.

Another approach would be to, rather than getting rid of the ICE UPDATE, always require the ICE UPDATE. Then the UAS knows it will come, and can delay the fax UPDATE.

Regards,

Christer

> > Wouldn't the usage of RFC 3262 be a potential solution also for the 
> > fax case, if it would be able to send the candidate update 
> before 200 
> > OK?
> > 
> > Regards,
> > 
> > Christer
> >  
> > 
> > > In response to Gonzalo's request for a better 
> understanding of the 
> > > issues that keep ICE from being widely deployed, I have 
> submitted a 
> > > new I-D on problems arising from the updated SDP offer that ICE 
> > > requires under some circumstances:

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2011 10:16:16 +0100

> Sent: 10 February 2011 06:48
> To: Elwell, John; mmusic
> Well, to avoid that you have the preconditions mechanism. Ie 
> you don't indicate that preconditions have been met until ICE 
> is done, which means the UAS user won't even be alarmed 
> before ICE is done.
[JRE] ICE is determined to be done on the basis of what happens on the media path(s). An auto-answer device could send the 200 almost immediately.

> I was just thinking that, since you use RFC 3262 as an 
> alternative in section 3, it would also work for section 2.
> 
> Another approach would be to, rather than getting rid of the 
> ICE UPDATE, always require the ICE UPDATE. Then the UAS knows 
> it will come, and can delay the fax UPDATE.
[JRE] Can we rely on it always arriving in a timely manner, soon enough not to impact fax? What if a SIP intermediary rejects the UPDATE for some reason and it never arrives at the UAS?

However, these are useful points you make, which I will take into account if there is a need to update the document. Thanks.

John

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Feb 2011 13:39:14 +0100

Hi, 

>>>might send the 200 OK before the UPDATE request reaches the UAS.
>> 
>>Well, to avoid that you have the preconditions mechanism. 
>>Ie you don't indicate that preconditions have been met until ICE is done, which 
>>means the UAS user won't even be alarmed before ICE is done.
>[JRE] ICE is determined to be done on the basis of what 
>happens on the media path(s).

True. I guess you may not even be able to do ICE on the media path before the preconditions have met.

>An auto-answer device could send the 200 almost immediately.
> 
>> 
>>>something ICE was trying to avoid, don't forget. ICE does not mandate RFC 
>>>3262 support.
>> 
>>I know.
>> 
>>Another approach would be to, rather than getting rid of the ICE 
>>UPDATE, always require the ICE UPDATE. Then the UAS knows it will 
>>come, and can delay the fax UPDATE.
>[JRE] Can we rely on it always arriving in a timely manner, 
>soon enough not to impact fax? What if a SIP intermediary 
>rejects the UPDATE for some reason and it never arrives at the UAS?

Well, things can of course always go wrong. But, even the audio-to-fax UPDATE, when eventually sent, may get rejected or delayed in the network.

>However, these are useful points you make, which I will take into account if there is a need to update the document. Thanks.

Regarding doing ICE after 200 OK (assuming the 200 OK is sent when the call is answered - not earlier), there are some issues related to that:

1. Early media won't be possible

2. Any media plane procedure (e.g. related to media security) that is to take place before the call is established won't work

3. Since ICE, in the worse case scenario, may take a while to finish, there is a bigger risk of a bigger delay than just a little "clipping".

Regarding sending an "early" 200 OK, that of course destroys the whole forking model (which, one might say, would be a good thing since it solves a number of other issues :). In addition it would have impact on charging models etc. But, in IETF we of course don't use such ugly words as charging...

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2011 14:34:47 +0100

> Sent: 10 February 2011 12:39
> To: Elwell, John; mmusic
> Well, things can of course always go wrong. But, even the 
> audio-to-fax UPDATE, when eventually sent, may get rejected 
> or delayed in the network.
> 
> >However, these are useful points you make, which I will take 
> into account if there is a need to update the document. Thanks.
> 
> Regarding doing ICE after 200 OK (assuming the 200 OK is sent 
> when the call is answered - not earlier), there are some 
> issues related to that:
> 
> 2. Any media plane procedure (e.g. related to media security) 
> that is to take place before the call is established won't work
> 
> 3. Since ICE, in the worse case scenario, may take a while to 
> finish, there is a bigger risk of a bigger delay than just a 
> little "clipping".
> 
> 
> Regarding sending an "early" 200 OK, that of course destroys 
> the whole forking model (which, one might say, would be a 
> good thing since it solves a number of other issues :). In 
> addition it would have impact on charging models etc. But, in 
> IETF we of course don't use such ugly words as charging...
[JRE] This was not what I was suggesting. I was suggesting that ICE would complete (on the media paths) and then the user would be alerted, but in the case of auto-answer there would be an immediate 200 OK. So I am not suggesting sending 200 OK early, and I am not suggesting sending 200 OK before ICE completes. I was just pointing out that it might not be feasible for the UAC to send the UPDATE request with the updated offer and have that arrive at the UAS before the UAS sends the 200 OK to the INVITE request.

John

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Feb 2011 14:40:08 +0100

Hi, 

>>Regarding sending an "early" 200 OK, that of course 
>>destroys the whole forking model (which, one might say, would be a good thing since it 
>>solves a number of other issues :). In addition it would 
>>have impact on charging models etc. But, in IETF we of course don't use 
>>such ugly 
>>words as charging...
>[JRE] This was not what I was suggesting. I was suggesting 
>that ICE would complete (on the media paths) and then the 
>user would be alerted, but in the case of auto-answer there 
>would be an immediate 200 OK. So I am not suggesting sending 
>200 OK early, and I am not suggesting sending 200 OK before 
>ICE completes. I was just pointing out that it might not be 
>feasible for the UAC to send the UPDATE request with the 
>updated offer and have that arrive at the UAS before the UAS 
>sends the 200 OK to the INVITE request.

One could define an "ICE precondition" mechanism, where, eventhough the media plane resources are in place, the UAS user still isn't alterted until the "ICE preconditions" have been met.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Feb 2011 09:45:27 +0100

> Sent: 10 February 2011 13:40
> To: Elwell, John; mmusic
> One could define an "ICE precondition" mechanism, where, 
> eventhough the media plane resources are in place, the UAS 
> user still isn't alterted until the "ICE preconditions" have been met.
[JRE] Yes indeed, but this raises even further the barriers to adoption of ICE. It means one needs to implement 100rel and pre-conditions in order to have a viable ICE implementation that works for fax - hardly what was anticipated when ICE was written. It also increases the risk that middleboxes (e.g., SBCs) might not behave as expected. We really should be looking for simplifications, not further complexity.

John

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Feb 2011 11:12:01 +0100

Hi, 

>>One could define an "ICE precondition" mechanism, where, eventhough 
>>the media plane resources are in place, the UAS user still isn't 
>>alterted until the "ICE preconditions" have been met.
>[JRE] Yes indeed, but this raises even further the barriers 
>to adoption of ICE. It means one needs to implement 100rel 
>and pre-conditions in order to have a viable ICE 
>implementation that works for fax - 

I agree. But, there is a reason why those mechanisms were defined: to solve a specific problem :)

>hardly what was anticipated when ICE was written.

Well, SIP itself, and SDP offer/answer, were originally supposed to be very easy and simple things :)

>It also increases the risk that middleboxes (e.g., SBCs) might not behave as expected. 
>We really should be looking for simplifications, not further complexity.

I agree. But, again, the reason the mentioned extensions were defined was because there was no existing mechanism available.

Regards,

Christer