The economics of sending voice over packet networks, coupled with the technology that ensures acceptable quality of service, is causing the con- vergence of data and voice. It is unclear, though, what VoIP management architecture will best meet user needs, what services will be most success- ful, and at what location in the network these services should reside. This chapter links the value of VoIP-based services to the management structure of the service and the market uncertainty. It illustrates how high market uncertainty increases the value of the flexibility of SIP, because it gives users choice in management structure.
Historically (as discussed in Chapter 3), the end-2-end principle has been important in designing Internet protocols and the applications that use them. One proposed architecture for VoIP is the SIP [1] protocol, which is supported by the IETF. It promotes user innovation because it allows end-2-end operation. It also offers the advantage of central control via a proxy server. Another architecture for providing VoIP is megaco/H.248 [2], which was developed by the IETF and ITU. Megaco/H.248 is a centralized architecture similar to the current PSTN and does not allow true end-2-end use. The ideas in this book illustrate why SIP has a higher expected value when market uncertainty exists because it offers the advantages of end-2- end services when innovation is important, along with the advantages of centralized control and management when efficiency is paramount, at the user’s choice.
VoIP means different things to different people. It might describe how traditional dumb telephones talk to a megaco gateway in order to convert the analog voice into IP packets, or it might explain how smart SIP phones establish connections to each other, or it might define the protocol for IP phones to become a Media Gateway controlled by a Media Gateway con- troller, as described in RFC3054. This chapter focuses on the market for new IP-based voice infrastructure. The question addressed in this chapter is the estimation of value between different architectures for a new IP-voice system. Will forced centralized control, along with its implied efficiency and the robustness of the megaco/H.248 architecture [3], prove more valu- able than the flexibility inherent with the SIP model? This chapter dis- cusses the potential value of the market for new IP-voice systems.
The question of where to place services in IP telephone networks is com- plex [4] and depends on many variables, including the capabilities of the end systems, the amount of interaction with the end user, and the architec- ture of the network infrastructure. Networks with dumb devices, such as the PSTN, force services to be implemented within the network because of the limited ability of the end devices. Networks having smart end systems 176 Chapter 10
allow more choice in where to locate a service, but other factors affect the location of services in these networks. Services dealing with how to reroute a call to a device that is not working require network intervention because smart devices not connected to the network can’t participate in any service offering. Sometimes, the user of the end device is needed to help decide what to do — for example, transferring a call. Assistance from the end device might be helpful to the user, for example, when user interaction is desirable such as handling a new incoming call when the user is already busy with at least one other call. In this case, the user may wish to know who the incoming caller is, and maybe the topic of the call, and decide if the new call is more important than any of the current ones — involvement of the end device makes this much easer. Finally, services such as confer- ence calls may or may not require network intervention. Flexibility in where to place services in IP telephone networks is valuable because it pro- motes innovation of services that meet user and service provider needs.
This chapter focuses on voice service over the Internet, which is a net- work allowing end-2-end services. Voice services built using the Internet can have centralized or distributed architecture. Conference calling imple- mented with SIP is a good example of such a service. It can be imple- mented with a distributed structure without the network providing any services — each end device manages the different audio streams. Alterna- tively, it can be implemented within the network using a centralized net- work server to mix the many audio streams [4]. The end-2-end implementation is more flexible, but it is not as scalable as the more cen- tralized architecture.
This book’s theory will highlight the intrinsic value of SIP because it allows users and small service providers to experiment with new services.
SIP users can bypass any centralized management structure and create new services without anybody knowing about these services. I illustrate how SIP allows the best of both worlds: centralized management via proxy SIP servers and end-2-end services when they make sense. This is not the case with megaco/H.248, which forces centralized control with all ser- vices. I discuss how megaco/H.248 will coexist with SIP and how, in the long run, megaco/H.248 might disappear because SIP is able to provide the advantages of megaco’s centralized structure while allowing the flexi- bility to locate services either within the network or at its edge.
SIP
SIP is designed for setting up multimedia connections between consenting parties. One of the many uses of SIP is to provide voice services over the Inter- net. SIP is similar to HTTP, having text headers that people can understand.
Voice-over IP: SIP and Megaco 177
It is a flexible protocol because it allows true end-2-end applications as well as applications requiring centralized control via the use of SIP proxies.
When SIP is used end-2-end, users can experiment by extending the proto- col. Many wireless phone providers, such as Ericsson or Nortel, are adopt- ing SIP because they are beginning to understand that service providers other than traditional phone companies will be providing some (maybe most) of the future applications for wireless phones and other wireless devices.
SIP is used in conjunction with other protocols, such as Session Descrip- tion Protocol (SDP) and Real Time Protocol (RTP), allowing multimedia sessions to be initiated, carried out, and then terminated. SDP is the proto- col used to describe the characteristics of the connection, such as the proto- col used for data transfer (RTP/UDP), the type of media (voice), and the format of the media (that is, the voice encoding). It is needed so that both sides can exchange information about what the upcoming data stream will look like. RTP is the application protocol enabling data transport — it is unreliable, but it has sequence numbers so packets are delivered to appli- cations in the order sent. Together with these other application protocols, SIP allows building Voice over IP applications on the Internet.
SIP is not a complex protocol. It consists of commands (messages) with headers that describe attributes of the command. To initiate a call in SIP, the INVITE message is sent along with a set of headers containing information required to establish the call. The example that follows is the end-2-end use of SIP — Alice is calling Bob directly without the help of an SIP proxy server. Here is an example of what the INVITE command (taken from RFC2543.bis09) might look like if Alice at Harvard is calling Bob at BU:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pcalice.harvard.edu;branch=z9hG4bK776asdhds Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp Content-Length: 142
178 Chapter 10
The first line of this SIP message contains the INVITE message. This command is directly asking Bob at Boston University ([email protected]) if he would like to talk. The protocol used is SIP, version 2.0. Following this method is the minimum set of headers describing the required information for Bob to talk with Alice. These headers are described next:
Via. This is the address (pcalice.Harvard.edu) where Alice is expect- ing to receive responses to this request. It also has a branch parame- ter to identify this transaction.
Max-Forwards. This is the maximum number of hops this request can take.
To. This indicates where the SIP message is going — directly to Bob at Boston University ([email protected]).
From. This is the address of the calling party — Alice in this case ([email protected]).
Call-ID. This contains a globally unique identifier for this call.
Cseq. This contains a sequence number for the particular method specified.
Contact. This is the direct route to Alice so that Bob can directly com- municate with her. In this case, it is the same as the “From header”
because a proxy is not being used.
Content-Type. This describes the content type of the message and comes from the MIME world; in this case, the message is a session description using the Session Description Protocol (SDP).
Content Length. This is the length of the entire message with headers.
All the headers apply to the method specified in the first line of the SIP message.
In this particular end-2-end case, the message is going from Alice’s sys- tem at Harvard to Bob’s system at Boston University, without any SIP prox- ies involved in the transaction. This simple end-2-end use of SIP is illustrated in Figure 10.1. This end-2-end architecture illustrates how users directly communicate with each other without any server within the net- work knowing this is taking place. Next, each step of this simplified exam- ple is explained:
Voice-over IP: SIP and Megaco 179
Figure 10.1 End-2-end SIP architecture.
1. Alice sends the INVITE message to Bob, asking him if he wishes to join her in a conversation.
2. Bob receives this message from Alice and responds with the OK message, indicating to Alice that he is glad to speak with her.
3. Alice receives Bob’s OK message and sends him the ACK message to indicate the establishment of the session between them.
This is a good example of a pure end-2-end application because nothing within the network is aware of the application Alice or Bob is running. If Alice and Bob choose to experiment, they can because the network will be unaware of what they are doing; they are the only ones to be affected by their actions. For example, Bob and Alice can agree to experiment with new messages and/or new headers that will enable a service that they want to implement. With SIP, they can experiment between themselves with end-2- end SIP without modifying any servers within the network. Bob and Alice can change the SIP however they want with this distributed mode of oper- ation because only they are aware of what they are doing.
SIP provides a more centralized management architecture by allowing end users to communicate though an SIP proxy. This proxy is responsible for establishing a connection between the two end users. The following is an example of an INVITE request where both end users communicate via an SIP proxy. Bob’s proxy is sip.bu.edu, and Alice’s proxy is sip.harvard.edu:
INVITE sip:[email protected]SIP/2.0
Via: SIP/2.0/UDP pcalice.harvard.edu;branch=z9hG4bK776asdhds Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
SIP Device Alice
(3)ACK (2)OK (1)INVITE Bob
(4)RTP Connection
SIP Device Bob 180 Chapter 10
Call-ID: [email protected] CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp Content-Length: 142
This example illustrates the similarities with both end-2-end and proxy models. The differences are highlighted in bold. The INVITE method has Bob’s proxy, not his direct address. The “To” header also has his proxy instead of his direct address. Finally, the “From” header has Alice’s proxy address, instead of her direct address. These are the only differences.
This more centralized structure for SIP is illustrated in Figure 10.2, where SIP end users do not directly establish sessions, but instead communicate with an SIP proxy. This SIP proxy is a network server, making this structure not end-2-end. Here is a simplified example of Alice asking Bob to talk when they are both communicating via different SIP proxy servers:
1. Alice sends the INVITE message through her proxy server (sip.
harvard.edu), asking Bob if he wants to talk to her.
2. Alice’s proxy server forwards the INVITE message to Bob’s proxy server (sip.bu.edu).
3. Bob’s proxy server forwards the INVITE message to him — this is the first time he is aware that Alice is asking to establish a connec- tion to him.
4. Bob sends the OK message back through his SIP proxy server.
5. Bob’s proxy server forwards the OK message to Alice’s proxy server.
6. Alice’s proxy server sends this OK back.
7. Alice sends the ACK message to Bob directly, indicating session establishment. This is the first time that Alice has directly communi- cated with Bob.
One important architectural question arising from the preceding exam- ple is how much state an SIP proxy server keeps about each connection it sets up. SIP allows proxies that are stateless or stateful. A stateless proxy retains no knowledge of what the end users are doing; a stateful proxy keeps information about what all end users are doing. For my argument, the statefulness of the server does not matter. The fact that the proxy exists and must understand the session setup between the two communicating parties is the important factor that indicates a more centralized style of management structure.
Voice-over IP: SIP and Megaco 181
Figure 10.2 Centralized SIP architecture.
One important factor is that both of the preceding examples are identical as far as the end devices are concerned. As Figures 10.1 and 10.2 illustrate, the messages that Alice and Bob see are the same with or without the SIP proxy between the end users. The only differences are in the headers that indicate name/address information; the interchange of messages is the same in both end-2-end and proxy mode. This is important because it allows easy migration of services from the network’s edge into its core.
SIP is a nice solution to VoIP, but it is not the model of choice for tradi- tional centralized telephone service providers. Some traditional telephone companies believe in customer lock-in and worry that with SIP it is easy for users to switch service providers or do without a service provider alto- gether by adopting end-2-end SIP. By pointing to a different SIP proxy or directly connecting to another SIP user, SIP customers will have choices in how they use the SIP services. Some traditional carriers are afraid that with SIP, users will not choose them as their primary service provider.
Figures 10.1 and 10.2 show why SIP is the best of both worlds: It offers the advantages of end-2-end applications, or the advantages of centralized management using proxy servers, or a combination of the two. On one hand, SIP allows true end-2-end use, as Figure 10.1 depicts, which promotes
SIP Device Alice
(7)ACK
(8)RTP Connection
SIP Device Bob Alice's SIP
Proxy
(2)INVITE Bob
(1)INVITE Bob
(3)INVITE Bob (5)OK
(6)OK
(4)OK
Bob's SIP Proxy 182 Chapter 10
innovation; on the other hand, SIP allows the business and technical advantages of centralized control by funneling the connection requests to an SIP proxy, as illustrated in Figure 10.2. SIP seems to give both users and administrators what they want because it allows experimentation when needed and then allows services to be placed where they fit best, and can most efficiently be deployed for many users, either inside the network, at the end device, or a combination of both.