Session Initiation Protocol

Session Initiation Protocol (SIP) is an alternative to H.323. It was created for the distribution of multimedia content. SIP supports a variety of architectures and protocols and is modeled after HTTP using plain text, which allows for easy packet inspection by administrators. It uses a Request-Response model (or INVITE model). It supports several types of proxy servers and operates on the Application layer of the OSI model. It leverages separate protocols that can be used without making any core protocol changes. It is totally independent of the voice path.

Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).

SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.

A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.

A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.

SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.

No comments:

Post a Comment