VoIP-Forum

SIP and NAT, network address translation, doesn\’t like each other. SIP invites are often initiated from a private IP number inside the NAT Firewall. So when the SIP invite reaches the other party, there\’s no way to set up a session. With STUN, there\’s a way for the other party to find out the IP and port of the NAT and connect through the NAT. This is work in progress, but closely watched by all SIP users and developers.

Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of J. Rosenberg et. al. [Page 1]  Internet Draft STUN October 14, 2002 applications to work through existing NAT infrastructure. J. Rosenberg et. al.

• IETF DRAFT: Simple Travelsal of UDP through NATs

SIP Express Router 0.8.10. A very fast and flexible SIP (RFC3261) server. [freshmeat.net]

A new draft that combines SIP with the XML-based version of iCalendar. Using SIP to invite people to meetings, to schedule
conferences makes sense to me. Competition in the protocol world!

"This document, proposes a binding from the abstract iCalendar Transport-independent Interoperability Protocol (iTIP) using Session Initiation Protocol (SIP) as transport and SIP/SIPS URIs as addresses. This document proposes using the XML iCalendar or xCal as a mandatory payload format with SIP. XML iCalendar is an XML DTD that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. SIP is a application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, retrieving user presence and sending instant messages."

• iCalendar SIP-Based Interoperability Protocol

This IETF draft outlines a mechanism for using the SIP proxies to authenticate the caller to the recipient. The author does not believe that end user equipment will support TLS certificates for authentication from SIP client to SIP client directly with S/MIME.

"The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages."

• Enhancements for Authenticated Identity Management in
  the Session Initiation Protocol (SIP) - J Peterson