Last week’s tutorial began our examination of the Session Initiation Protocol (SIP), supported by the Internet Engineering Task Force (IETF), where we considered the history and architecture of SIP, and also looked at some of the related Internet protocols that have influenced the SIP design Here, we will extend that discussion to consider the functions that SIP performs within that architecture.
SIP is an application protocol; that is to say, it provides services to end users. The SIP architecture, as defined in RFC 3261, builds upon two other Internet application protocols, the Simple Mail Transfer Protocol (SMTP), which is defined in RFC 2821 and specifies the format for electronic mail messages, and the Hypertext Transfer Protocol (HTTP), which is defined in RFC 2616 and specifies the format for web-based multimedia communication. Like SMTP and HTTP, SIP uses the Internet Protocol (IP), the User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) for the underlying network infrastructure. As such, it could be viewed as another component —or application —of a comprehensive suite of Internet-related (and IETF-defined) protocols.
However, the operative application service that describes SIP is session, which could be defined as an orderly exchange of information between two or more participants. Digging deeper, SIP must first act to create the session, and thereafter, manage the session as long as communication is required. And while this charter may seem quite straightforward, a few complications can arise. The first could be the existence of more than two participants, meaning that the call would be a multipoint (or conference) call, rather than a point-to-point (or end-user-to-end-user) call. Second, the end users may not always originate the call from the same location, adding the requirement for keeping track of those end users. Third, the end users may employ a mixture of media types —text, voice, and/or video —all with different constraints and parameters, such as bandwidth requirements, maximum permissible transmission delays, and so on.
To support this session service, RFC 3261 describes five facets of multimedia session management for SIP:
- User location: determining which end system will be used for communication.
- User availability: determining whether or not the called party is willing to engage in communications.
- User capabilities: determining the media and media parameters to be used for this communication.
- Session setup: establishing the session parameters at both the called and calling parties.
- Session management: including the transfer and termination of sessions, the modifying of session parameters, and the invoking of session services.
We also discovered that the SIP architecture describes two functional devices: clients and servers, also similar to SMTP and HTTP. A client is a network element that sends SIP requests and receives SIP responses. A client may or may not interact with a human user. Similarly, the server is a network element that receives requests in order to service them, and then responds to those requests.
This client/server operation, modeled on the HTTP request/response paradigm, is one of the major strong suits of SIP. Within HTTP, clients send requests for network resources (such as a web page) to a server, which provides one or more responses. In the case of SIP, the client (such as a User Agent Client or a Proxy) sends a request to the server (such as a User Agent Server, a Redirect Server, or a Registrar) requesting communications resources, or some modification to existing resources. An example of a SIP request message from the client to the server would be an Invite message, which indicates that the user or service is being invited to participate in a communications session. If that request message could be completed, a Success response would be returned from the server. Of course, not all stories have happy endings, so other responses may convey error or failure conditions as well, but that is a topic for another tutorial.
Thus, with a background from other well-known protocols, such as HTTP, plus a straightforward client/server architecture, SIP is positioned to operate as an effective member of an IP-based internetwork. The specific messages that are sent between these clients and servers that facilitate SIP operation will be the subject of our next tutorial.
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.
