An ICE Implementation

You have probably noticed that NAT devices are quite widely deployed today (chances are that you are reading this page behind one right now) and you have certainly also noticed that NATs tend to cause problems for many VoIP applications. The problem is not new and the IETF has been on it for a while. There are a number of techniques that are supposed to resolve it, like for example the STUN and TURN protocols, but most of them come with serious reliability or scalability tradeoffs.

Because of the above issues the MMUSIC IETF working group has developed a protocol for Interactive Connectivity Establishment most often referred to as ICE. ICE completely reuses STUN semantics so any ICE implementation could also be viewed as an extension to a STUN protocol stack and to the way VoIP clients use it.

SIP Communicator currently includes a sub-project called stun4j that implements the STUN protocol. The purpose of this project would be to first upgrade the stun4j project to support the ICE address negotiation mechanisms, add client support for TURN, and integrate the whole in SIP Communicator.

That’s a lot of work so you’ll be working in close collaboration with some of our developers (who would also be your mentors).

Think you can handle it? We hope you do! :)

References:
The MMUSIC working group
http://www.ietf.org/html.charters/mmusic-charter.html

The ICE specification
http://tools.ietf.org/html/draft-ietf-mmusic-ice

The TURN specification
http://tools.ietf.org/html/draft-ietf-behave-turn

The STUN specification
http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis

The Stun4J implementation
http://stun4j.dev.java.net

Other SIP Communicator GSoC 2008 Projects
http://www.sip-communicator.org/gsoc

SIP Communicator Developer Documentation
http://www.sip-communicator.org/index.php/Documentation/DeveloperDocumentation

The official SIP Communicator website
http://www.sip-communicator.org