In the near future, if you make a telephone call, it's quite likely that the Session Initiation Protocol will be what finds the person you're trying to reach and causes their phone to ring. SIP is all about calling people and services.
The most important way that SIP differs from making an existing telephone call (apart from that it's an IP-based protocol) is that you may not be dialing a number at all. Although SIP can call traditional telephone numbers, SIP's native concept of an address is a SIP URL, which looks very like an email address.
When you email joe@gadgets.com, as a user you have no real idea which computer at gadgets.com your email will eventually reach, or indeed if Joe is currently contracting at another company, your message may even be forwarded there. All you wanted to do was to send a message to Joe.
The SIP authors believe that making a telephone or multimedia call should be similar - you want to call Joe, but you don't really care exactly which ``phone'' Joe uses to answer your call. SIP solves this problem by combining user location with the request to set up the call. It might seem that these should be separate, but this is not the case - the routing the call takes may depend on who is trying to make the call. If Joe's sister calls him while he's out at lunch, he might want the call to be routed to his cell-phone, but if his boss makes the same call, the call gets routed to his voice-mail. For privacy reasons, performing user location without actually making the complete call is simply unacceptable to many people.
So how does SIP do this? SIP makes extensive use of proxy servers, each of which looks at the call request, looks up whatever local information it has about the person being called (i.e., the callee), performs any security checks it's been asked by the callee or her organisation to make, and then routes the call onward.
When I call jane@euphoric-state.edu, my computer (or phone exchange) looks up euphoric-state.edu in the Domain Name System (DNS) and looks for a SIP service record giving the address of the SIP server (in this case sip.euphoric-state.edu) for Euphoric State University. It then sends the SIP request to that machine. At sip.euphoric-state.edu, the server consults a database and discovers that Jane is a staff member in the Computer Science department, and that the SIP server for CS is sipgw.cs.esu.edu. It then sends the SIP request on to sipgw.cs.esu.edu, which again consults a database. This new database happens to be built dynamically by SIP clients registering when people log on. It turns out that Jane is a professor, and computer science professors never adopt new technology early so her workstation is not capable of multimedia conferencing. Instead sipgw.cs.esu.edu routes the call to her regular telephone and it acts as a gateway into the department PBX.
The example above uses proxies that relay the SIP call. This is illustrated in figure 6.3. Relaying is often performed when the gateway or firewall to a site wishes to hide any search that goes on internally from the caller's machine.
An alternative to relaying is redirection, which is illustrated in figure 6.4. Redirection makes the caller's machine do any additional work, so it makes life easier for the proxy server. This might be appropriate when the callee has moved outside of the local network of the proxy.
Of course if you do know the machine the callee is using, you can also direct the request there directly without going through any proxies, but some sites may insert a proxy in the path anyway because the proxy is on their firewall machine.
Figure 6.5 shows a complete SIP call, with the arrows indicating SIP requests and responses passing backward and forward. In this case the SIP INVITE request for eve@isi.edu is sent to isi.edu, but is then redirected to eve@east.isi.edu. A new INVITE request is then made, which succeeds in finding Eve, and causing her phone to ring, which is reported back to the caller. When Eve picks up the phone, the request is completed with a ``200 OK'' response, which is in turn acknowledged, and a voice call is set up. Multimedia information is now exchanged using RTP for as long as they continue to chat. After they've finished their conversation, the caller hangs up, and this causes a SIP BYE request to be sent, which proceeds to close down the call.
SIP can set up many types of call, not just telephone calls, because it was originally designed for setting up multimedia conferences. However, the world can be a very heterogeneous place, and the person making a call may not be able to predict what equipment is available at the other end to receive the call. For example, I may make a video-phone call to you, and although you may have an equivalent video-phone on your desk, it happens that you're out of the office when I call. Instead my call is redirected to your cell-phone, which unfortunately doesn't yet support video-conferencing, but it could perfectly well support an audio call.
This is illustrated in figure 6.6. The original call attempt requests an audio/video call, and is relayed to mobile27.isi.edu. Mobile27 is a cell-phone, and so it rejects the call with a ``606 Not Acceptable'' response code indicating that an audio-only call would be possible. A new call attempt is made suggesting an audio call, and then everyone is happy.
Next: SIP Protocol Details
Up: Session Directories, Advertisement and
Previous: Session Announcement Protocol (SAP)
Jon CROWCROFT
1998-12-03
