SIP注冊(cè)和注冊(cè)路由問(wèn)題

10.5.1 概述

本节阐述Tobias注册过程中与SIP路由有关的问题（见表10-1和图10-2）。

表10-1  与路由有关的消息头

Tobias的UE首先会生成一个REGISTER请求，发往Tobias运营商的归属域。相关信息将从Tobias的通用用户标识模块（USIM）中的IP多媒体服务标识模块（ISIM）应用中获得。该请求将经过P-CSCF和I-CSCF,如果没有事先指定S-CSCF,I-CSCF将为Tobias选择一个S-CSCF。

S-CSCF将根据REGISTER请求中的信息来建立Tobias公共用户标识与UE的IP地址之间的绑定关系。这使得来自其他用户的请求可以通过S-CSCF传送到Tobias的UE。S-CSCF会更新HSS中的注册信息，下载Tobias的用户配置，并根据从HSS中收到的初始过滤准则来通知所有与Tobias注册状态相关的应用服务器（AS）。

图10-2  认证过程中的路由

在注册过程中，UE可以从Service-Route消息头中获知通往S-CSCF的直接路由。此后，当Tobias的UE需要发出初始请求时，就不需要再联络I-CSCFT了。

S-CSCF从Path消息头中得知P-CSCF的地址。这是必须的，因为所有发往Tobias的初始化请求都必须首先经过P-CSCF才能达到UE。

10.5.2 构造REGISTER请求

在建立信令PDP上下文并发现P-CSCF地址之后，Tobias的UE可以开始生成初始的REGISTER请求：

REGISTER sip:homel.frSIP/2.0

Via:SIP/2.O/UDP[5555::l:2:3:4];branch=0uetb

Route:sip:[5555::a:f:f:e];Ir

Max-Forwards:70

From:<sip:tobias@homel,fr>;tag=pohja

To:<sip:tobias@home1,fr>

Contact:<sip:[5555::1:2:3:4]>;expires=600000

Call-ID:apb03a0s09dkjdfglkj49111

CSeq:25REGISTER

Content-Length:0

10.12.2节将描述如何从ISIM中得到所用的公共和私有用户标识以及注册服务器地址。上述消息不是一个完整的IMSREGISTER请求，其中隐去了一些消息头和参数，它只包含了为解释本节中的过程而必需的信息，后续的消息也是这样。

该请求消息的最终目的地是注册服务器，在请求URI中标志为sip:homel.fr（从ISIM中读出的Tobias的归属网络的域名）。

在To消息头中有要注册的公共用户标识sip:tobias@homel.fir,是从ISIM中读出。SIP注册的目的是告诉注册服务器：公共用户标识sip:tobias@homel.fr是可以通过Contact消息头中所指出的IP地址访问到的。该IP地址包含一个IPv6前缀，这是UE在建立专用信令PDP上下文时分配的（见10.2节）。

在Contact消息头中，UE还指出这个IP地址和SIP URI之间的绑定可以持续600000s（大约一星期）。在IMS中强制要求UE注册如此长的时间，然而网络可以调整这个时间。

• 在注册过程中，在REGISTER请求的200（OK）响应消息Contact消息头中，将超时时间设置为一个小些的值。

• 在用户注册之后，使用状态注册事件通知（例如10.13.2节中网络发起的重新认证部分）。

UE还将它的IP地址放到请求消息的Via消息头中，这就可以保证所有对该请求的响应都可以传送回UEoVia消息头中还包含一个Branch参数用于惟一标识该事务（Transaction）。路由上的每个实体都将加入它自己的Via消息头。

前面步骤中解析得到的P-CSCF地址也放到Route消息头中。P-CSCF是该REGISTER消息的下一跳，因此它是Route消息头的顶端也是惟一的条目。“;lr"参数表示该P-CSCF是一个宽松路由器（见12.12.2节）。

From消息头标识了正在进行注册的那个用户。可以看出在From消息头与To消息头中的公共用户标识是一样的，这是因为Tobias进行的是所谓的第一方（First-party）注册（即他在注册他自己）。

注意，From消息头包含一个标签，而To消息头则没有。该请求的接收方（即注册服务器）将在向UE发送响应时填写To中的标签。

还有Call-ID消息头，它和CSeq消息头一起标识这个REGISTER事务（Transaction）。

最后，由于Content-Length消息头中的内容为0,因此表示该REGISTER请求的正文部分是空的。

上个例子中，消息头的名字都是以长格式给出的。为了避免空中接口传送不必要的过长的信令，Tobias的UE可以使用压缩格式，这时该REGISTER请求是这样的：

REGISTERsip:homel.frSIP/2,0

v:SIP/2.0/UDP[5555::l:2:3:4];branch=0uetb

Route:sip:[5555::a:b:c:d];Ir

Max-Forwards:70

f:<sip:tobias@homel.fr>;tag=pohja

t:<sip:tobias@homel.fr>

m:<sip:[5555::1:2:3:4]>;expires=600000

i:apbO3aOsO9dkjdfglkj49111

CSeq:25REGISTER1:0

为使SIP消息便于阅读，本例中只使用长格式的消息头名称。

10.5.3从UE到P-CSCF

现在Tobias的UE可以发出该REGISTER请求了，其下一跳为Route消息头的最顶部的条目（即P-CSCF）o由于该请求长度完全不超过1300B,因此使用UDP传输。由于在Route消息头中没有指明使用哪个端口，因此该请求将被发送到默认SIP端口(默认SIP端口是5060）。

10.5.4从P-CSCF到I-CSCF

当接收到初始的REGISTER请求时，P-CSCF首次获知Tobias的UE正在使用它作为SIP的出站代理。由于此时Tobias还没有通过鉴权，P-CSCF还只能承担SIP出站代理的功能，因此它将尝试把REGISTER请求转发到下一跳。

P-CSCF从Route消息头中移去它自己的条目，这样Route消息头就空了。现在所留下的惟一路由信息是请求URI中的注册服务器地址，该地址指向Tobias的归属网络。为了找到归属网络中SIP代理的地址，P-CSCF需要通过DNS进行域名解析（域名在请求URI中给出）。通过使用DNS的NAPTR、SRV和AAAA查询，P-CSCF可以解析出Tobias归属网络中一个I-CSCF的地址（见第12章）。

然而，P-CSCF并不把I-CSCF的地址放在Route消息头中，因为它不能确定该I-CSCF是否可以承担宽松路由器（LooseRouter）㊀的功能。因此，P-CSCF将I-CSCF的地址放在传送SIP请求的UDP分组中，直接作为UDP的目的地址。

在发送REGISTER消息之前，P-CSCF还将自己加入到Via消息头中，以便可以接收到对该请求的响应。它还在Via消息头中增加一个分支（Branch）参数：

REGISTERsip:homel.frSIP/2.0

Via:SIP/2.0/UDPsip:pcscfl.visitedl.fi;branch=0pctb

Via:SIP/2.0/UDP[5555::a:b:c:d];branch=0uetb

Max-Forwards:69

From:<sip:tobias@home1.fr>;tag=pohja

To:<sip:tobias@home1.fr>

Contact:<sip:[5555::1:2:3:4]>;expires=600000

Call-ID:apb03a0s09dkjdfglkj49111

CSeq:25REGISTER

Content-Length:0

10.5.5从I-CSCF到S-CSCF

I-CSCF是到达Tobias归属网络的入口，它将收到Tobias的UE所发起的每一

个REGISTER请求。它查询HSS以找到所分配的为正在注册的用户提供服务的S-CSCF,

如果目前为止还没有选择任何S-CSCF,LCSCF会负责选择一个。该过程在3.10节已经介绍过。

㊀译者注：宽松路由器是相对于严格路由器而言的。后者要求发往它的SIP请求的请求URI必须是它的地址，而前者则不要求这一点。

I-CSCF把自己的条目放在Via消息头的顶部，然后把该REGISTER请求发往S-CSCF,S-CSCF的地址要么是I-CSCF从HSS中查询得到的，要么是I-CSCF自己选择的。

REGISTERsip:homel.frSIP/2.0

Via:SIP/2.0/UDPsip:icscfl.homel.fr;branch=0ictb

Via:SIP/2.0/UDPsiprpcscfl.visitedl.fi;branch=0pctb

Via:SIP/2.0/UDP[5555::a:b:c:d];branch=0uetb

Route:sip:scscfl.homel.fir;Ir

Max-Forwards:68

From:<sip:tobias@homel.fr>;tag=pohja

To:<sip:tobias@homeLfr>

Contact:<sip:[5555::1:2:3:4]>;expires=600000

Call-ID:apb03a0s09dkjdfglkj49111

CSeq:25REGISTER

Content-Length:0

10.5.6在S-CSCF处注册

接到初始的REGISTER请求之后，S-CSCF要求Tobias进行认证，该过程在10.6节描述。这将导致Tobias发来另一个REGISTER请求。第二个REGISTER请求包含相同的有关注册的信息，并且它所经过的路由也与初始REGISTER请求完全相同。但是，第二个REGISTER请求将产生一个新的Call-ID.因此，它将包含新的CSeq号码、branch参数和一个新的From标签。S-CSCF接到的第二个REGISTER消息如下：

REGISTERsip:homel.frSIP/2.0

Via:SIP/2.0/UDPsip:icscfl.homel.fr;branch-3ictb

Via:SIP/2.0/UDPsip:pcscfl.visitedl.fi;branch=2pctb

Via:SIP/2.0/UDP[5555::a:b:c:d];branch=luetb

Route:siprscscfl.homel.fr;Ir

Max-Forwards:68

From:<sip:tobias@home1.fr>;tag=ulkomaa

To:<sip:tobias@homel.fr>

Contact:<sip:[5555::1:2:3:4]>;expires=600000

CaU-ID:apb03a0s09dkjdfg!kj49222

CSeq:47REGISTER

Content-Length:0

假设认证过程成功，S-CSCF将对Tobias进行注册。这意味着S-CSCF将创建一个绑定关系，绑定REGISTER请求To消息头中的公共用户标识(sip:tobias@homel.fr)和Contact地址(sip:[5555::a:b:c:d])。这个绑定时间将严格地保持600000s,即UE在Contact消息头"expires”参数中填写的值，除非S-CSCF基于本地策略而决定缩短该时间。

S-CSCF还会更新HSS中的数据，指示Tobias现在已经注册。HSS会通过Cx接口向S-CSCF下载Tobias的用户数据(见3.13节)。

10.5.7  200(0K)响应

随后S-CSCF向UE发回200(OK)响应，以指示注册过程已成功完成：

SIP/2.0200OK

Via:SIP/2.0/UDPicscfl.homel.fr;branch=3ictb

Via:SIP/2.0/UDPpcscfl.visitedl.fi;branch=2pctb

Via:SIP/2.0/UDP[5555::l:2:3:4]:1357;branch=luetb

From:<sip:tobias@homel.fr>;tag=ulkomaa

To:<sip:tobias@homel.fr>;tag=kotimaa

Contact:<sip:[5555::a:b:c:d]>;expires=600000

Call-ID:apb03a0s09dkjdfglkj49222

CSeq:47REGISTER

Content-Length:0

S-CSCF在To消息头中增加了一个标签。

这个响应被传送回UE时途经所有接收过REGISTER请求的CSCF,之所以可以这样是由于各CSCF在接收REGISTER请求时都把自己的地址放在了Via消息头的顶端。现在，当接收到200(OK)响应时，它们所作的就是从Via列表中移除自己的条目，并将请求转发到当前Via消息头中最顶端的地址。

当收到响应后，UE就得知注册过程已经成功了。

10.5.8Service-Route消息头

我们已经看到，在注册过程中UE和P-CSCF都不知道S-CSCF的地址，因此必须联系I-CSCF以便从HSS获得S-CSCF的地址。

为了避免UE发起每个初始消息时都要将I-CSCF作为额外的一跳，S-CSCF需要在反馈给REGISTER请求的200（0K）响应中的Service-Route消息头中填入它的地址：

S1P/2.0200OK

Service-Route:sip:orig@scscfl.homel.fr;lr

当接收到200（OK）响应时，UE将保存Service-Route消息头中所有的条目。这样无论何时当UE发出任何REGISTER以外的初始请求时，它将：

• 把Service-Route消息头中得到的地址填写在初始请求的Route消息头中；

• 把P-CSCF地址放在初始请求Route消息头的最顶端。

初始请求如何路由的例子可以参见10.12.2节的SUBSCRIBE请求和第11.3.2节的INVITE请求。

本例中S-CSCF在其Service-Route条目中增加了一个用户部分（“orig”），因为它需要区分两类不同的请求：

•从服务对象用户（例如Tobias）发起的请求；

•发往TobiasUE的请求。

任何时候当S-CSCF收到一个初始请求（例如INVITE请求）时，它需要判断该请求是来自用户还是发往服务对象的用户。利用Route消息头中的用户部分，S-CSCF能容易地知道所收到的请求是否是由服务对象用户发起的，因为Tobias的UE会在发出的所有请求中的Route条目中填入S-CSCF的Service-Route条目。

10.5.9Path消息头

S-CSCF将接到所有发往Tobias的初始请求，因为它充当了他的注册服务器。在正常的SIP过程中，注册服务器能够直接向UE发送请求。但在IMS中，这是不可能的，因为需要首先联系P-CSCFo这是因为P-CSCF已经和UE建立IPsecSA安全联盟，保证所有收发的消息都得到完整性保护（见10.7节）。不仅如此.P-CSCF还在媒体授权（见11.7.2节）上扮演重要角色，因为它是IMS中惟一与GGSN有直接连接的网元。

这样，S-CSCF需要确保发往UE的每个请求都要首先经过P-CSCF,为了达到这个目的，P-CSCF在所有REGISTER请求中添加Path消息头，填入自己的地址：

REGISTERsip:homel.frSIP/2.0

Path:sip:pcscfl.visitedl.fi;Ir

当用户成功注册后，S-CSCF会保存这个P-CSCF地址。任何时候当接收到发往Tobias的请求时，S-CSCF就添加一个Route消息头，填入从Path消息头中得到的地址。关于如何向服务对象用户路由转发初始INVITE请求的例子可以参见11.3.3.5节。

10.5.10向应用服务器的第三方注册

在成功注册后，S-CSCF要检查所下载的该用户的过滤规则（见3.13节）。我们假设有一个在线状态服务器为Tobias提供服务，该在线状态服务器需要知道Tobias现在已经注册并且是可达的。为了将此信息通知给该在线状态服务器，需要设置过滤规则，触发所有由Tobias公共用户标识发起的REGISTER请求（见图10-2）。

表10-2Tobias的S-CSCF中的过滤规则

由于这些过滤规则，Tobias无论何时成功地施了注册，S-CSCF都要生成一个第三方REGISTER请求（见图10-3）并发往在线状态服务器：

REGISTERsip:presence.home1.frSIP/2.0

Via:SIP/2.0/UDPscscfl.homel.fr;branch=99sctb

Max-Forwards:70

From:<sip:scscfl.homel.fr>;tag=6fa

To:vsip：tobias@homel.fi>

Contact:<sip:scscfl.homel.fr>;expires=600000

Call-ID:1as22kdoa45siewrf

CSeq:87REGISTER

Content-Length:0

这个REGISTER请求发往在线状态服务器presence.homel.fr,如请求URI所示。由于没有包含Route消息头，因此该请求将直接发往这个地址。

图10-3   S-CSCF实施的第三方注册

To消息头中包含Tobias的公共用户标识，这是被注册了的URI。

S-CSCF在From消息头中给出自己的地址，它代表Tobias（即作为第三方）来注册Tobias的公共用户标识。此外，S-CSCF还在Contact消息头中给出了自己的地址。这保证了在线状态服务器永远不会直接传送到Tobias的UE,而总是会先与S-CSCF联络。

在线状态服务器将为这个REGISTER请求向S-CSCF发回一个200（OK）响应，但并不会充当Tobias的注册服务器。它会认为这个REGISTER请求意味着Tobias已经在S-CSCF上成功地注册，而这个S-CSCF才是Tobias的注册服务器。如果在线状态服务器需要关于Tobias注册状态的更多信息（例如Tobias隐含注册的所有其他公共用户标识），它可以采取与UE和P-CSCF相同的方式（见5.12节）,以订阅Tobias的注册状态信息。

10.5.11相关标准

与10.5节有关的规范包括: