IP multimedia communication services are built on top of the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite. In this chapter, we will briefly review the fundamental concepts around IP networks and the TCP/IP protocols. After that, we will describe the architecture and the application-level Internet protocols that have been defined to enable multimedia communications. It is crucial to understand that SIP (Session Initiation Protocol) is not the only protocol involved in delivering multimedia communication services. It is just one additional component, though fundamental, in the whole architecture.
For a comprehensive description of the TCP/IP protocol suite, I recommend the excellent Internetworking with TCP/IP, Volume 1 by Douglas E. Comer.
The core of the internetworking (or “internet”) concept is that of being able to provide end-to-end connectivity on top of a variety of underlying network technologies. The tool to accomplish this concept is the Internet Protocol. The IP protocol provides a homogeneous network layer that enables the interconnection of many different types of networks while at the same time hiding the details of these networks to the applications above. The networks below can support a variety of technologies such as Ethernet, ATM (Asynchronous Transfer Mode), frame relay, and PSTN (Public Switched Telephone Network). It is interesting to note that no internal change is required in each of these physical networks for them to be part of an internet[1] (this was a ground rule in the early design of the Internet back in the early 1970s).
Figure 3.1 shows an internet composed of three different physical networks that are interconnected through IP routers (R). Routers help to route the packets from source to destination. The end systems are called hosts (H). Hosts are the entities where the end-user applications reside. They are connected to the network through interfaces that are identified by an IP address. The IP address is the main parameter in the IP protocol, which is used for routing datagrams to their destination.
Both hosts and routers implement the IP protocol, and thus create a virtual-network layer that makes the applications in the hosts believe that they are sitting on top of a homogeneous network. This is shown in Figures 3.2 and 3.3.
We will now look at the main functions provided by the Internet Protocol.
The most basic service that the IP layer provides is defined as an unreliable, connectionless packet-delivery service. The service is called unreliable because delivery is not guaranteed. The network will do its best to deliver the packets, but under congestion or faulty situations, packets may be lost, duplicated, or delayed. This concept is also sometimes referred to as best-effort delivery.
The service is called connectionless because each packet is treated independently from all others. The packet itself contains all the information needed by the network in order to route it to the destination. There is no “connection” concept or connection state stored in the network. A sequence of packets sent from one computer to another may travel over different paths—so some packets may be delivered out of order, or some may be lost while others are delivered.
The lack of state makes IP networks very robust in cases of node failures. Because the network nodes do not store any state needed for end-to-end communication, in case an area of the network fails, other routers can pick up the traffic and reroute it to the destination through another area of the network. Of course, in such faulty situations, packets may be lost or delayed or delivered out of order, but it is assumed that the end systems are responsible for compensating for such situations. This may include the need for the end systems to control IP network traffic, including end-to-end flow control and error detection. The IP network itself is dumb, and this allows it to scale better and be more robust. As stated in [RFC 1958], “The network’s job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes.”
The version of the IP protocol that has been in use in the Internet for more than two decades is called IPv4, and is defined in [RFC 791]. It uses the popular 32-bit addresses (e.g., 169.254.31.25). A new version of the protocol, called IPv6, was developed in [RFC 2460]. IPv6 introduces a few new features and enlarges the address space (which was being exhausted) by defining 128-bit addresses. IPv6 has yet to find widespread adoption.
The Internet architectural principles and guidelines are described in [RFC 1958] and [RFC 3439]. From the above discussion, we have seen that the two key principles behind the Internet paradigm are:
The internetworking concept
The “dumb network” concept
Both of them are reflected in the following quote from [RFC 1958], “Architectural Principles of the Internet”: “The goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.”
End-to-end connectivity is a good thing, but what the end users are really interested in is applications (we, in this book, are also interested in a particular kind of Internet application: multimedia communication). So what does the Internet paradigm mean with regard to service creation?
First, application programs can be written on top of the IP layer and be independent of the underlying physical network. I can run the same program over a 100Base-T LAN (Local Area Network), over a dial-up connection, or over an ADSL (Asymmetric Digital Subscriber Line) access.[2] This is an important concept that is taken for granted (and therefore is somewhat underestimated), given that all existing operating systems have built-in IP support and offer drivers for very different physical networks, including at least Ethernet, dial-up, and ADSL physical networks.
Second, Internet applications work end to end. Application-level communication in the Internet is better achieved through the utilization of end-to-end protocols in such a way that the behavior of the underlying IP protocol is mirrored. This approach is better suited to deliver end-to-end functions. An example of such a function is security. Security can be better provided by using upper-layer end-to-end protocols. Information can be signed or encrypted by the endpoints, thus preventing the network from accessing the content.
Consequently, Internet applications are implemented at the network fringes. As an example, SIP is an application-layer end-to-end protocol. This end-to-end approach for designing communication applications provides great flexibility and reduces time to market because it reduces the dependency on the network.
Third, due to the way in which the Internet was conceived (as a service-agnostic network) at the beginning and how it has evolved over time, it so happens that access and service provision are decoupled in the Internet. Access providers and service providers do not necessarily have to be the same entity. As an example, one could obtain access through an ADSL provider and still get email service from Yahoo! This fact again fosters innovation and competitiveness because applications are not necessarily tied to the access provider.
Hence, the Internet can be considered a platform ideally suited for service creation.
All this discussion is particularly relevant in order to understand, in later chapters, the rationale behind SIP. This is defined as an end-to-end protocol, according to the Internet principles, in order to better deliver its end-to-end functions.
Notably, this implies quite a significant difference from other signaling protocols that are used today in circuit-switched networks, which are not end to end. In the traditional circuit-switched world, most of the intelligence is residing in the network, and access is tightly coupled to service provision. These aspects constrain the flexibility to deliver services in such networks. Much of the revolution currently taking place in the telecom industry has to do with abandoning the old signaling paradigms and embracing the Internet ideas that have proved to be the perfect ecosystem to boost application development.
Internet Protocol architecture can be best described using a layered model. Any layer in such architecture is said to provide services to the layer just on top of it while obtaining services from the layer just below it. This idea provides a powerful abstraction for the development of communication software. Layers are independent—they provide a very definite set of functions, and can be replaced without affecting the rest of the layers, as long as the interfaces between them are maintained. The topmost layer represents the end user’s view, whereas the layer at the bottom represents the hardware infrastructure that actually deals with the physical details of bits transmission.
The Internet layered model is typically referred to as the TCP/IP protocol suite, and is represented in Figure 3.4. The Internet layer sits on top of the data-link layers and physical layers, which are provided by the underlying network infrastructure (e.g., Ethernet, ATM, and so on). The transport layer uses the connectionless delivery service provided by the Internet layer, and offers specific transport services to the application layer. In the application layer, the end-to-end protocols that deliver the end-to-end functionality are implemented. Meanwhile, the applications that the end users “see” are implemented on top of the application layer, and use whatever application-layer protocol is needed to provide the requested functionality.
End-user services are therefore implemented on top of the application layer. For instance, an email application requires at least implementing a user interface through which the end user can submit emails and manage the emails that are in his or her mailbox (e.g., read, delete, and so on). A more complex email application might offer additional functionalities such as local folders and out-of-office announcements. Such an application would be built on top of the application layer, and would use the services of two protocols in such a layer: SMTP (Simple Mail Transfer Protocol, for submitting the emails) and IMAP4 (Internet Message Protocol version 4, for the management of the mailbox). Likewise, SMTP and IMAP4 are application-layer protocols that require the services of a transport-layer protocol such as TCP, which, in the same way, uses functionality provided by the IP protocol. This is shown Figure 3.5.
As already stated, this layer comprises the end-to-end protocols that are required to implement the end-to-end functions. Some well-known protocols are sitting in this layer—for example, HTTP, SMTP, POP3, IMAP4, TELNET, FTP, and DNS.
SIP is also an application-layer protocol, and works together with other application-level protocols such as RTP (Real-time Transport Protocol) or SDP (Session Description Protocol).
There are two widely used transport protocols in IP networks: TCP and UDP (User Datagram Protocol). In addition to these, another transport protocol, called SCTP (Stream Control Transmission Protocol), has been defined and is of special interest for signaling applications. We will now review the key functionality in these protocols.
UDP [RFC 768] provides little functionality on top of the unreliable connectionless datagram-delivery service that the IP layer provides. UDP merely provides a multiplexing/demultiplexing function on top of IP. Communication in IP networks occurs between application programs in the hosts. In the destination host, identified by an IP address, there might be many applications running, and it is crucial to identify which one is the ultimate destination for the datagram. UDP adds the ability to distinguish among multiple destinations within a given host through the utilization of the destination port field. It is said that UDP software at the destination demultiplexes the received packet and delivers it to the proper application. Likewise, the sending application also adds a source port parameter to which replies should be addressed. Figure 3.8 shows the way ports are used in UDP.
UDP also adds an optional checksum parameter that just provides a way to guarantee that data has arrived intact.
So, summarizing, the UDP transport layer does not ensure in any way that the datagrams have arrived at the destination. An application that uses UDP and needs this guarantee will have to implement the guarantee itself.
We will see in later sections that the service offered by UDP is extensively used in the context of real-time services.
TCP [RFC 793] provides reliable transport of data streams. In order to accomplish such a function, it uses a fundamental technique known as “positive acknowledgment with retransmission.” What this means is that the receiver host has to acknowledge the received packets. The sender host starts a timer after transmission of each packet, and, if a timeout occurs, retransmits the packet. At the receiver host, the TCP software delivers the packets to the destination application in sequence, exactly as they were sent, and also provides end-to-end flow control so as not to overload the receiver.
In order to provide these services, TCP uses the connection-oriented approach, which allows it to maintain the necessary context information in both sender and receiver host. An end-to-end TCP connection has to be established so that contexts can be initialized and data transmission can start. Similarly, once data transmission has finalized, the transport connection needs to be closed.
The TCP protocol also provides the multiplexing/de-multiplexing function and allows reaching a particular application in the destination host based on the destination port.
However, TCP takes the multiplexing concept further than UDP through the TCP connection concept. TCP can distinguish different flows for application processing even if they have the same destination port. The TCP server can de-multiplex different packets based on the connection in which they arrived, and can deliver them to the right application instance. A connection is identified by a pair of endpoints. An endpoint is defined as a pair of integers (host, port) where “host” is the host’s IP address, and the “port” is a TCP port on that host. Figure 3.9 shows how the connection concept is used in TCP.
SCTP is yet another transport protocol that, like TCP, provides a reliable transport service. It assures in-sequence, error-free transmission. SCTP is also connection oriented, but, unlike TCP, has some specific features that are specially suited to the transport of signaling information:
It is message oriented and supports framing of individual message boundaries (as opposed to TCP, which is byte oriented).
It allows for multiple streams in the same transport connection. Each stream has independent sequence delivery (as opposed to TCP, which assumes a single stream of data).
It supports multi-homing, or the ability for a single SCTP endpoint to support multiple IP addresses. This allows for greater survivability of the session in the presence of network failures.
SCTP is not yet as widespread as TCP or UDP. SCTP is specified in [RFC 2960], and a good introduction to it can be found in [RFC 3286].
SIP can use UDP, TCP, or SCTP in the transport layer. RTP, another important protocol for the delivery of multimedia services, always uses UDP as a transport.
Multimedia communication is enabled in the Internet by a myriad of IP-based application-level protocols that work in concert. Among these, two types of protocols play a predominant role in all the architecture:
The signaling protocols
The media transport protocols
These two types of protocols form the core of multimedia communication systems; no multimedia communication architecture can exist without them. In addition to the signaling and media protocols, other protocols provide optional functionality that complements, extends, or facilitates the core communication functions under specific circumstances. Examples of these protocols are those related to provision of QoS (Quality of Service), policy control, conferencing, NAT (Network Address Translator) traversal, accounting, and so forth.
Figure 3.10 depicts the protocol architecture comprising both the core and the supporting protocols.
Furthermore, as we said in the introduction, the protocols used in multimedia communication scenarios can work together with the existing Internet protocols in other service domains, and so help users to achieve a total communication experience.
The core signaling protocol for multimedia communication is the Session Initiation Protocol. SIP works in concert with the Session Description Protocol. SIP deals with the session-management issues; SDP is responsible for session description. The SDP messages are transported in the body of SIP messages. This split between session management and session description is a powerful concept because it allows the two functions to evolve separately. For instance, new media types can be easily incorporated into the Internet multimedia framework by defining new session descriptors and not impacting at all the SIP functionality. Likewise, new functionalities can be incorporated into SIP without the need to impact the way sessions are characterized.
SDP offers a generic mechanism to describe multimedia sessions. As such, it is not only used in communication scenarios. For instance, it is also used in the remit of streaming services, where it is conveyed by the RTSP (Real-time Streaming Protocol, [RFC 2326]) in order to describe the characteristics of streaming sessions.
SDP was also traditionally used together with the Session Announcement Protocol (SAP, [RFC 2974]) in the MBone (Multicast Backbone). SAP was used as a way to advertise the MBone multicast sessions among the potential participants. The multicast sessions were described by SDP content embedded in the SAP message.
SIP is detailed in Chapters 4, 6, and 7. SDP is examined in Chapter 9.
The core protocols used for media transport are:
Real-time Transport Protocol (RTP).
Message Session Relay Protocol (MSRP).
Transmission Control Protocol (TCP).
RTP is typically used to carry pure real-time media—such as voice or video—that are highly delay sensitive. It incorporates a mechanism to cope with the delay variations (jitter) introduced by the network. RTP is further described in Chapter 10.
MSRP is, at the time of this writing, still an Internet Draft (I-D). It is currently being used to carry quasi-real-time traffic such as Instant Messaging (IM) and online gaming. MSRP is further described in Chapter 10.
TCP can also be used directly as a media transport protocol. Typical usages are for image sharing or file transfer in the middle of a voice or video conversation.
There are other Internet protocols that can be used to enhance a multimedia communication system or that are needed to facilitate the operation of the core protocols. These complementary protocols encompass a number of aspects. Some examples are given next.
In order to implement QoS in loaded IP networks, the IETF (Internet Engineering Task Force) has defined extensions to the traditional best-effort Internet service, such as Integrated Services (IntServ) or Differentiated Services (DiffServ). The provision of QoS sometimes implies the need to reserve resources in the IP routers. This can be done using the Resource Reservation Protocol (RSVP).
Chapter 21 is dedicated to examining the mechanisms and protocols that enable Quality of Service.
In scenarios where there is a requirement to implement QoS mechanisms, there is sometimes the need to enforce policy-based admission-control decisions. In such cases, the entity responsible for taking the policy decisions has to communicate them to the entity responsible for enforcing them. In order to enable such communication, protocols such as COPS (Common Open Policy Service) can be used.
Policy-control aspects are discussed in Chapter 21.
In communication scenarios, service providers may want to charge for provision of the service and/or the utilization of the network resources. In those cases, it is crucial to have a mechanism that allows the service provider to request Authentication, Authorization, and Accounting from external servers. This can be done through the utilization of AAA protocols such as DIAMETER.
One of the most complex communication scenarios refers to the situation where many users participate in the same conversation (i.e., conference). In order to enable enhanced features in multiparty conversations, additional protocols are needed—for example, the Binary Floor Control Protocol (BFCP).
Conferencing is extensively discussed in Chapter 19.
Network Address Translators are frequently used in IP networks in order to separate private and public addressing realms. SIP and RTP are not NAT-friendly protocols, so their operation is severely disrupted in scenarios involving NAT devices.
The NAT traversal issue is one of the most critical aspects that SIP and RTP are faced with in real deployments. Many new procedures, mechanisms, and protocols have been defined to cope with that problem. One of the most relevant supporting protocols in this remit is the Simple Traversal Utilities for NAT (STUN).
NAT traversal is covered extensively in Chapter 22.
There are many other Internet protocols that are focused on delivering other types of services such as infotainment, streaming, or offline communications. Examples of such protocols are:
HTTP (Hypertext Transfer Protocol): Defines the rules for transferring and conveying information on the web.
SMTP (Simple Mail Transfer Protocol): Is used for email submission across the Internet.
IMAP4 (Internet Message Access Protocol): Allows clients to access and manage their email box.
RTSP (Real-time Streaming Protocol): Allows a client to remotely control a streaming server. It offers VCR-like commands such as “play” or “rewind.”
SIP has been designed in such a way that it can be smoothly integrated with Internet protocols used in other service domains. For instance, SIP addressing follows the URI (Universal Resource Identifier) format to address SIP resources. That is the same format that is used on the web and by email systems. This characteristic enables some interesting combined features (e.g., John might try to initiate a media session with Alice and, because Alice is not available, be redirected to her web page).
In this chapter, we have reviewed the TCP/IP basics and have presented the big picture for multimedia communications. In the next chapter, we will continue looking at the fundamentals of multimedia communications and will introduce SIP.
[1] Throughout this book, the term “internet” (with the first letter in lowercase) is used to refer to a collection of interconnected networks using the IP protocol. On the other hand, the term “Internet” (with the first letter in uppercase) refers to the well-known network, which represents a global instantiation of the internetworking (or internet) concept.
[2] Obviously, different underlying physical networks may allow for different bandwidths, and this may have an effect on the user experience. However, from the functional perspective, the application does not need to bother about the physical network.