Subject: SIP in higher education
VoIP SIG minutes - Jonathan Rosenberg, May 10, 2007
- From: Garret Yoshimi <>
- To: Internet2 VoIP SIG <>, "Internet2 SIP.edu" <>
- Subject: VoIP SIG minutes - Jonathan Rosenberg, May 10, 2007
- Date: Thu, 31 May 2007 17:42:51 -1000
- Organization: University of Hawaii
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.
- - - - - VoIP SIG Conference Call - May 10, 2007
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
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.
- VoIP SIG minutes - Jonathan Rosenberg, May 10, 2007, Garret Yoshimi, 05/31/2007
Archive powered by MHonArc 2.6.16.