This is undeniably the most important feature of SIP. All of the SIP features explained so far are useful only insofar as they convert SIP into a good plat-form for user services.
Reuse of Components SIP (deliberately) makes use of many Internet components also exploited by other Internet applications. This makes SIP the perfect protocol to combine into different services for the user. Specifi-cally, its similarities with HTTP [RFC 2068] and Simple Mail Transfer Pro-tocol (SMTP) [RFC 821] make it easy to combine the most successful Internet services so far (Web and e-mail) with multimedia. SIP not only integrates services, but it also delivers them to the user’s real location. For those in search of the holy grail of unified communications, SIP represents a revolution in combined services because SIP applications integrate Web browsing, e-mail, voice calls, videoconferencing, presence information, and instant messages in a straightforward way. Some people see SIP as the telecommunications industry’s next killer app.
SIP Is Based on HTTP A SIP implementation is rather similar to an HTTP implementation for the obvious reason that the former is based on the latter. Both use a request/response model, both are text based, and both
have a similar format for encoding protocol messages. These similarities enable an implementation to reuse code between the two protocols.
The utility in sharing code is highest for devices that have to provide Web browsing and SIP-based services. A SIP mobile phone with wireless Inter-net features will almost certainly implement both (Figure 4-16). Such devices lack the huge hard disks and tons of memory you’re used to on the desktop; they’re usually thin devices with serious footprint constraints for which the capacity gained by reuse is substantive.
SIP Uses URLs to Address SIP Resources Fortunately, the format used by SIP to address SIP entities is identical to the one used on the Web and by e-mail systems. This gives tremendous flexibility to SIP redirections and lets us integrate several forms of communication.
A redirect server typically returns an alternative address where the user can possibly be located. The redirect server is actually returning a URL. In most of our examples, it’s a SIP URL, but the server has no problem return-ing a Web URL or an e-mail address.
The Internet
Do you think I should pack my coat for
our vacation?
Let me check the weather forecast on the Internet...
Figure 4-16 Bob’s terminal implements both SIP and HTTP.
This way Bob can configure his SIP redirect server to send incoming voice sessions to his e-mail account. The server obliges by returning mailto:Bob.Johnson@company.com in response to a SIP request (Fig-ure 4-17). Laura, who’s notoriously impatient, can choose between leaving Bob a voice mail or writing him an e-mail. If Bob has redirected incoming sessions on his Web page, she can amuse herself by looking at pictures of his new puppy, car, or house while her call is in a queue.
Web pages can also include SIP URLs besides e-mail addresses, provid-ing click-to-dial features.
Having a SIP URL that can be redirected to any other means of commu-nication considerably reduces the amount of different contact information needed by an individual. Currently, an average business card contains at least a fixed phone number, a mobile number, a fax number, and an e-mail address (Figure 4-18). SIP distills all this to a single URL.
Users will contact our SIP server specifying what type of service (voice call, e-mail, fax) they want, and our redirect server will provide them with the proper URL.
Same Routing Concept as SMTP SIP messages are routed in much the same way as e-mail messages. They can also carry multipart message bodies using Multipurpose Internet Mail Extensions(MIME) [RFC 2045]. However, SIP is not good at transporting large amounts of data; it’s just not designed as a transport protocol. E-mail (mailto: Bob.Johnson@company.com)
(1) Invitation to a session for SIP: Bob.Johnson@company.com
On the other hand, it does deliver instant messages exceptionally well, which are small by definition and probably urgent, and intended to reach users at their present location. The same features also make SIP suitable as a protocol for presence. SIP registrars have to know when a user is online in order to deliver messages to him or her. Combining presence information with instant messages is another example of the advanced services that can be implemented by using SIP.
SIP Uses Existing Infrastructure for Providing New Services For instance, a ser-vice provider builds a SIP infrastructure for VoIP serser-vices, consisting of SIP proxies, redirect servers, and location servers. Customers of this service provider use SIP UAs to establish voice calls over the new infrastructure.
Because VoIP is the service that the customers want, the service provider is successful.
But as time goes by, customers do not find VoIP that exciting any more, and what they really want to do is play interactive games. The service provider doesn’t have to modify or retrofit at this point; it just has to pro-cure an updated SIP UA that uses a gaming session description protocol to establish subscriber sessions instead of SDP. Because the SIP servers in the network ignore the contents of the session description, the entire SIP infra-structure built with VoIP in mind is instantly repurposed without any changes to the network.
Widespread Knowledge of How to Program SIP Applications Programming SIP applications requires certain skills that are already widespread among programmers. Most programmers are used to Web applications, text parsers, and scripting languages, which are exactly what come into play when coding SIP applications.
Besides, because SIP messages are human readable, no need exists for special protocol analyzers to discover why two different implementations do not interact properly. In fact, no special knowledge is needed in order to cre-ate a SIP service. Programmers fresh from the university are equipped with
Bob Johnson
Telephone: +1 212 555 5555 Mobile: +1 212 555 5556 Fax: +1 212 555 5557
everything they need to innovate services, as long as they have the imagination. Not so long ago, this was far from true. Highly specialized knowledge was needed, and once the service was implemented, it was not easy to test. (Not everybody has the requisite telephone switch handy.) Today any personal computer can become a SIP server to test new applications.
This has an important implication. It means that the people creating a particular SIP service are the people who have the expertise on that par-ticular service; that is, organizations creating gaming applications will come to understand gaming and organizations developing messaging appli-cations will come to understand messaging. Today’s programming practice (much bemoaned) is to find a programmer who knows a protocol and teach him or her how the applications should work. SIP enables people who know the functional needs of a certain community to create their own services.
SIP Enables Application Decomposition SIP enables us to combine simple applications into more complex services [draft-rosenberg-sip-app-components]. For instance, if I want to build an application that gets input in the form of a text in Spanish, translates it into English, and produces output in the form of speech, I can look at the solution as several simple applications working together. The first application performs text transla-tion from Spanish to English. The second, which receives English text as input, converts it into English speech as output. This example comprises two application servers doing relatively simple things that can be tailored a hundred ways to meet a user’s need. The user employs SIP signalling to coordinate both application servers in order to obtain the expected global result.