Sunday, March 21, 2010

NAT traversal - MS-ICE2 and MS-TURN

For the last few months, I have been working on changing Eyeball AnyFirewall Engine (AFE) so that it can work with Microsoft Office Communication Server (OCS) and Microsoft Office Communicator 2007 R2 (MOC).

OCS is basically a SIP server. One part of OCS is called the "edge" server, which acts as a TURN server.

MOC is a SIP client. It can make voice or video calls.

AFE is a NAT traversal library that offers a high-level API to be used by an application. AFE uses IETF standards STUN, TURN and ICE to solve the NAT traversal problem in VoIP.

TURN is the protocol which can be used by a client to open a "relay port" in a TURN server. If the client is unable to use a host port for being behind a NAT, it can use the relay port or the server-reflexive port for its purpose. The TURN server is normally located outside any NAT.

ICE is a protocol by which two clients can weigh the possibility of establishing connection between them through different paths, and choose the optimal one. This is done by exchanging STUN connectivity checks.

MOC and OCS use protocols that are slightly different from the IETF standards. For example, MOC uses MS-ICE2 based on IETF ICE-19. For communicating with the OCS edge server, MOC uses MS-TURN, which is based on IETF midcom TURN-08.

There are many details about the implementation of these protocols. Allocating the relay ports, forming the SDP, carrying out ICE connectivity checks, nominating the best path - these are some of the broad steps.

The AFE can now successfully interop with MOC and OCS. Initially, we had a tough time figuring out why some of the ICE checks were failing randomly. Later it was found that the CRC table used by MOC for the calculation of STUN fingerprints is slightly different from the usual table in one value. After adapting this, everything is running quite smoothly.