A lot of very different services can be offered on top of the Internet and, in general, on top of an Internet Protocol (IP) network—a network based on the Internet Protocol.^[1] It is not at all easy to find a categorization of those services from the user’s perspective, but we will try to offer a simple one here, with the purpose of allowing us to understand what the remit of IP multimedia communication services is.

A very high-level approach might split the services offered on the Internet into three different categories or domains from the end-user perspective. A first category might include the infotainment services—that is, those services that give the user access to information and entertainment applications typically stored and executed in remote servers. The web would represent the paradigm for this kind of services. A second category would include the streaming services. These allow the user to access, in real-time, either live or stored time-based media content. Video-on-Demand (VOD) or the hot Internet Protocol Television (IPTV) service would fall into this category. The third service type includes the communication services—that is, those that allow people to communicate with each other using different types of media. A voice call or an email exchange would be examples of communication services (Figure 1.1).

Figure 1.1. 

Communication services can be further classified into offline and online. In online communications, both originator and recipient need to be “connected” simultaneously for communication to happen, and the exchange of information occurs immediately between them. Examples of this include a voice call, an IM exchange, or a chess game.

In offline communication services, the involved parties do not necessarily need to be “connected” simultaneously for communication to happen. The popular email service is a good example of this. In the email service, the submission of information is decoupled from its reception by a store and forward mechanism, so the parties can communicate with each other even if they are not connected at the same time. Let us imagine that John wants to send an email to Alice. He switches on his computer, starts the email program, and sends the message. At that point, John closes the program and switches off his computer. Sometime later, Alice starts her email application and checks if new mail has arrived. She sees John’s email and reads it. As we can see, John and Alice do not need to be connected simultaneously for the communication to happen.

The type of information (i.e., media) that can be exchanged in online communication services can be quite diverse. For instance, we might want to exchange real-time media such as voice or video, which have very stringent timing requirements. Packets containing voice samples should be received at regular intervals of some milliseconds so as to allow the receiver to play them back at the appropriate rate.

We might also want to exchange quasi-real-time information—that is, information that has requirements for timely delivery, but not as strong as in the case of voice. An example is an IM session or a chess game. In order to keep the interactivity in the session, data needs to arrive quickly enough—though, in this case, one or two seconds’ delay would not impact the end user’s experience.

Another type of information that we might want to exchange in online communication services is a prestored image or file. This scenario typically occurs in combination with an exchange of other types of media. Take, for instance, the case of John and Alice, who are engaged in a Voice over Internet Protocol (VoIP) conversation. John is at his 3G (third-generation) IP multimedia-enabled phone. Meanwhile, Alice is sitting at home in front of her PC. While talking to Alice, John takes a picture of a beautiful landscape with the camera integrated into his phone. He decides to show the picture to Alice. The image file would, in this case, be sent online and conveyed immediately to the recipient while both parties are talking so that they can comment on it (Figure 1.2).

Figure 1.2. 

Online IP communication services are typically referred to as IP multimedia communication services, and that is the term that we will use throughout this book.

Unlike what occurs in other type of services, signaling plays a key role in IP multimedia communication services. SIP is typically used as the application-level signaling protocol in that remit, and therefore its role is crucial.

It is important to understand that SIP has not been designed to replace existing Internet application-level protocols such as those used in web (Hypertext Transfer Protocol, or HTTP) or email (Simple Mail Transfer Protocol, or SMTP; Post Office Protocol version 3, or POP3; Internet Message Access Protocol version 4, or IMAP4). On the contrary, SIP covers a piece that was originally missing in the Internet architecture—that is, the signaling mechanism for multimedia communication services. SIP was designed in such a way as to fit smoothly with the existing Internet services and protocols such as web or email, so that, when combined with them, the promise of an all-IP total communications system encompassing all type of services can be made a reality.

It is also important to understand that SIP, all by itself, is not capable of delivering multimedia communication services. It needs to work alongside other protocols to accomplish that function. Most importantly, because SIP is a signaling protocol, it needs to work together with other protocols at the media layer.

In order to get a first understanding of the role of signaling and media protocols in IP multimedia communications, let us start by looking at a very simple example of voice communication on the Internet.

Let us assume that John and Alice, who are both in front of their PCs connected to the Internet, want to have a voice conversation. Each of them has a microphone and a loudspeaker connected to the soundcard in his or her computer. John is running a program such that, when he speaks on the microphone, the soundcard samples and encodes the voice signal into a bitstream. The computer program takes this stream of bits representing voice samples, and puts them into IP packets. These packets are then sent to Alice through the Internet. In order to make the packets reach Alice, the program in John’s computer has to fill in the IP packets with the IP address of Alice’s PC.

At the other end, Alice’s PC receives the IP packets, decodes the voice samples in the payload, and feeds them into the soundcard so that they can be played.

In order for this real-time communication to work, this entire process has to be done with minimal latency, and it has to be done very regularly. Fortunately, PC programs can easily achieve this thanks to advances in computer technology.

In our example, we have considered that the voice samples are carried over IP protocol. Instead of conveying the samples directly over IP, an upper-level protocol is generally used. The information exchanged between the communicating parties (in this case, the voice) is typically referred to as media; thus, these protocols are referred to as media transport protocols. Different media transport protocols are specially suited to the type of media that needs to be conveyed. For instance, if the media is voice, a protocol called RTP (Real-time Transport Protocol) is typically used, which runs on top of User Datagram Protocol (UDP)/IP. RTP contains features that facilitate the transport of pure real-time traffic, such as voice, over IP networks. RTP and other media transport protocols are further described in Chapter 10.

Figure 1.3 depicts the previous example.

Figure 1.3. 

So we have seen in the example how a simple voice communication might be enabled in the Internet, and we have understood the need for:

Are these two aspects enough, or do we need something more in order to enable fully fledged online communications? In order to answer this question, let us look at some of the additional challenges that the previous scenario presents.

First of all, we were assuming that both John and Alice were already available, prepared, and sitting in front of their PCs at the time communication started. Of course they might have agreed sometime before, through other means, that they both would have this communication at a specific date and time so they could be prepared for it—but that is not really a practical approach. Also, it is not efficient, from the resource-utilization perspective, to have the microphone, the loudspeaker, the soundcard, and software program permanently activated and processing the voice signals in the environment or listening for the voice packets being transmitted in the network. What is needed here is a mechanism by which John can first signal to Alice his desire to start a communication with her. This would be like an invitation signal sent from John’s PC to Alice’s. When this signal reaches Alice’s PC, it would need to trigger some alerting mechanism—for example, a ringing audio signal—that can attract Alice’s attention even if she happens not to be in front of the PC at that precise moment. This would be analogous to the ringing of the phone in the traditional, legacy phone system.

Secondly, John may want to be informed about the progress of the communication process. For instance, he may need to know that his invitation went through and that Alice is being alerted. Most importantly, he needs to know when Alice accepts the communication so that he knows when he can start speaking. This event is also very important for the computer program because it will trigger the activation of the necessary resources in the PC (soundcard, IP resources, and so on) just at the precise moment when they will be needed, thus optimizing resource usage.

The third aspect refers to the fact that in order to send voice samples over the network, they first need to be encoded. Likewise, the encoded data needs to be decoded at the receiving end. This coding or decoding process can be done by specialized hardware (the soundcard) or within the communication software running on top of the operating system, which is termed software CODEC (COder/DECoder). In any case, there are quite a few standard ways to code and decode the voice signals, and it is crucial that the codec used in John’s PC matches the one used by Alice. Because there may typically be many different codecs installed in both PCs, it is necessary that, prior to starting the voice communication itself, John and Alice agree on the codecs that they will use for this particular communication. In other words, there is the need to agree on some voice-related parameters (e.g., the voice codecs) before communication can start.

The fourth aspect refers to the way addressing is done. In our example, we said John’s program needed to add Alice’s computer IP address as the destination address in the IP packets that it sent to Alice. This is actually cumbersome because it forces John to learn Alice’s IP address as a set of four numbers, each of them ranging from 0 to 255.^[2] Most importantly, a true communication system should be available for the user irrespective of his or her actual location (IP address). Alice would expect to be able to use the service from her PC at home connected to the Internet through Asymetric Digital Subscriber Line (ADSL), but also when at the office or, when traveling with her laptop, or with her Internet Multimedia Subsystem (IMS)–enabled mobile phone. The problem is that, as location changes, so does the IP address of the device. So how can we guarantee that Alice will be able to receive the call from John irrespective of her location?

All the aspects highlighted above call for the need to exchange some extra information between John and Alice. This is not actually voice information (media), but rather, information that helps John and Alice to control the way voice communication occurs. This control information is called signaling, and is sent in messages between Alice’s and John’s computers according to some signaling protocol. SIP is one such signaling protocol that can convey this type of information, but there are also others.

The relevance of signaling in this context is huge—not just in order to cope with the basic call scenarios, but also to enable more-complex multimedia value-added services. Accordingly, SIP plays a major role in making all these new services possible.

So we now have a clearer picture of what a true multimedia communication system requires in terms of information exchanges:

The set of functions and elements that participate in the processing and exchange of the media are said to form the media plane (also called user plane). The set of functions and elements that participate in the processing and exchange of the signaling are said to constitute the Control (or signaling) Plane. Both the media plane and the control plane are integral parts of an IP multimedia communication system.

Figure 1.4 shows the two planes in a multimedia communication.

Figure 1.4. 

Both SIP and RTP are IP application-level protocols, meaning that they are sitting on top of the TCP/IP stack, and therefore they use the services provided by transport protocols such as UDP or TCP. Chapter 3 further explains the TCP/IP stack, and shows how the different protocols used in multimedia communications fit with it.

Media and control protocols are independent. For example, in the recent past, a lot of IP multimedia communication systems were using RTP in the media plane. Meanwhile, in the control plane, International Telecommunication Union (ITU) H.323 signaling protocols were used. Today, SIP is becoming commonplace as the signaling protocol in IP networks, and it is very often used with RTP in the media plane. Nevertheless, SIP can also be used with other Media Transport Protocols. For instance, some session-based Instant Messaging systems use SIP as the signaling protocol and Message Session Relay Protocol (MSRP) as the media transport protocol.

The previous example of voice communication between John and Alice was just meant to help the reader grasp the key concepts around signaling, and does not show all the power of SIP-enabled IP communications. More -sophisticated examples might be built with SIP. For example, communication between John and Alice might start out by being just voice, but after some minutes, Alice might want to add video so that she can show John the cake she is preparing for her birthday. At some point in time, they may even want to start playing a chess game through the Internet while they still talk to each other, or they may decide to stop voice communication but exchange real-time text messages while playing chess. Once they stop playing, Alice may want to show John a map of the new house she has recently bought, and write on top of it in order to mark where, for instance, the different rooms are located.

This would be an example of an IP multimedia call. Throughout this book, we will use the term “call” to refer to IP multimedia calls enabled by SIP. Obviously, this call concept is different from the traditional (voice communication only) telephone call that we are all used to. It is not only that the underlying technologies are completely different (the telephone call is supported by the legacy circuit-oriented telephone system, whereas the multimedia call is supported by the Internet), but also that the amount of services and communication experiences that SIP-enabled IP communications can offer does not have a match in the legacy telephone system.

In this section, we intend to give an overview of the different types of services that can be enabled by SIP. The list is not intended to be exhaustive.

In order to illustrate the concepts in the previous section, we will describe a few examples of commercial SIP applications that group some of the features previously mentioned.

In the web pages www.pulver.com and www.sipforum.org, the user can find a list of SIP commercial products in different categories:

A list of SIP service providers can be also found at www.pulver.com.

Within the SIP environment, there are a lot of open-source initiatives. We recommend that the reader visit www.sipforum.org, where he or she will be able to find more information on open-source SIP products and components.

SIP Communicator Applications

An SIP communicator is an SIP-based multimedia application hosted in the endpoint (i.e., PC, mobile device, laptop, and so on) that provides the capability to establish communications in different media such as voice, video, messaging, and file sharing—all of them integrated with presence and contact-list management. The typical interface that these applications provide shows a list of contact names. Associated to each contact is typically an icon showing the presence information for that contact. By clicking in a contact, a menu is displayed that asks for the type of communication requested (voice, video, messaging). The user clicks on the desired option, and the application sets up the required media session.

These types of services, though strongly based on the terminals, do frequently also require some back-end infrastructure, for instance, in order to store the presence and contact information.

SIP communicator applications allow for building on the “community” concept, and are becoming increasingly popular across the Internet. Such Internet players as Microsoft and Yahoo! have a significant customer base of SIP-based communicator customers.

Figure 1.5 shows the layout of one example of these applications.

Figure 1.5. 

Figure 1.6. 

According to [RFC 3233], the IETF is an “open global community of network designers, operators, vendors, and researchers producing technical specifications for the evolution of the Internet architecture and the smooth operation of the Internet.” The IETF is the main body responsible for defining Internet standards.

The IETF is formally an activity that falls under the umbrella of the Internet Society (ISOC). The society is an international nonprofit organization with individual and corporate members all around the world whose aim is to promote Internet use and access. Among other things, the ISOC provides insurance service and some financial and logistical support to the IETF.

The IETF is organized into eight study areas. These are:

The study areas are broken down into Working Groups (WGs). Each WG focuses on a specific topic, and is intended to complete work on that topic and then shut down. Most of a WG’s work is done via email. Anyone can participate in an IETF Working Group, and decisions are made by rough consensus.

The Internet Standards process is defined in [RFC 2026].

We have, in this chapter, understood what multimedia communications are and the role that SIP plays in this remit. We also looked at some examples of services that might be delivered through SIP. The way SIP and related protocols work is defined in Internet specifications generated by the IETF. We also learned a bit about how the IETF is organized and the types of documents that it generates. In the next chapter, we will review the past history of multimedia services in the Internet. As happens in other areas of knowledge, understanding the history can help us understand why things are as they are today.