Session Initiation Protocol and Session Description Protocol

The two standard protocols that govern session control are the Session Initiation Protocol (SIP) and Session Description Protocol (SDP). These standards were originally intended for loosely controlled multimedia conferencing over the Internet; however, they have developed into a functional alternative to the H.323 suite. In particular, the combination of SIP and SDP is functionally equivalent to that of H.225.0 and H.245.


SIP (see RFC 2543) was initially standardized by the Multiparty Multimedia Session Control (mmusic) (see www.ietf.org/html.charters/mmusic-charter.html ) working group in the IETF Transport area. As the work had grown, a specialized SIP working group was created (see www.ietf.org/html.charters/sip-charter.html ).

SIP was designed to create and tear down multimedia sessions. In its syntax, SIP is similar to the Hypertext Transfer Protocol (HTTP)—defined in RFC 2616—and it reuses many HTTP header fields (such as authentication). Like HTTP, SIP is ASCII text encoded. Unlike HTTP, however, SIP was developed with the intention of addressing human users, for which reason the uniform resource identifier (URI) defined by SIP looks more like an e-mail address than the address of a World Wide Web page. For example, sip:hui-lan.lu@bell-labs.com is a SIP URI. For the purposes of integrating the PSTN and the Internet, it is important to note that SIP message headers can also carry other URIs (such as telephone URLs, defined by the IETF).

SIP is a client-server protocol: A client generates a request, to which a server sends one or more responses. A (potential) session participant can both generate and receive requests, which suggests that the end systems should have both the client and server capabilities. SIP also supports transaction capabilities. The RFC 2543 definition of a transaction is:

A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final . . . response sent from the server to the client.

Transactions are assigned the command sequence (CSeq) numbers. The SIP nomenclature (similar to that of SNMP and HTTP) alludes to the object-oriented model by defining the following methods that are carried in SIP requests (one method per request):

• INVITE. Conveys the information about the call to invited participants. It is issued in order to set up a call, and once the call is set up, it can be issued by any party to the call in order to change the call parameters or to add another party.
• BYE. Terminates a connection.
• OPTIONS. Solicits information about a user’s capabilities.
• CANCEL. Terminates the search for the user.
• REGISTER. Makes the user’s location known to a SIP server.
• ACK. Invokes the reliable message exchange for invitations. (Note that SIP has its own mechanism for invitation exchange; thus, it can run on top of an unreliable transport layer protocol such as UDP.)

The invitation to a session is accompanied by the Session Description Protocol (SDP) defined in RFC 2327, also developed by the mmusic working group (WG). SDP provides the description format (not the protocol) of the multicast and unicast addresses, the number and types (that is, audio, video, data, control) of streams involved, the codecs involved (that is, the payload types to be carried by the transport protocol), the transport protocol itself (for example, RTP or H.320), the UDP port, the list of starting and stopping times of the session, encryption keys, and so on. Keep in mind that SDP is only one possible payload of SIP; SIP can also carry all Multipurpose Mail Extensions (MIME) types, for example.

In the following section, we discuss location of clients and servers. In a perfectly valid degenerated case, both a client and server can be located in the same host. The opposite extremity, which is strategic to network-wide applications of SIP, is when several SIP servers located in different hosts act as proxies. In this case, server A, after having received a request from a client, may consult a local directory (by using LDAP, for example), only to find out that there is another SIP server, server B, which is better suited to respond to the request. Server A forwards the request to server B, which, from now on, will route its responses through server A.

The proxies can form a routing chain of any length. Figure 1 demonstrates such a chain. You have probably noticed a striking similarity between this figure and Figure 1. This similarity is actually profound, and it has been among the major factors that have influenced the pint working group to adopt SIP as the foundation of the PINT Protocol. SIP also offers a natural solution to the problem of gateway discovery, which is being worked on in the IP Telephony (iptel) working group (www.ietf.org/html.charters/iptel-charter.html).

Figure 1: SIP routing.

http://simple-telecom.blogspot.com