SIP is described as a control protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet (or any IP Network) telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or via a combination of these. SIP supports session descriptions that allow participants to agree on a set of compatible media types. It also supports user mobility by proxying and redirecting requests to the user’s current location. SIP is not tied to any particular conference control protocol. In essence, SIP has to provide or enable the following functions:

This allows the group involved in a call (this may be a multi-party call) to agree on the features supported - recognizing that not all the parties can support the same level of features. For example, video may or may not be supported.

During a call a participant can bring other users onto the call or cancel connections to other users. In addition, users could be transferred or placed on hold.

A user should be able to change the call characteristics during the course of the call. For example, a call may have been set up as ‘voice-only’, but in the course of the call, the users may need to enable a video function. A third party joining a call may require different features to be enabled in order to participate in the call.

SIP fulfils these functions and re-uses other web elements to make it flexible and scalable. Rather than defining a new type of addressing system, SIP addresses users by an email-like address. Each user is identified through a hierarchical URL that is built around elements such as a user’s phone number or host name (for example, sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it ). This means that it is just as easy to redirect someone to another phone as it is to redirect someone to a webpage.

SIP uses MIME, the de facto standard for describing content on the Internet, to convey information about the protocol used to describe the session. As a result, SIP messages can contain Java applets, images, audio files, authorization tokens or billing data.

SIP borrows from the email model, using the Domain Name System to deliver requests to the server that can appropriately handle them. This simplifies the integration of voice and email. Servers along the call path can easily create and forward email messages, and vice versa, enabling various combined services.

SIP provides its own reliability mechanism and is therefore independent of the packet layer and only requires an unreliable datagram service. SIP is typically used over UDP or TCP.

SIP provides the necessary protocol mechanisms so that end systems and proxy servers can provide services:

User location

User capabilities

User availability

Call set-up

Call handling

Call forwarding, including:

The equivalent of 700-, 800- and 900- type calls;

Call-forwarding no answer;

Call-forwarding busy;

Call-forwarding unconditional;

Other address-translation services

Callee and calling “number” delivery, where numbers can be any (preferably unique) naming scheme

Personal mobility, i.e., the ability to reach a called party under a single, location-independent address even when the user changes terminals

Terminal-type negotiation and selection: a caller can be given a choice how to reach the party, e.g. via Internet telephony, mobile phone, an answering service, etc.;

Terminal capability negotiation

Caller and callee authentication

Blind and supervised call transfer

Invitations to multicast conference