Subject: [Sipping] Update to ICE

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2003 14:57:48 -0400

Folks,

You may have noticed that I submitted an update to the ICE spec:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-01.txt
http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-01.html
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt

A bunch of things changed in this revision:

1. Based on comments during the SF IETF, I worked on backwards 
compatibility. ICE is now backwards compatible with non-ICE clients. 
No Require or Proxy-Require is needed. No additional round trips of 
signaling are consumed. To do that, I am no longer using the ALT 
semantic for the SDP grouping framework. Instead, each media stream 
has one m line. There are any number of a=alt attributes within that 
stream, which provide alternate points of contact. So, if an ICE 
client calls a non-ICE client, they end up communicating using the 
address that the caller placed in the m and c lines. The spec now 
recommends that this be the address that is most likely to work, 
usually a TURN allocated address.

2. Construcing an answer is a lot simpler. It used to be that, because
the number of m-lines in an offer and answer had to be the same,
creating the answer was hard. You had to split it up over multiple 
cycles. Yuck. Now, the answer just contains as many
"alt" attributes as is necessary. This avoids additional ICE cycles
which used to be required.

3. an optimization has been added to avoid additional ice cycles. If a
peer learns about new transport addresses, it only initiates a new 
offer if that address is higher priority than any other one that the 
peer has already connected to.

4. During the San Fran IETF, I proposed to deprecate the existing 
nat-scenarios document in favor of one which showed a single solution 
- ICE - in all configurations. The response was that I would need to 
show what that would look like before a decision could be made. Well, 
the -01 draft contains almost 50 pages of detailed call flows for each 
scenario. Residential, enterprise, and centrex configurations are 
shown. The flows in all cases are all the same basic ICE flows over 
and over, but with differing results based on the conditions. The good 
news is, as expected, ICE works well in each of those configurations 
and does the optimal thing in each, using the same single client 
algorithm described in the spec.

5. Removed the suggested q-values for the various addresses. Now, only 
the basic ordering is suggested. This is in line with the ordinal 
nature of q-values.

6. In a few places, a UA needs to know when its peer "connects" to a 
particular transport address. In -00, it was suggested that this is 
known when media arrives on that transport address. However, that 
doesnt work. A UA can't tell, when receiving media, whether it was 
sent TO the TURN derived or STUN derived address. As a result, this 
determination is now made based on the receipt of peer-to-peer STUN 
requests. The username and password within the STUN request can be 
used to disambiguate the transport address to which it was sent.

7. Partial alignment with a new revision of TURN. That new revision 
(which I'll comment on in a separate note), introduces a 
MORE-AVAILABLE feature, the aim of which is to allow a TURN server to 
allocate multiple bindings on a single request. The ICE draft assumes 
this works differently than the TURN spec does.

There are a few open issues:

1. How exactly does a UA determine the "address that is most likely to 
work?" when populating the m and c lines in an offer? I found that, in 
the enterprise case, when the TURN server lives within the enterprise, 
there was no one single address. The enterprise case actually has two 
TURN addresses that get used. One is the private address, reachable 
from within the enterprise, and the other is the public address, 
reachable from outside. The right "default" depends on who you are 
calling. Of course, if the peer supports ICE, there is no need to 
choose a default, and the one which works best is discovered.

2. I suspect some enterprises may forbid outbound UDP traffic that 
doesnt come from some server in the DMZ. If that is the case, ICE will 
actually work well when you have a call between an enterprise with 
this restriction, and some other user without it (such as a 
residential user). You'll end up getting media sent in/out of the 
enterprise through its TURN server. But, in the case of an enterprise 
to enterprise call, both sides will block outbound UDP from end 
devices to each other's TURN servers, and so nothing works. What is 
the easiest way to fix this? I have some ideas on adding a feature to 
TURN to support this, similar to the way, in MSRP, you can use an 
outbound proxy to send messages.

The other main issue is that status of this work. Is there interest in 
making this a working item of sipping? There was support for that at 
the last IETF (the minutes showed a hum of favor of adopting), but I 
think it was lukewarm. I am hoping that this rev addresses some of the 
concerns from last round. If there is support, I would propose that:

1. The behavioral parts of ice become a sipping BCP item,
2. The precondition stuff get pursued as a separate sip item,
3. The examples become an informational document, replacing 
draft-ietf-sipping-nat-scenarios,
4. the SDP extensions get worked in mmusic

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP