SIP in higher education

[Garret Yoshimi <>]

Hi folks,

Notes from our VoIP SIG conference call on May 10, 2007 with Jonathan 
Rosenberg, Cisco Systems, discussing ICE.  Note, several of the attendee 
names were missing since I was slow to click the start button.  For 
those that are interested, I believe the slides from the presentation 
are still posted at Jonathan's site.

Please look for announcements regarding future calls.

Best regards.
garret

- - - - -  VoIP SIG Conference Call - May 10, 2007

*Attendees*

Dennis Baron, MIT
Chris Casswell, MCNC
Candace Holman, Independent
Jerry Keith, UC Riverside
Anne Knoll, Polycom Canada
Eric McCrosky, UC Riverside
Leo O'Shea, Boston College
Jonathan Rosenberg, Cisco Systems
Christian Schlatter, UNC
Alex Shaw, NOAA
Jonathan Tyman, Internet 2
Mike Van Norman, UCLA
Doug Walston, Cisco Systems
Garret Yoshimi, University of Hawaii


*Discussion*

Today's call features Jonathon Rosenberg of Cisco Systems discussing the 
interactive connectivity establishment protocol, which was developed to 
deal with issues involving SIP and NAT traversal. The specifications for 
ICE are currently being finalized by the IETF.

Slides from today's presentation are available here: 
http://www.jdrosen.net/papers/ice-basic-tutorial.pdf

Jonathon begins by providing an overview of NAT, or network address 
translation. In general  NAT is a router which maps internal private IP 
addresses to an external public one by modifying the addresses and ports 
of all packets as they pass through the router. NAT is widely used by 
consumer broadband routers as well as enterprise grade firewalls as it 
allows administrators to avoid renumbering and, most importantly, to 
allow multiple clients to share one IP address.

In terms of SIP and VoIP traffic, NAT has several disadvantages. Clients 
send SIP INVITE messages using local IP and port numbers, which are seen 
by others as private and media is not sent. There are three parts to the 
problem, one of which is solved by ICE. The other two are not discussed 
in this presentation.

The IETF solution to sending media through NAT is called ICE. ICE makes 
use of other protocols and technologies, such as STUN and TURN. It is a 
peer-to-peer protocol, which works by having both endpoints work 
together to mutually traverse the network. It does require STUN and TURN 
servers to function, but allows media to be transmitted in a variety of 
NAT situations while helping to eliminate problems such as one-way 
media. ICE also can prevent phones from ringing if media support does 
not exist.

The protocol functions by dynamically discovering the shortest route 
between endpoints. It also provides security benefits, such as 
eliminating DOS attacks in SIP. ICE works with any NAT or firewall, and 
the endpoints don't have to know any details about the NAT nor how many 
there are. It uses external relays only in the worst cases, such as when 
both endpoints are behind symmetric NAT.

When an ICE enabled client makes a call, it begins by gathering IPs and 
port numbers where it might be reached, which are referred to as 
candidates. Host candidates exist natively on the device, server 
reflexive candidates are located on the public side of the NAT, and 
relayed candidates reside on servers, similar to VPNs. The client builds 
a list of candidates, any of which might work for media based on the 
network topology. The client assigns a priority to each candidate, with 
the host candidate getting the highest priority. In some cases this 
might work, such as when the calling client and the receiving client are 
behind the same NAT. The second priority is usually the server reflexive 
candidate, with the relay candidate ordered last due to higher amounts 
of latency and other drawbacks.

Dennis asks if STUN servers are required to perform relay functions. 
Jonathan says that this is not required by the spec, which discusses 
providing this but discourages it. In some cases relays are required, 
and generally this function is not done by public servers as there is a 
high overhead associated with it. Dennis also asks about authentication 
and authorization with STUN, which Jonathan says is possible.

After the client gathers a list of candidates, it sends an INVITE. The 
session description protocol says what  type of call this will be, and 
contains ICE related fields for ports and IP addresses which are in the 
body of the SIP message and therefore ignored by proxies. The called 
party receives the INVITE and generates its own list of candidates. Both 
sides now have a list of candidates, which are paired and redundant ones 
are eliminated. These are then sorted into priority order and tested by 
sending packets. These are sent every 20 to 30ms, with the highest 
priority candidates first. STUN is used because it is possible to 
discover new candidates while checking for connectivity. After each side 
runs the checks and receives responses, a pair of candidates is agreed 
upon. The call is finalized before the called client rings the phone, to 
minimize any delay apparent to the user.

Jonathan is asked why the first pair of candidates isn't used 
automatically. He states that packet loss can cause higher priority 
candidate checks to take longer to complete, and ICE wants to give these 
a chance. ICE can also do round-trip time estimates, and works with 
multi-homed agents to decide on IPV4 or IPV6. It can also choose optimum 
routes for notebooks with both wired and wireless connections.

After the candidates have been selected, ICE needs to deal with the fact 
that the addresses chosen don't match was sent in the SDP information, 
which might confuse any systems along the way. The ICE client solves 
this by sending another INVITE with SDP information that matches the IP 
and port that were chosen.

Dennis asks about actual implementations of ICE. Jonathan says that 
eyeBeam includes support, but for an older version. Googletalk uses 
Jingle, which extends Jabber with ICE in a proprietary signaling 
protocol. There are other hard and soft phones that support ICE, and an 
open source implementation is in the works.

Jonathan is asked if ICE clients learn or store routing information 
between calls. He says that they do not, and this is somewhat 
intentional as addresses are often transient and based on a variety of 
servers and relays. It's hard to say that something that worked once 
will necessarily work again. One major goal of ICE is to make as few 
assumptions as possible, with the goal of making SIP "just work". He 
also explains that there are different ways to weight priorities for 
clients based on past experiences and to allow local optimizations.

Jonathan also says that ICE isn't necessarily tied to SIP, but should 
work for any ask-answer protocol. It is modeled as an abstract protocol 
for anything that is setting up a session. There is work in the IETF to 
use ICE for RTSP, and it should also work for video to reduce latency. 
TCP and TLS support make file sharing possible. ICE is not generally 
integrated into any operating system, but is usually in a library 
invoked by a SIP stack.

Dennis asks about session border controllers and ICE. He wonders about 
using SBCs to do NAT traversal once ICE becomes more common. Jonathan 
confirms that using border controllers strictly for NAT traversal would 
become obsolete, though they are still useful for things like security. 
In essence, an SBC dedicated to NAT traversal would evolve into a TURN 
and STUN server.

Christian asks about the first two steps of the ICE transaction, and if 
they are always done or only done at call setup. The spec says that they 
are only done at setup, usually based on some interface clue like a user 
picking up a receiver or a mobile user entering their address book, at 
which point the allocation is performed. The idea is to avoid call setup 
delays. Keeping candidates available is inefficient and would require 
traffic every 20 to 30 seconds to refresh any relays and keep NAT 
bindings alive. On the receiving end, allocation is done before the 
ringing of the phone so it is not perceived as a delay.

Jonathan mentions that there have been some instances 
non-interoperability, which is mostly due to implementations of older 
versions of the ICE draft. The spec has taken a long time to finish, 
roughly three and a half years, and versions have not been backwards 
compatible. Several groups have decided to wait until a finalized 
version in order to implement ICE, while others have gone ahead with 
various versions of the draft. Jonathan acknowledges that the spec is 
complicated, as it depends on two endpoints doing the same thing to 
perform a task.

He mentions that they are coming to a conclusion with the spec, and it 
is currently in a "last call" state. Comments have been received, and 
should be incorporated into a revision within the next week after which 
it will go out for a final approval. One change is that it was decided 
that ICE would deprecate ANAD, which is a smaller specification for IPv6 
transition. ICE turned out to be a better protocol for dual-stack 
transition, and is now mentioned in IPv6 transition documentation.

In the future there will be a related spec for performing similar work 
with TCP, which is not as mature as the UDP efforts and is much more 
complicated. Like most protocols, ICE allows for extensibility and 
should be broadly used as a SIP protocol. Another discovery is that ICE, 
with its STUN checks, helps to prevent a specific type of DOS attack.