7
Wireless, Mobility, and IMS
The mobility features of SIP have been discussed in earlier chapters. In this chapter, those aspects will be explored further. The Third Generation Partnership Project (3GPP) [1] has adopted SIP as their call signaling protocol in the Intelligent Multimedia Core Subsystem (IMS). Since then, a number of extensions and usage documents have been authored describing 3GPP’s planned use of SIP; these will be discussed in this chapter. The future direction of wireless SIP will be discussed in Section 7.5.
7.1 IP Mobility
There are a number of different types of mobility that will be discussed in this chapter, including terminal mobility, personal mobility, and service mobility [2]. Terminal mobility is the ability of an end device to maintain its connection to the Internet as it moves around and possibly changes its point of connection. Personal mobility is the ability to have a constant address (identifier) across a number of devices. Finally, service mobility is the ability of a user to keep the same services when mobile.
Terminal mobility can be addressed by Mobile IP [3], which has been standardized in the IETF. It allows a terminal to keep the same IP address when roaming as it does in its home network. While roaming, the terminal is reachable by a “care of” address, which is registered in the home network. Packets destined for the roaming terminal are received in the home network, then tunneled to the terminal at the “care of” address, as shown in Figure 7.1. Mobile IP has the advantage of hiding the mobile nature of the terminal from layer 3 protocols and above. These protocols can then be used without any modification.
For example, a TCP connection can be maintained since the terminal appears to have a constant IP address. However, Mobile IP has the disadvantage
177
178 |
SIP: Understanding the Session Initiation Protocol |
Figure 7.1 Triangular routing of IP packets in Mobile IP.
that incoming packets are not routed directly, and as a result, most efficiently. This results in increased packet latency. While this is not a problem for nonrealtime services such as Web browsing or e-mail, real-time media transport has critical requirements on packet latency. A solution that has been proposed [2] is based on the fact that a protocol such as SIP already has mobility support built in. In addition, SIP is capable of handling some of the terminal mobility aspects at the application layer. This can result in more efficient RTP packet routing and better efficiency (as the additional overhead of IP packet encapsulation required by Mobile IP are avoided).
HIP (Host Identity Protocol) mobility, described in Section 15.5 is another way for mobility to be supported. HIP does not use the triangular routing of Figure 7.1.
The result is that mobile SIP devices are utilizing two different architectures. One is based on the use of Mobile IP and the other utilizes the built-in mobility support in SIP. The next sections will discuss these two approaches. SIP is ideally suited to provide both personal and service mobility.
7.2 SIP Mobility
Personal mobility is the ability to have a constant identifier across a number of devices. A sip or sips URI has exactly this property and is fundamentally supported by SIP. SIP can also support service mobility (the ability of a user to keep the same services when mobile) although some conventions and extensions have been proposed that provide this in certain architectures.
Basic personal mobility is supported by SIP using the REGISTER method, which allows a mobile device to change its IP address and point of connection to the Internet and still be able to receive incoming calls. As discussed in Chapters 2 and 4, registration in SIP temporarily binds a user’s AOR (Address of Record)
Wireless, Mobility, and IMS |
179 |
URI with a Contact URI of a particular device. As a device’s IP address changes, registration allows this information to be automatically updated in the SIP network. An end device can also move between service providers using multiple layers of registrations, in which a registration is actually performed with a Contact as an address of record with another service provider. For example, consider the UA in Figure 7.2, which has temporarily acquired a new SIP URI with a new service provider. (The reasons for doing so could include security, NAT/firewall traversal, or local policy.) The UA then performs a double registration as shown in Figure 7.2. The first registration is with the new service provider, which binds the Contact URI of the device with the new service provider’s AOR URI. The second REGISTER request is routed back to the original service provider and provides the new service provider’s AOR as the Contact URI. As shown later in the call flow, when a request comes in to the original service provider’s network the INVITE is redirected to the new service provider who then routes the call to the user.
Figure 7.2 Precall mobility using SIP REGISTER.
180 |
SIP: Understanding the Session Initiation Protocol |
For the first registration message containing the device URI would be:
REGISTER sip:registrar.capetown.org SIP/2.0
Via: SIP/2.0/TLS 128.5.2.1:5060;branch=z9hG4bK382112 Max-Forwards: 70
To: Nathaniel Bowditch <sip:bowditch321@capetown.org> From: Nathaniel Bowditch <sip:bowditch321@capetown.org>
;tag=887865
Call-ID: 54-34-19-87-34-ar-gr CSeq: 3 REGISTER
Contact: <sip:nat@128.5.2.1> Content-Length: 0
and the second registration message with the roaming URI would be:
REGISTER sip:registrar.salem.ma.us SIP/2.0
Via: SIP/2.0/TLS 128.5.2.1:5060;branch=z9hG4bK1834 Max-Forwards: 70
To: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us> From: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us>
;tag=344231
Call-ID: 152-45-N-32-23-W3-45-43-12 CSeq: 6421 REGISTER
Contact: <sip:bowditch321@capetown.org> Content-Length: 0
The first INVITE that is depicted in Figure 7.2 would be sent to
sip:n.bowditch@salem.ma.us; the second INVITE would be sent to
sip:bowditch321@capetown.org, which would be forwarded to sip:nat@128.5.2.1.
It reaches Bowditch and allows the session to be established. Both registrations would need to be periodically refreshed.
A disadvantage of this approach is that SIP does not currently have a means to obtain a local URI. This would have to be done using a non-SIP method such as a Web page signup, which would be coupled with the proper authentication, authorization, and accounting mechanisms.
An optimization of this is for the local registrar to forward the registration information on the roaming UA back to the home registrar. This has been proposed in the IETF [4] but has yet to be adopted or standardized. No changes to SIP messages are required, just a convention adopted by registrars to recognize a roaming registration and take the appropriate action. It is possible that these conventions may become standardized if the authentication and accounting systems needed to properly process such registrations are standardized in the future.
During a session, a mobile device may also change IP address as it switches between one wireless network and another (the Mobile IP protocol is not as- sumed—it will be discussed in the next section). Basic SIP supports this scenario as well, since a re-INVITE in a dialog can be used to update the Contact URI and change media information in the SDP. This is shown in the call flow of Figure 7.3. Here, Bowditch detects a new wireless network, uses DHCP to acquire a
|
|
|
|
Wireless, Mobility, and IMS |
181 |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 7.3 Midcall mobility using a re-INVITE.
new IP address, then performs a re-INVITE to make the signaling and media flow to the new IP address. If the UA momentarily is able to receive media from both networks, the interruption can be almost negligible. If this is not the case, a few media packets may be lost as the media catches up with the signaling, resulting in a slight interruption to the call. The re-INVITE would appear as follows:
INVITE sip:laplace@client.mathematica.org SIP/2.0 Via: SIP/2.0/UDP 65.32.21.2:5060;branch=z9hG4bK34213 Max-Forwards: 70
To: Marquis de Laplace <sip:laplace@mathematica.org> ;tag=90210
From: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us> ;tag=4552345
Call-ID: 413830e4leoi34ed4223123343ed21 CSeq: 5 INVITE
Contact: <sip:nat@65.43.21.2> Content-Type: application/sdp Content-Length: 143
v=0
o=bowditch 2590844326 2590944533 IN IP4 65.32.21.2 s=Bearing
c=IN IP4 65.32.21.2 t=0 0
m=audio 32852 RTP/AVP 96 a=rtpmap:96 iLBC/8000
182 |
SIP: Understanding the Session Initiation Protocol |
This contains Bowditch’s new IP address in the Via and Contact header fields and SDP media information.
Note that both of the mobility scenarios in Figures 7.2 and 7.3 do not require cooperation between the two wireless networks. As such, this is a useful scenario in which a UA can hand off a call between, for example, a commercial wireless network and a home or office 802.11 wireless network.
For midcall mobility in which the actual route set (set of SIP proxies that the SIP messages must traverse) must change, a re-INVITE cannot be used. For example, if a proxy is necessary for NAT/firewall traversal, then more than just the Contact URI must be changed—a new dialog must be created. The solution to this is to send a new INVITE (which creates a new dialog and a new route set including the new set of proxies) with a Replaces header (Section 6.2.2.4), which identifies the existing session. The call flow is shown in Figure 7.4. It is similar to that in Figure 7.3 except that a BYE is automatically generated to terminate the existing dialog when the INVITE with the Replaces is accepted. In this scenario, the existing dialog between Bowditch and Laplace includes the old visited proxy
Figure 7.4 Midcall mobility using INVITE with Replaces.
Wireless, Mobility, and IMS |
183 |
server (the proxy Record-Routed during the initial INVITE). The new dialog using the new wireless network requires the inclusion of the new visited proxy server. As a result, an INVITE with Replaces is sent by Bowditch, which creates a new dialog that includes the new visited proxy server (which Record-Routes) but not the old visited proxy server. When Laplace accepts the INVITE, a BYE is automatically sent to terminate the old dialog that routes through the old visited proxy server that is now no longer involved in the session. The resulting media session is established using Bowditch’s new IP address from the SDP in the INVITE.
Services in SIP can be provided in either proxies or in UAs. If the service is resident in the UA, then there are no service mobility problems as the user moves around. However, combining service mobility and personal mobility can be challenging unless each of the user’s devices are identically configured with the same services. Also, end-point resident services are only available when the end point is connected to the Internet. A terminating service such as a call forwarding service implemented in an end point will fail if the end point has temporarily lost its Internet connection. For this and other reasons, some services are implemented in the network using SIP proxy servers. For these services, service mobility for a UA means that the same set of proxies are used to route incoming and outgoing requests when mobile.
Due to the nature of the Internet, in general there is no reason why a UA cannot use the same proxies when connected to the Internet at a different point. That is, a UA that is normally in the United States and is configured to use a set of proxies in the United States can still use those proxies when roaming in Europe, for example. Perhaps the SIP hops will have a slightly higher latency due to more router hops and a call setup request may take a second or two longer to complete. However, this has no impact on the quality of the media session as the media always flows directly between the two UAs and does not traverse the SIP proxy servers. As a result, SIP can easily support service mobility over the Internet.
However, there are some cases in which this service mobility approach will not work. For example, if a local proxy server must be traversed in order to facilitate firewall or NAT traversal, or for some other security reason, then a UA may have to use a different first hop proxy when roaming. In this case, service mobility is still possible provided that:
1.The roaming UA is able to discover the necessary local proxy.
2.Both incoming and outgoing requests are routed through the home proxy in addition to any local proxies.
The first requirement is met by the DHCP extension to SIP [5], which allows a UA to learn of a local proxy server at the same time it learns its IP address and other IP configuration information. The second requirement is met using a
184 |
SIP: Understanding the Session Initiation Protocol |
preloaded Route header field in requests. Normally a Route header is inserted in a request when a proxy requests it using a Record-Route header field. However, it is possible for a configured UA to include a Route header field. If the Route header contains the URI of the home proxy, the request will be routed to the home proxy after the local proxies have been traversed, meeting the requirement for outgoing requests. For incoming requests, the double registration technique will result in both the home and local proxies being traversed by incoming requests. This will result in a call flow similar to Figure 7.2 but with the home proxy server forwarding the INVITE instead of redirecting.
These SIP mobility capabilities are well suited to use over a wireless network such as 802.11 in a home, office, or public space. As roaming agreements allow such wireless “hotspots” to be linked in metropolitan areas, this will provide a wireless service. However, commercial wireless providers plan a specific purpose wireless telephony network using SIP. For some of their business and service requirements, SIP extensions have been developed, which will be discussed in this chapter.
Wireless SIP clients may also make use of voice codecs such as the iLBC [6], which is highly tolerant to packet loss that may be experienced in a heavily loaded 802.11 network.
7.3 IMS and SIP
The 3GPP architecture uses SIP in the IP Multimedia Subsystem (IMS). The main elements of the IMS architecture are listed in Table 7.1. An excellent reference text for IMS is [7].
|
Table 7.1 |
|
IMS Elements |
Element |
Name |
|
|
P-CSCF |
Proxy call session control function |
I-CSCF |
Interrogating call session control function |
S-CSCF |
Serving call session control function |
UE |
User equipment |
MGCF |
Media gateway control function |
MGW |
Media gateway |
AS |
Application server |
MRFC |
Media resource function controller |
BGCF |
Breakout gateway control function |
HSS |
Home subscriber server |
Wireless, Mobility, and IMS |
185 |
The 3GPP architecture relies on Mobile IP instead of the mobility aspects of SIP described in the previous section. The reasons for doing so are primarily business related rather then technical.
Another requirement of mobility systems is a keep alive signal, which allows end points and proxies to know that a UA still has network connectivity. On an end point to end point basis, this can be done using RTCP (see Section 12.2) reports sent periodically, even when the media is on hold or silence suppression is taking place. However, proxies do not have access to these direct end-to-end reports. Instead, the session timer extension [8] and re-INVITEs can be used for this purpose, or the SIP outbound extension described in Section 10.11.13.
Call Signaling Control Functions or CSCF are SIP proxies that also sometimes behave as a B2BUA under certain circumstances. For example, if a Proxy or P-CSCF looses the radio link to the user equipment (UE) that contains the SIP UA, it can send a BYE on behalf of the UE to tear down the session. The motivation for doing this is for sessions that have a per-minute billing charge, which the out-of-contact UE would otherwise have to pay for but not have the ability to disconnect. To save bandwidth on the wireless connection, a P-CSCF
removes Route, Record-Route, Path, Via, Service-Route and other header
fields and reinserts them in the opposite direction. To prevent high bandwidth codecs from being used by a UE, a P-CSCF may edit the list of codecs in an SDP offer or answer, preventing the codec from being used. A P-CSCF may change the To and From headers to provide privacy, which is a B2BUA function.
The proxy CSCF provides emergency service, triggers for local services, and normalizes telephone numbers for the rest of the network. The P-CSCF is used as the default outbound proxy server for a UE outside its home network. The Interrogating CSCF queries the HSS to determine the proper service CSCF. The I-CSCF also can do hiding of the S-CSCF network by removing or encrypting Via header fields. The serving CSCF provides the services for the subscriber. It identifies the user’s service profile and privileges.
The 3GPP uses IPv6 addresses due to the number of mobile subscribers envisioned and the fact that with Mobile IP, each device may use more than one IP address at a time. SIP RFC 3261 includes full support for IPv6 addresses, and an extension to SDP [9] adds IPv6 support to SDP.
The 3GPP also uses signaling compression [10] to compress SIP messages transmitted over a wireless link. This is primarily done to minimize latency rather than for bandwidth savings. The use of signaling compression with SIP is described in [11], which defines a parameter comp=sigcomp that can be used in Via header fields and as a URI parameter that can be used, for example, in a Contact header field. IMS also makes heavy use of header fields such as ServiceRoute [13] and Path [14].
The 3GPP uses the adaptive multirate (AMR) [12] codec for the audio encoding.