Chapter 9 Wireless SIP and 3GPP
Translation of: Visit to address: Qinhuangdao Yanshan University
In the previous chapter, the mobile characteristics of the SIP protocol have been introduced, and these features are further discussed in this chapter. In 2000, the 3GPP organization used SIP as a signaling protocol in its released IMS5. Since then, 3GPP organization [1] released a series of documents, which describe the extension and application of the SIP protocol they plan to use. This chapter will focus on these extensions and applications. In this chapter, the development direction of wireless SIP will be discussed.
9.1 IP mobility
This section will introduce different types of mobile forms, including: terminal movement, personal (user) movement, service mobile [2]. Terminal movement means that the device maintains the ability to access the Internet when the terminal device moves and may change the access point; the personal (user) movement refers to the ability to use a fixed address (identifier) across a series of devices; service movement Sexually refers to the ability to get the same service when the user moves.
Terminal mobility can be positioned by mobile IP, and the IETF organization has implemented standardization of mobile IP. The mobile IP allows a terminal device to use the same IP address in the parent domain when roaming, and the regulatory address is registered in its parent domain. To reach the packet of the roaming terminal first reach the master domain, then pass the regulatory address to the terminal device, the entire process is shown in Figure 9.1. The advantage of moving IP is to hide the movement of the third and overline, which can be applied without expanding.
Figure 9.1 Triangle Routing of IP Package in Mobile IP
Below is an example, a terminal device using a fixed IP address is easily capable of maintaining a TCP connection, however mobile IP has a data packet to be received to be routed to the terminal, which results in an extension of the packets of the packet. There is no much impact on the non-real-time business of web browsing and E-mail. However, the transmission of real-time media has a strict requirement for packet waiting times. Some protocols that are proposed, such as SIP protocols, have been built into mobile IP in practical applications. Moreover, the SIP protocol has the ability to move some aspects of the application layer processing terminal, which enhances the efficiency of RTP packet routing and transmission (using SIP to avoid replenocating by moving IP).
Therefore, the mobile SIP device can adopt two different structures: one is based on the application of mobile IP, and the other is a SIP that supports mobility. The next chapter will introduce these two different solutions. As we will discuss, the SIP protocol can solve personal (users) and service mobility.
9.2 SIP mobility
Personal (user) movement is the ability to use a fixed identifier across a series of devices. The SIP protocol uses the URI (Uniform Resource Identifier), which itself has this capability. SIP protocol also supports service movement, ×××××× ※
The SIP protocol gains basic personal (user) mobile capabilities through the Register method. By registering methods, mobile devices changing its IP address and Internet access point, still accepting calls. In Chapter 2 and 4, the implementation method is introduced, and the registration mechanism of the SIP protocol is temporarily bound to a specific device. It is temporarily bound to its AOR URI and Contact Uri. When the IP address of the device changes, the registration mechanism allows the information to be automatically updated in the SIP network. A terminal device can roam in the network that provides multi-layer registration services. During mobile, registration is done by another network with the same functionality to see the recording address as a Contact address. As shown in Figure 9.2, the user agent temporarily obtains a temporary SIP URI through another service providing network (which takes into account the safety, local policies, firewall penetration), can be seen from Figure 9.2, the user agent completed two Submit, the first registration is completed through the new service providing network, which is bound to the AOR URI provided in the Contact URI and the new network. The second registration is registered again in the parent domain, providing the AOR URI provided by the new network as the Contact URI to the parent domain. A call creation process is given in the second half of the figure. When a user from the mother domain is requested, the INVITE request is redirected to the new web server and then reaches the called user agent. Figure 9.2 Mobility before the call is registered via SIP
The first registration of the SIP message is as follows:
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
From: nathaniel bowditch
TAG = 887865
Call-ID: 54-34-19-87-34-AR-GR
CSEQ: 3 register
Contact:
Content-Length: 0
The SIP message registered in the second time is as follows:
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
From: Nathaniel Bowditch
CALL-ID: 152-45-N-32-23-W3-45-43-12
CSEQ: 6421 Register
Contact:
Content-Length: 0
Figure 9.2 First INVITE Return: SIP: N.Bowditch@salem.ma.us; Second INVITE RETET: SIP: Bowditch321@capetown.org; Third Invite Request Sencture: SIP: Nat@128.5.2.1, the third INVITE request reaches Bowdith and establishes a session. Two registration processes need to be periodically updated.
The disadvantage of this method is that the SIP protocol itself has not provided a method of obtaining a local URI. Local URI can be obtained by some non-SIP protocol methods, such as web page registration. Use web registration will be combined with appropriate authentication, authorization, and billing mechanisms. The best way to register locally is to use roaming user agents to update the parent domain registration service information. IETF organization [4] This method has been proposed, but it has not been standardized. This method requires not to change the SIP message form, just generating a registrar to identify roaming registration information and respond to information. In the future, after the appropriate certification and billing process are as standardized as the same as the same standardization, roaming registration will also become possible.
During a session, the mobile terminal may also enter another wireless network from a wireless network, thereby changing its IP address (mobile IP protocol is not suitable for this situation). In this case, the basic SIP protocol can be solved well, and a RE-INVITE message can update the Contact Uri and update media information in the portable SDP message body, as shown in Figure 9.3. Bowditch detects a new wireless network, get a new IP address through the DHCP protocol, send a Re-INVITE message, the media stream transfers to the new IP address, if at some point, the user agent receives media from two networks. Information, this interference is usually ignored. If you can't ignore, some RTP data packets will be lost, and the session may temporarily interrupt.
9.3 Applying Re-Invire during the mobile session
The Re-INVITE message is 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
From: Nathaniel Bowditch
Call-ID: 413830E4leoi34ed4223123343ed21
CSEQ: 5 INVITE
Contact:
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 0
a = rtpmap: 0 pcmu / 8000
Bowditch's new IP address is included in the VIA, in the Contact header, and the SDP media information message body.
The cases shown in Figures 9.2, 9.3 do not take into account the synergy between two different types of wireless networks, for example, the user agent enters the 802.11 network from a commercial wireless network to the office or family, this situation occur frequently.
In this case, the actual routing entity (SIP message must pass through the SIP message) changes, and a simple RE-INVITE message cannot be completed. For example, when there is a change in the network, a firewall is needed, not just a Contact Uri, you must re-establish a session. The solution is to send a new INVITE message with the Replace header, create a new session, the routing entity in the new session includes a new proxy server (see 6.2.23), the new session can identify the existing session. The specific flow is shown in Figure 9.4. Similar to the flow shown in Figure 9.3, different, the flow shown in Figure 9.4 is only after accepting an INVITE message containing ReplaceS information, the terminal automatically generates a BYE message to Figure 9.4 Invite with Replaces in the mobile call
Survey of existing dialogue. In this case, BowDitch and Laplace's existing dialogues contain proxy servers accessed in the past (the server starts to record routing in the session), and new sessions use new wireless networks including the current proxy server. Bowditch Send an INVITE message containing ReplaceS information, creating a proxy server that contains currently access (recording routing) instead of proxy servers that have been accessed, when Laplace receives INVITE, automatically send a BYE message to abort the last conversation, bye the past The server is sent by the proxy server, and the current dialog is not involved. The newly created media session uses new IP addresses carried by SDP in the INVITE message.
The service in the SIP protocol can be provided by the proxy server or can be provided by the user agent. For users provided by the user agent, there is no problem with service mobility. However, unless all user devices provide the same services, service movements and personal movements are affected, and the service terminal only functions when the terminal device is connected to the Internet. Similar to the session update service If the user agent is provided, once the terminal device is temporarily connected, the termination service will fail. Due to such a reason, some specific services are completed by the SIP proxy server. For these services, the service movement of a user agent means that the same proxy entity is used to route calls and responses when roaming.
In general, considering the nature of the Internet, when the user agent uses a different Internet access point, there is no reason not to allow the same proxy server. That is, a US user agent usually uses a series of fixed proxy servers that they can still use these servers when it roams to Europe. For example, since multiple routers, SIP packets may have to experience long wait period, and the establishment of sessions may be used to use, two seconds. However, this does not affect the quality of the media session because the media stream is done between the two user agents and does not pass the SIP proxy server. In this way, the SIP protocol can easily achieve service mobility on the Internet.
However, in some cases, this service mobile method is not feasible. For example, due to firewall penetration or other security considerations, the first jump of roaming users must use different servers through the local proxy server. In this case, it is possible to implement service movement, to achieve two aspects:
1. Roaming User Agents can find the local agent server that must pass.
2, requests for sending and accessing must pass through the parent domain proxy server and the local proxy server.
The first requirement to achieve [5] through the DHCP protocol extension through the SIP protocol, through which the user agent discovers the local agent server while obtaining IP addresses and other configuration information. The second requirement can be implemented by preloading the Route header in the request message. Typically, when the proxy server requires the RECORD-ROUTE header to join the Route header in the request. A configured proxy server can use the Route header message. If the Route header contains the URI of the Parent Manager Server, the request will reach the parent domain proxy server after the local proxy server, so that the request to send the request is satisfied. The two registration mechanisms are the request to receive through the parent domain and the local proxy server, which is similar to the flow shown in Figure 9.2, and the different is to transfer the INVITE message by the mother domain proxy server, not a redirect server. The mobile capabilities of the SIP protocol make it ideal for 802.11 wireless networks such as homes, offices, public places. When the wireless network "hotspot" in large cities can be connected to the SIP protocol, the commercial Wi-Fi isas SIP protocol builds a special purpose wireless telephone network. In terms of business and service, they have developed some SIP protocol expansion, we will introduce in the following sections.
Wireless SIP customers can also utilize speech coding techniques such as ILBC [6]. ILBC is not high on packet loss rate, and there is operational experience in busy 802.11 networks.
9.3 3GPP architecture and SIP
The IP Multimedia Subsystem (IMS) in the 3GPP architecture uses the SIP protocol, and Fig. 9.5 shows a simplified IMS structure, and the basic elements of IMS are given in Table 9.1. SIPs in the 3GPP system in 3GPP TS 24.229 and literature [7] have a detailed introduction.
Figure 9.5 Architecture of 3GPP IMS
Table 9.1 Basic elements in the IMS structure
AbbreviationNameP-CSCFProxy - Call Session Control FunctionI-CSCFInterrogating - Call Session Control FunctionS-CSCFServing - Call Session Control FunctionUEUser EquipmentMGCFMedia Gateway Control FunctionMGWMedia GatewayASApplication ServerMRFCMedia Resource Function ControllerBGCFBreakout Gateway Control FunctionHSSHome Subscriber Server
For basic business considerations, the 3GPP structure utilizes the mobile IP instead of certain aspects of the previously mentioned SIP mobility.
Another requirement for the mobile system is to keep the signal connection, which means that the terminal and proxy server should know that the user agent has always been connected to the network. The terminal and terminal base stations are implemented by RTCP (specifically 7.2) periodic reports, which can be implemented in the media for mute or suppression. The proxy server cannot implement the above functions by end-to-end, session schedule expansion [8] and RE-INVITE implement this feature.
CSCF can be used as a SIP proxy server, sometimes it is also used as B2BUA. For example, because the session is charged in minutes, the UE does not have a function of terminating billing, when the P-CSCF wants to disconnect and built-in the UE connection, send a BYE message to the UE to terminate the session. To save wirelessly connected bandwidth, P-CSCF removes Route, Record-Route, Path, VIA, Service-Route and other header heads, and embed them in reverse direction. To prevent UEs from using a high bandwidth coding technology, P-CSCF provides an encoding list used in SDP. P-CSCF can supervise the TO and FROM headers to protect personal privacy, which is functional as B2BUA.
P-CSCF provides emergency services, launching the local service, and standardizing the phone number. P-CSCF is typically treated as an output proxy server that is not in the UE in the parent domain. The I-CSCF determines the appropriate S-CSCF by querying HSS, I-CSCF can also hide the S-CSCF, S-CSCF for the predetermined person by deleting or encrypting the VIA header header, and identifying user services and their permissions. 3GPP plans to apply IPv6 network addresses because 3GPP has a large potential appler, and the reality of the mobile IP protocol, one device may use more than one IP address. SIP RFC 3261 fully supports the use of IPv6, SDP [9], also added support for IPv6.
When the wireless connection transmits SIP information, 3GPP uses signaling compression [10], which mainly considers shortening the data package waiting time, followed by bandwidth. There is a detailed discussion on the SIP signaling compression method in the literature [11]. It first defines a parameter comp = singcomp, which can be applied to the VIA header, or as a URI parameter application, for example, in the Contact header
3GPP uses AMR [12] to coding as its audio coding technology.
9.4 3GPP header head
This chapter will discuss some SIP title headers based on the requirements of 3GPP organizations. In Chapter 6 we introduced the title header of SIP, and its 3GPP external structure has no standardized application. It is possible that in the near future, the IETF organization standardizes it, and its applications will be more extensive.
9.4.1 Service-Route
Service-Route header [13] can be used in 2 ×× Response Register request. The registration server provides registration of UA Uris, further requesting preload Route header service-route Uris is only valid during registration and updates with registration information. An example of a service-route:
Service-route:
9.4.2 Path Title
Path Title [14] is an option in the Register request. It can be seen as a Service-Route mechanism requested by the Register, and creates a route during registration. The proxy server can embed the Path header head, transfer the Register request to the registration server, providing routing information when the user agent is registered. In the mobile network, the PATH header head can be used to discover and notify the user agent's proxy server, which can be preloaded in the Route header head. An example of a PATH:
PATH:
9.4.3 Other P Title Head
3GPP also defined some special header heads [15], known as the P header head, it is a short written in ProPrietary, Preliminary, or Private. Its domination definitions appear in the RFC information that is changed by each SIP protocol, see section 10.7, and Table 9.2 lists it.
Table 9.2 3GPP P Title
Header FieldUseP-Associated-URI Lists other URIs associated with the userP-Called-Party-ID Lists the URI of the called partyP-Visited-Network-ID Identifies the visited networkP-Access-Network-Info Identifies the access networkP-Charging-Function -Addresses contains charging informationp-charging-vector more Charging Informationsource: [15]. 9.5 SIP and Wi-Fi foreground
There is no doubt that the IP network develops in the direction of the wireless network, and the SIP protocol is applied to the wireless network. Through the discussion of this chapter, we can see that the SIP protocol is ideal for wireless networks, which can provide support in the application of mobile IP protocols and non-applied mobile IP protocol design wireless networks.
By using the SIP protocol, identity verification and roaming can be solved, which is an extension of a professional 3GPP structure, which is not too much for most other networks.
references:
1. Information About The 3GPP Project, Including The Latest Technical Specifications (TS), Can Be Found At http://www.3gpp.org.
2. Schulzrinne, H., AND E. WEDLUND, "Application-Layer Mobility Using Sip", Mobility Mobile Computing and Communications Review (MC2R), VOL. 4, No. 3, July 2000.
3. Perkins, C., "IP Mobility Support", RFC 2002, 1996.
4. VAKIL, F., ET Al., "Supporting Mobility for MultiMedia with Sip", IETF Internet-Draft, Work In Progress, December 2000.
5. Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers, RFC 3361, 2002.
6. DURIC, A., AND
S. Anderson
"RTP PayLoad Format for ILBC Speech", IETF Internet-Draft, Work in Progress, March 2003.
7. 3GPP TS Relating to Sip Include TS 23.228 and TS 24.229. For the Latest On these and other sip-related specifications, Visit http://www.3gpp.org.
8. Donovan, S., AND J. Rosenberg, "Session Timers in the session Initiation Protocol (SIP)", IETF Internet-Draft, Work In Progress, November 2002.
9. Olson, S., G. Camarillo, And A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, 2002.10. Price, R., et al., "Signaling Compression (SIGCOMP)" RFC 3320, 2003.
11.
Camarillo
, G., "Compressing the session Initiation Protocol (SIP)", RFC 3486, February 2003.
12. Sjoberg, J., et al., "Real-Time Transport Protocol Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
13. Willis, D., And B. Honeisen, "Session Initiation Protocol Extension Header Field for
Service Route
Discovery During Registration, IETF Internet-Draft, Work In Progress, February 2003.
14. Willis, D., And B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts, RFC 3327, 2003.
15. Garcia-Martin, M., E. Henrikson, And D. Mills, "Private Header (p-header) Extensions to the session initiation protocol (SIP) for the 3rd-generation partnership project (3GPP)", RFC 3255, 2003
16. MANKIN, A., ET Al., "Change Process for the session Initiation Protocol (SIP)", RFC 3427, 2002.
