In the previous tutorials in our study of the Session Initiation Protocol (SIP), supported by the Internet Engineering Task Force (IETF), we considered the history and architecture of SIP, the capabilities of the protocol, and the message formats, and the role of the Session Description Protocol (SDP). This tutorial will bring it all together to discuss SIP Signaling—the methods and procedures through which SIP connections are established.
In our discussions on H.323 Signaling, we considered the processes that are specified by the H.323, H.225 and H.245 protocols to establish a connection between two end stations. The SIP signaling is somewhat similar, but much simpler, as a result of the pragmatic nature of the IETF.
This straightforward approach is evident in the SIP call setup procedures. The most basic configuration is used to establish a call directly between two end stations (without the use of any intermediate proxy servers). In this simple case, the calling party would send an INVITE message to the called party to initiate the session, who would respond with Ringing and OK messages. The calling party would then return an ACK (acknowledgement) message, which would complete the connection, and allow information to be exchanged between the two parties. When the connection is no longer required, one party sends a BYE message, with an OK message returned in response, thus terminating the call.
A more complex example, which is described in the SIP standard, RFC 3261, Section 4, uses proxy servers in the communication path. A proxy is someone or something that acts on behalf of another person or entity. For example, if you own shares in a public company, and are not able to attend the annual meeting, you send in a proxy ballot that enables another person or group to vote on your behalf. In a similar manner, a SIP proxy server acts as an intermediary for the purpose of making requests on behalf of other SIP clients, and in many cases, functions in a routing mode, forwarding SIP requests to another device that is closer to the ultimate destination (i.e. the called party).
As a result, the SIP proxy server has a dual role—it acts as a server when it processes end user request messages, but it can also act as a client when it forwards a message to another device downstream. Note that the proxy server must be able to interpret a SIP message (such as an INVITE), and re-write that message as necessary before it is forwarded on. Large networks may include more than one proxy server in the path from a calling to a called party.
An interesting example, taken from RFC 3261 Section 4, describes the call setup procedures between two SIP end stations when two proxies are used. In this example, the two end stations are in different cities (Atlanta and Biloxi), and therefore on separate networks. Each network has its own proxy server, designated atlanta.com and biloxi.com, respectively. If Alice in Atlanta wanted to call Bob in Biloxi, Alices phone sends the following INVITE message, which is the read and forwarded by the atlanta.com proxy:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
Notice the many protocol constructs that we have discussed in previous tutorials, are included in this message. These include: the SIP URI format (sip:bob@biloxi.com), the Via command (specifying the atlanta.com proxy), and the Content-Type command (application/sdp), which would include a media information for this call, as defined by the Session Description Protocol (SDP) format.
Once the message traverses all the intermediate networks, it reaches Bobs station. If he is willing to accept the call and initiate a session, his station returns an OK message, which is forwarded by the biloxi.com proxy:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
Note that the same Call Identifier (Call-ID: a84b4c76e66710@pc33.atlanta.com) that was sent with the INVITE message is returned in the OK response, so that Alice and Bob can keep this session unique from other ones that they may have open at the same time.
Additional details on this example, plus many others, including those which describe the use of other SIP servers, such as the Register server and Location server, are detailed in the 269-page RFC 3261, and are left for the research of the readers.
From the example given above, it should be clear that many parameters are passed between SIP clients when the call is initiated. Our next tutorial will examine the issue of testing and interoperability between various vendors SIP products, to assure that those logical connections operate as they were intended.
Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved
Author’s Biography
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.
