In the first part of this article series, I talked about the basic functionality of SIP, and how SIP fits in with...
some other commonly used protocols. In this article, I want to continue the discussion by talking about how SIP performs some of the tasks that I talked about in Part 1.
Basic SIP Operation
As I explained in the first part of this series, there are certain tasks that SIP is responsible for performing. SIP performs these tasks by issuing commands, which are commonly referred to as verbs. Any time that SIP issues a verb, the host that the verbs are being transmitted to responds with a numerical code. This code tells SIP the results of the requested action so that it knows what it needs to do next.
Later in this article, I'm going to show you some of the more commonly used SIP verbs, and provide you with a general overview of what the response codes mean. Before I get into all of that though, I want to give you an example of how the process works as a whole.
Perhaps the most commonly used verb associated with SIP is REGISTER. REGISTER is used primarily for logging into the SIP environment, but the REGISTER verb can also be used when a user is logging out or changing locations.
With that in mind, here's a condensed version of what happens when a user tries to log into an Office Communications Server:
- Since Office Communications Server 2007 uses SIP, the client machine issues the Register verb to the server.
- Because of the security that Office Communications Server uses, a user can not register with the server without first logging on. Therefore, the Office Communications Server returns an error. As I mentioned earlier, SIP issued verbs are met with numerical responses. In this case, the response code is 401, which indicates that the registration was unauthorized.
- In response to the error, the client reissues the register verb. This time though, the registration will supply a set of Kerberos credentials.
- The Office Communications Server accepts the credentials, and returns a response code of 200, which is SIP's OK response. Basically, this means that the command completed successfully.
Other SIP Verbs
Now that I have talked about the REGISTER verb, and given you a brief (and simplified) example of how the verbs and responses work, I want to talk about some of the more commonly used SIP verbs.
The first two verbs that I want to talk about are SUBSCRIBE and NOTIFY. These two verbs work together to make it possible to use presence information. Suppose for instance that User1 wanted to monitor the presence information for User2. User1's client application would issue a SUBSCRIBE command to the host server indicating that they wanted to monitor User2. The Host would return a response code of 200, indicating that the command was successful, but then the host would issue a command of its own. In this case, the host would issue the NOTIFY command to the client, informing them of User2's current status. Upon receipt of this information, the client would return response code 200 to the server. This process is repeated any time that User2's presence information changes. Since User1 has subscribed to the information about User2, the host will Notify User1 any time that User2's status changes.
Another verb that I want to talk about is the SERVICE verb. In the previous example, I talked about how a host could notify a subscriber when another user's presence information changed. However, the user whose presence information changed needs to have a way of informing the host of that change. This is where the SERVICE verb comes in. Any time that a user needs to change their presence information, their client application issues a SERVICE command to request that the host perform some kind of service; in this case making a change to the presence information. The SERVICE command can also be used to do things like creating or modifying conferences.
Another commonly used verb is INVITE. The INVITE verb is used to establish a peer-to-peer communications session. Probably the most well known use for the Invite verb is in establishing instant messaging sessions, but it can also be used for establishing audio and video conferencing, application sharing, and whiteboarding.
There are a few other really common verbs that I want to quickly mention. Below is a list of these verbs and a brief description of what they do:
ACK - ACK is an acknowledgement that is sometimes sent to a host in response to response code 200.
BYE - Used to terminate a session.
CANCEL - A request to cancel an Invite request.
Now that I have talked about some commonly used verbs, I want to talk about some of the response codes that are used. Generally speaking, response codes are grouped into ranges. Codes within a range have similar functions. The table below lists the ranges that are used, and what the function of that range is:
|100 to 199||Codes in this range are informational, and typically indicate that the server is attempting to process the request.|
|200 to 299||200 range codes are success and acknowledgement codes. These codes indicate that the request has been processed.|
|300 to 399||Response codes in the 300 range indicate a type of service error called a redirection error. What this means is that the current host cannot handle the request, so the request is being redirected to another host.|
|400 to 499||Response codes in the 400 range are client errors, but they usually correspond to security events. For example, a client would receive an error code in this range if it supplied an invalid password.|
|500 to 599||500 range response codes indicate a server error. For example, a code in this range would be generated if the server cannot be found or if it doesn't respond.|
|600 to 699||Codes in this range are global error codes.|
In this article, I have talked about some of the more commonly used SIP verbs and response codes. In part 3, I will conclude this series by talking about SIP routing.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.