第九章 无线SIP与3GPP
翻译作者:张树国 地址:秦皇岛 燕山大学
在前面几章中，已经介绍了SIP协议的移动特性，在本章中，进一步讨论这些特性。2000年，3GPP组织在其发布的IMS5中采用SIP作为信令协议。从那以后，3GPP组织【1】发布了一系列的文件，在这些文件中，描述了他们计划采用的SIP协议的扩展和应用。本章将重点介绍这些扩展和应用，在本章的最后，将讨论无线SIP的发展方向。
9.1 IP 移动性
本节将介绍不同类型的移动形式，包括：终端移动，个人（用户）移动，服务移动【2】。终端移动是指当终端设备移动并可能改变接入点时，设备维持接入因特网的能力；个人（用户）移动是指使用一个固定的地址（标识符）跨越一系列的设备的能力；服务移动性是指当用户移动时获得同种服务的能力。
终端移动性可以通过移动IP来定位， IETF组织已经实现了移动IP的标准化。移动IP允许一个终端设备在漫游时和母域中使用同一个IP地址，漫游时通过监管地址到达终端设备，监管地址在其母域中注册。要到达漫游终端的数据包首先到达母域，然后通过监管地址中传到终端设备，整个过程如图9.1所示。移动IP的优点是隐藏了第三成及以上层的移动性，该协议不扩展就可以应用。
图9.1 移动IP 中IP包的三角路由
下面举例说明一下，使用固定IP地址的终端设备很容易能够保持TCP连接，然而移动IP有要接收的数据包不是直接路由到终端的缺点，这就导致数据包的报文等待时间的延长。对于Web浏览和E-mail这样的非实时业务来说，没有太大的影响。然而，实时媒体的传输对报文等待时间有严格的要求。一些被提议使用的协议，例如SIP协议，已经在在实际应用中被内置到移动IP中。而且，SIP协议具有在应用层处理终端移动某些方面的能力，这种能力能够提高RTP数据包路由和传输的效率（利用SIP能够避免通过移动IP所需的重新打包）。
因此，移动SIP装置可以采用两种不同的结构：一种是基于移动IP的应用，另一种是内置支持移动性的SIP。接下来的章节将分别介绍这两种不同的解决结构。正如我们将要讨论的一样，SIP协议能够很好的解决个人（用户）和服务移动性。
9.2 SIP 移动性
个人（用户）移动是使用一个固定的标识符跨越一系列的设备的能力。SIP协议使用URI（统一资源标识符），本身就具有这种能力。SIP协议还支持服务移动，××××××※
SIP协议通过 REGISTER方法获得基本的个人（用户）移动能力，通过注册方法，移动装置改变它的IP地址和因特网接入点，仍旧能接受到来电。在第二章和第四章介绍过实现方法，SIP协议的注册机制对一个特定的装置临时绑定了它的AOR URI和Contact URI。当该装置的IP地址发生改变的时候，注册机制允许该信息在SIP网络中自动更新。一个终端设备可以在提供多层注册服务的网络中漫游，在移动过程中，注册是通过另一个具有同样功能的网络把记录地址看成Contact地址完成的。如图9.2所示，用户代理暂时获得通过另一个服务提供网络获得一个暂时的SIP URI（这样考虑到安全，地方政策，防火墙穿透的需要），从图9.2中可以看出，用户代理完成两次注册，第一次注册通过新的服务提供网络完成，它绑定了设备的Contact URI和新网络中提供的AOR URI。第二次注册在母域中进行再次注册，把新网络提供的AOR URI 作为Contact URI提供给母域。在图的后半部分，给出了一次呼叫建立的流程，当请求来自母域的一个用户时，INVITE请求被重定向到新网络服务器，然后到达被叫用户代理。
图 9.2 通过SIP 注册实现通话前的移动性
第一次注册SIP消息如下：
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
第二次通过漫游注册的SIP消息如下：
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
图9.2中的第一个INVITE请求发向：sip:n.bowditch@salem.ma.us;第二个INVITE请求发向：sip:bowditch321@capetown.org;第三个INVITE请求发向：sip:nat@128.5.2.1,第三个INVITE请求到达Bowdith并建立会话。两次注册过程都需要周期性更新。
这种方法的缺点是SIP协议本身还没有提供获得本地URI的方法。通过一些非SIP协议方法可以获得本地URI，例如，网页登记。使用网页登记将和适当的认证，授权，以及计费机制结合起来。
本地注册的最佳方法是运用漫游用户代理来更新母域注册服务信息。IETF组织【4】已经提出这种方法，但还没有标准化。这种方法要求不改变SIP消息形式，只是产生一个注册员能够识别的漫游注册信息并响应该信息。将来，合适的认证和计费过程象注册一样标准化以后，漫游注册标准化也将成为可能。
在一个会话进行的过程中，移动终端也有可能从一个无线网络进入另一个无线网络，从而改变了它的IP地址（移动IP协议并不适合该情形）。在这种情况下基本的SIP协议就能够解决的很好，一个re-INVITE消息就能够更新Contact URI并且在携带的SDP消息体中更新媒体信息，如图9.3所示。Bowditch检测到一个新的无线网络，通过DHCP协议获得一个新的IP地址，发送一个re-INVITE消息，媒体流转向新的IP地址，假如在某一时刻，用户代理收到来自两个网络的媒体信息，这种干扰通常可以忽略，如果不能忽略，一些RTP数据包会丢失，会话可能暂时中断。
9.3 在移动会话过程中运用re-INVIRE
Re-INVITE消息如下：
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 0
a=rtpmap:0 PCMU/8000
Bowditch的新的IP地址包含在Via中，Contact头部和SDP媒体信息消息体中。
图9.2，9.3所示的情况都没有考虑到两种不同类型的无线网络之间的协同工作问题，举例来说，用户代理从一个商业无线网进入到办公室或家庭的802.11网络，这种情况也经常发生。
在这种情况下，在移动通话中的实际路由实体（SIP消息必须穿过的SIP代理服务器）发生改变，一个简单的re-INVITE消息不能够完成转变。比如，网络发生改变时，需要一个防火墙穿透的代理而不仅仅是一个Contact URI，就必须重新建立一个会话。解决方法是发送一个带Replaces头的新的INVITE消息，建立一个新的会话，新的会话中的路由实体包括新的代理服务器（详见6.2.23），新的会话能够识别现存会话。具体流程见图9.4。与图9.3所示的流程相似，不同的是，图9.4所示的流程只是在接受到包含Replaces信息的INVITE消息后，终端自动产生一个BYE消息来
图 9.4 在移动呼叫过程中运用携带Replaces的INVITE
中止现存的对话。在这种情况下，Bowditch和Laplace的现存对话包含过去访问的代理服务器（该服务器在会话开始是记录路由），新的会话运用新的无线网络包括现在访问的代理服务器。Bowditch 发送一个包含Replaces信息的INVITE消息，创建一个包含现在访问的代理服务器（记录路由）而不是过去访问的代理服务器，当Laplace接收INVITE，自动发送一个BYE消息中止上一次对话，BYE消息是通过过去访问的代理服务器发送的，而现在的对话中并不涉及该服务器。新创建的媒体会话运用包含在INVITE消息中SDP携带的新的IP地址。
SIP协议中的服务可以由代理服务器提供也可以由用户代理提供。对服务是由用户代理提供的用户来说，不存在服务移动性的问题。但是，除非所有的用户装置都提供相同的服务，服务移动和个人移动都会受到影响，而且，服务终端也只在终端设备接入到互联网上时发挥作用。类似于会话更新服务如果由用户代理提供，一旦终端设备出现暂时性的连接问题，终止服务就会失败。由于这样或者那样的原因，一些特定的服务，通过SIP代理服务器来完成。对这些服务来说，一个用户代理的服务移动意味着在漫游的时候使用相同的代理实体来路由呼叫和响应。
一般来说，考虑到Internet 的本质，当用户代理使用不同的互联网接入点时，没有理由不允许使用相同的代理服务器。也就是说，一个美国的用户代理通常使用一系列固定的代理服务器，当它漫游到欧洲的时候，仍旧可以使用这些服务器。例如，由于经过多个路由器，SIP数据包可能要经历较长的等待期，会话的建立可能要多用一、二秒时间。但是，这并不影响媒体会话的质量，因为媒体流是在两个用户代理之间进行，并不通过SIP代理服务器。这样，SIP协议就能在因特网上很容易实现服务移动性。
可是，在某些情况下，这种服务移动方法并不可行。例如，由于防火墙穿透或其他安全方面的考虑，必须通过本地代理服务器，漫游用户路由的第一跳必须使用不同的服务器。在这种情况下，要可能实现服务移动，要实现两个方面：
1、 漫游用户代理可以发现必须经过的当地代理服务器。
2、 发送和接入的请求都要经过母域代理服务器和本地代理服务器。
第一个要求通过SIP协议的DHCP协议扩展来实现【5】，通过该扩展，用户代理在获得IP地址和其他一些配置信息的同时发现当地代理服务器。第二个要求可以通过在请求消息中预载Route头来实现。通常，当代理服务器要求用Record-Route头的时候才在请求中加入Route头部。一个经过配置的代理服务器能够运用Route头的消息，如果Route头包含母域代理服务器的URI，请求就会通过本地代理服务器后到达母域代理服务器，这样，发送请求的要求满足了。两次注册机制是要接收的请求通过母域和本地代理服务器，这个流程和图9.2所示的流程相似，不同的是由母域代理服务器转送INVITE消息，而不是重定向服务器。
SIP协议的移动能力使其非常适合如家庭、办公室、公共场所的802.11无线网络，当大城市中的无线网络“热点”连接起来，就能够利用SIP协议提供无线服务，商业无线网络提供商计划利用SIP协议构建特殊用途的无线电话网络。处于业务和服务方面的考虑，他们已经开发了一些SIP协议扩展，我们将在本章后面几节介绍。
无线SIP客户还可以利用如iLBC【6】之类的语音编码技术。iLBC对丢包率的要求不高，而且有在繁忙的802.11网络中的运营经验。
9.3 3GPP的体系结构与SIP
3GPP体系结构中IP多媒体子系统（ IMS）运用SIP协议，图9.5给出了简化的IMS结构，表9.1给出了IMS的基本元素。在3GPP TS 24.229和文献【7】中对3GPP体系中SIP有详细的介绍。
图 9.5 3GPP IMS 的体系结构
表 9.1 IMS结构中的基本元素
Abbreviation
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
出于基本业务上的考虑，3GPP结构中利用移动IP代替前面提到的SIP移动性的某些方面。
对于移动系统的另外一个要求是要保持信号连接，这意味着终端和代理服务器要知道用户代理一直出于和网络的连接状态。终端和终端基站之间通过RTCP(具体见7.2节)周期性报告来实现，在媒体出于静音或抑制状态也能实现。而代理服务器不能够通过端到端来实现上述功能，会话计时扩展【8】和re-INVITE能够实现此功能。
CSCF可以作为SIP代理服务器，有时也作为B2BUA来使用。例如，因为会话按分钟进行收费，而UE不具有终止计费的功能，当P-CSCF想断开和内置SIP UA的UE连接时，向UE发送一个BYE消息来终止会话。为节省无线连接的带宽，P-CSCF移出Route、Record-Route、Path、Via、Service-Route等标题头，并把他们反方向嵌入。为防止UE端使用占用高带宽的编码技术，P-CSCF提供在SDP中使用的编码清单。P-CSCF能够监管To和From标题头，以保护个人隐私，这是作为B2BUA使用时具有的功能。
P-CSCF提供应急服务，启动本地服务，并把电话号码标准化。P-CSCF通常当作不在母域中的UE的输出代理服务器。I-CSCF通过查询HSS确定合适的S-CSCF，I-CSCF也可以通过删除或加密Via标题头来隐藏S-CSCF，S-CSCF对预定者提供服务，并且识别用户服务及其权限。
3GPP计划专门应用IPv6网络地址，这是因为3GPP有很大的潜在应用者，和使用移动IP协议的现实，一个装置可能同时使用不止一个IP地址。SIP RFC 3261全面支持使用IPv6，SDP【9】扩展也加入了对IPv6的支持。
在无线连接传输SIP信息时，3GPP使用信令压缩【10】，这样做主要考虑缩短数据包等待时间，其次节省带宽。在文献【11】中对SIP信令压缩用法有详细的论述。它首先定义一个参数comp=singcomp，它可以在Via标题头应用，也可作为URI参数应用，例如可以应用在Contact标题头
3GPP采用AMR【12】编码做为它的音频编码技术。
9.4 3GPP标题头
本章将讨论根据3GPP组织的要求发展起来一些SIP标题头。在第六章我们介绍了SIP的标题头，其3GPP外部结构的应用没有标准化应用。可能，在不久的将来，IETF组织将其标准化，它的应用将会更加广泛。
9.4.1 Service-Route
Service-Route标题头【13】可以用在2××响应REGISTER请求。注册服务器通过它来提供注册UA URIs，进一步请求的预载Route标题头Service-Route URIs只在注册期间有效，并随着注册信息的更新而更新。一个Service-Route 的例子：
Service-Route: <sip:proxy23.service.provider.com;lr>
9.4.2 Path标题头
Path标题头【14】是REGISTER请求中的可选项。它可以看成REGISTER请求的Service-Route机制，在注册期间创建路由。代理服务器可以嵌入Path标题头，转送REGISTER请求到注册服务器，当用户代理注册时，提供路由信息。在移动网络中，Path标题头可以用来发现和通知用户代理的代理服务器，可以预载于Route标题头中。一个Path的例子：
Path: <sip:proxy2.another.provider.com;lr>
9.4.3 其他的P标题头
3GPP还定义了一些特殊的标题头【15】，被称为P标题头，它是proprietary, preliminary, or private的简写。其语法定义仅在每次SIP协议改变的RFC信息中出现【16】，P标题头的应用流程见10.7节，表9.2列出了它的用途。
表9.2 3GPP的P标题头
Header Field
Use
P-Associated-URI
Lists other URIs associated with the user
P-Called-Party-ID
Lists the URI of the called party
P-Visited-Network-ID
Identifies the visited network
P-Access-Network-Info
Identifies the access network
P-Charging-Function-Addresses
Contains charging information
P-Charging-Vector
More charging information
Source:[15].
9.5 SIP及无线网络的前景
毫无疑问，IP网络在朝无线网路方向发展，SIP协议应用于无线网络。通过本章的讨论，我们可以看到，SIP协议非常适合无线网络，它在应用移动IP协议和不应用移动IP协议设计无线网络的情况下，都能够提供支持。
通过使用SIP协议可以解决身份验证和漫游等问题，这作为专业的3GPP结构体系的扩展，对其他大多数网络没有太大的用途。
参考文献：
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. Hoeneisen, "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.
