路由

11.3.1概述

IMS中最复杂的问题之一就是请求消息的路由，尤其是初始请求的路由。在我们的例子中，Tobias发送初始LNVITE请求给Theresa。其结果是，建立了一个SIP对话，并通过它发送若干后续的请求，例如ACK、PRACK、UPDATE和BYE。

Tobias UE发送 INVITE请求时并不知道如何才能达到TheresaUE。它所能提供的所有信息仅包括：

• INVITE请求的最终目的地——即Theresa的SIPURI(她公共用户标识之一)，Tobias必须要提供(例如从他的电话本中选取)。

• P-CSCF的地址——即TobiasUE的出站代理，也是路由的第一跳。该地址是在SIP注册之前的P-CSCF发现过程(见10.3节)中获得的。

• S-CSCF的地址——这是在注册过程中通过Service-Route消息头发现的(见10.5.8节)。

具备了这些不完整的路由信息之后，INVITE请求就上路了。它先后经过为Tobias选派的P-CSCF和S-CSCF。

Tobias的S-CSCF现在除了最终目的地(即Theresa的公共用户标识:"sip:Theresa@home2.hu")之外，没有任何进一步的路由信息。由于Tobias的S-CSCF不是Theresa的注册服务器，它只能解析地址的宿主部分“home2.hu”。它将该域名发往域名系统(DNS)服务器，然后将收到一个或多个Theresa归属网络中的问询CSCF(I-CSCF)地址。S-CSCF选择其中之一并把INVITE请求发给它。

I-CSCF仅作为Theresa归属网络的入口。它询问本地HSS为Theresa选派哪个S-CSCF,并把INVITE请求进一步转发到该S-CSCF地址。

现在Theresa的S-CSCF就作为注册服务器，将她的SIPURI更换成她已注册的联系地址。它还不直接将请求发往TheresaUE，因为它还没有和UE建立SA（见10.7节）。因此，这个INVITE请求首先被发往Theresa的P-CSCF。S-CSCF知道P-CSCF的地址，因为Theresa注册过程中从Path头收到了该地址（见10.5.9节）。最终，P-CSCF通过IPsec SA将INVITE请求转发到TheresaUE。

以上显示了对于初始的请求，从Tobias到Theresa的路由是一段一段被拼接起来的，因为主叫UE和各个CSCF都仅仅知道需要经过的下一跳或两跳的信息。为了使得该对话中后续的消息路由更为简单，将使用SIP路由机制（见12.12节）：

• 所有的CSCF都将自己的地址放在Via消息头的顶端——这使得所有对于INVITE请求的响应都可以准确地沿着请求消息所经过的路由发送回去。

• 除Theresa的I-CSCF以外，所有CSCF将自己的地址放入Record-Route头的顶端一这使得该对话中所有的后续请求都可以根据Record-Route头记录的CSCF而顺序转发。Theresa归属网络的I-CSCF在找到Theresa的S-CSCF地址后就完成了它的路由功能，因此在后续路由中就不再需要它了。

当发送后续请求时，UE将包含一个Route条目的列表，这将强制该请求沿着已记录的路由转发（见图11-2）。与服务提供有关的路由问题将在11.3.8节中介绍。

11.3.2 会话、对话、事务和分支

在会话建立过程中以及会话保持活跃的过程中，两个UE之间要交换多种不同的信令消息，并建立各种不同的关系。

名词“会话（Session）”描述了两个用户之间的媒体连接。Tobias希望与他姐姐之间交换音频和视频媒体流。这种媒体交换是在所谓“承载层”完成的，这意味着RTP（实时传输协议）数据包从两个UE发往它们的GGSN（网关GPRS支持节点），然后GGSN直接通过骨干网交换彼此之间的这些数据包。这个会话是建立在SIP和SDP信令基础上的，而这些信令通过“控制平面”交换。

SIP对话（Dialog）是两个UE之间用于建立、更改和释放媒体会话的信令关系。对话首先将（通过INVITE请求）建立起来，并且在与相关的会话保持活跃期间一直存在。每个SIP对话通过SIP请求中Call-ID头的值、To和From头中的标签来标识。本例中如下所示：

From:“Yourbrother“<sip:tobi@brother.com>;tag=veli

TO:”MybelovedSister“<sip:theresa@home2.hu>;tag=schwester

Call-Id:apb03a0s09dkjdfglkj49555

Tobias和Theresa间多媒体会话的SIP对话起始于INVITE请求，并终止于对BYE请求的200（OK）响应。

图11.2初始INVITE请求及其响应的路由

一个SIP事务（transaction）由一个SIP请求和所有对它的响应构成。为建立会话，TobiasUE发送INVITE请求给TheresaUEo首先它会收到P-CSCF对该请求的100（尝试中）响应。之后，TheresaUE返回一个183（会话进行中）、一个180（振铃中）并最终给出一个200（OK）响应。所有这5个消息属于同一个对话,并具有相同的CSeq号。

From:"Yourbrother"<sip:tobi@brother.com>;tag=veli

To:"MybelovedSister"

<sip:theresa@home2.hu>;tag=schwester

Call-Id:apb03a0s09dkjdfglkj49555

Cseq:1112INVITE

来自同一点（本例是Tobias UE）的每个后续请求都具有比前一个请求更高的CSeq值，例如第一个PRACK请求的CSeq是1113,接下来的UPDATE请求的CSeq是1114,依此类推。

每个实体，包括UE和CSCF,都基于“分支（branch）”参数把收到的响应与发出的请求相关联起来，branch参数是作为Via消息头的参数而添加的。例如，Tobias的P-CSCF将下面的Via头加到INVITE请求中：

INVITE sip:Theresa@home2.huSIP/2.0

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

这个branch参数在P-CSCF处标识了INVITE事务（即INVITE请求和及其响应），它的构造是通过请求中的To和From头的标签、Call-ID、Cseq号码以及Via头中最顶端的信息来完成的。

11.3.3INVITE请求的路由

11.3.3.1从TobiasUE到P-CSCF

TobiasUE将在初始的INVITE请求中包含如下与路由相关的消息头：

INVITEsip:theresa@home2.huSIP/2.0

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

Route:<sip:[5555::a:b:c:d]:7531;lr>

Route:<sip:orig@scscfl.homel.fr;lr>

Contact:<sip:[5555::1:2:3:4]:1357>

该请求的目的地是Theresa的SIPURI,如请求URI示。

在注册过程中，TobiasUE到其归属网络S-CSCF之间的路由是通过Service-Route头发现的（见10.5.8节）。UE预先将这部分路由放到Route消息头中，然后把P-CSCF加在上面，因为UE总是需要首先联系气出站代理。

TobiasUE还把自己的IP地址放在请求消息的Contact消息头中，这样对端的UEB就可以直接访问它。它还将其IP地址放在Via消息头中，以便可以接收到对该请求的响应。

当已建立的IPsecSA发送请求消息通过时，TobiasUE会：

• 把Contact消息头的端口值设置为UE的受保护的服务器端口（1357）,因为它希望通过已建立的IPsecSA接收该对话中所有的后续请求。

• 把Via消息头的端口值设置为UE的受保护的服务器端口（1357）,因为它希望通过已建立的IPsecSA接收对INVITE请求的所有的响应。

• 把Route消息头中P-CSCF地址的端口值设置为P-CSCF受保护的服务器端口（7531）,因为P-CSCF必须通过已建立的IPsecSA接收所有来自UE的请求。UE是在SIP安全机制协定过程（见10.7.5和10.8节）中得知P-CSCF受保护的服务器端口。

To和From消息头从来不用于路由的目的（见11.2.2节）。

现在INVITE请求将发往Route消息头中最顶端的地址,在本例中就是服务于Tobias的P-CSCF。

11.3.3.2从Tobias的P-CSCF到S-CSCF

当接收到请求消息时，P-CSCF会：

• 从Route消息头的顶端删除自己的地址。

• 检查该请求包含的路由信息是否与在注册过程中所保存的进一步的路由信息相一致（即UE并没有试图违背Service-Route）。

• 在Via消息头的顶端填入自己的地址，因为它希望接收对INVITE请求的所有的响应。

• 添加第一^Record-Route消息头并在其中填写它自己的地址 这可以确保该对话中所有后续的请求都会经过该P-CSCF。

• 在Via和Record-Route头中都不包含受保护的服务器端口号——受保护的服务器端口号仅仅用于接收UE通过已建立的IPsecSA组发来的SIP消息。

完成这些之后，P-CSCF再次将分组路由到Route头最顶端的地址，本例中即是为Tobias提供服务的S-CSCF：

INVITE sip:theresa@home2.huSIP/2.0

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Route:<sip:orig@scscfl.homel.fr;lr>

Contact:<sip:[5555::l:2:3:4]:1357>

11.3.3.3从Tobias的S-CSCF到Theresa的归属网络（I-CSCF）

Tobias的S-CSCF把自己的地址从Route消息头的顶端除去；之后Route消息头就空了，可以被删除。之后S-CSCF将自己的地址放在Record-Route和Via头的顶端。接下来，S-CSCF执行11.3.8节所介绍的服务提供过程。

完成这些步骤之后，它就要进一步转发该请求消息。但是，现在出现了一个问题：没有Route消息头来指示下一跳的地址。现在S-CSCF所能做的就是取出请求URI中Theresa的公共用户标识的宿主部分（即“home2.hu”），并且通过DNS找到该域的一个SIP服务器（见15.1节）。作为应答，它会收到Theresa归属网络的一个或多个I-CSCF的地址，它从中选取一个并将请求转发过去。

请注意，当S-CSCF知道这个I-CSCF可以作为宽松路由器时，它惟一能做的就是将I-CSCF地址放入Route消息头。在本例中，S-CSCF和I-CSCF在不同的网络中，因此假设S-CSCF无法知道LCSCF的路由能力，因此它通过UDP包将初始INVITE请求发往I-CSCF地址。

INVITE sip:theresa@home2.hu SIP/2.0

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

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl,visitedl.fi;lr>

Contact:<sip:[5555::l:2:3:4]:1357>

11.3.3.4从I-CSCF到Theresa的S-CSCF

现在Theresa归属网络的I-CSCF需要找到为Theresa分配的S-CSCF的地址。即便Theresa现在是未注册状态，只要她订阅了某些服务而现在是未注册状态，I-CSCF就能够找到一个缺省的S-CSCF地址。

有关当前为某用户所分配的S-CSCF的信息存储在归属用户服务器（HSS）中；由于网络中可能同时存在多个HSS,I-CSCF首先需要查询订购关系定位功能（SLF）来找到保存Theresa数据的HSS。SLF返回HSS地址后，I-CSCF便查询该HSS最终得到为Theresa提供服务的那个S-CSCF的地址。现在,1-CSCF在Route列表顶端添加一个Route项，并填入所收到的S-CSCF地址。然后，I-CSCF会：

• 从Route消息头顶端删除它自己的条目，如果存在该项的话（本例中不存在该项）。

• 把它的地址放入Via列表顶端，以便可以收到对INVITE请求的所有响应。

• 并不把它的地址放入Record-Route中，由于它不需要再收到该对话中的任何后续请求——I-CSCF的任务就是找到被叫用户的S-CSCF,但是由于这是在初次请求过程中完成的，因此在Route消息头中不再需要保留它。

请求消息再次发往Route消息头最顶端的地址，这次是Theresa的S-CSCF。

INVITE sip;theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPicscfl,home2.hu;branch=bicth

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

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

Via:Sip/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl,visitedl.fi;lr>

Contact:<sip:[5555::l:2:3:4]:1357>

11.3.3.5从Theresa的S-CSCF至ijP-CSCF

现在，Theresa的S-CSCF（她的注册服务器）收到了INVITE请求。同样，它也从Route头中删除自己地址的条目，并把自己的地址放入Via和Record-Route列表。然后，它按照11.3.8节中介绍的那样为Theresa提供服务。

做完这些之后，S-CSCF就执行注册服务器的功能（即它把请求URLTheresa的SIP地址，换成她的已注册联系地址）。已注册联系地址还包含一个受保护的服务器端口（1006）,用于通过建立的IPsecSA将请求从P-CSCF发给TheresaUE。

在Theresa的注册过程中，S-CSCF从P-CSCF处收到了Path消息头。它现在必须把Path消息头中的条目放到INVITE请求的Route消息头中去。如果不做这—步，该请求会被直接发往Theresa UE，但后者无法接收该请求，因为它没有和S-CSCF之间建立IPsecSA。

因此S-CSCF增加一个新的Route消息头，并填入P-CSCF地址，由于现在这就是最顶端的条目了，因此该请求会立刻发往该地址。

INVITE sip:theresa（ahome2.hu SIP2.0

Via:SIP/2.0/UDPscscf2.home2.hu;branch=cscth

Via:SIP/2.0/UDPicscfl.home2.hu;branch=bicth

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

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

Via:Sip/2.O/UDP[5555::l:2:3:4]:1357;branch=8uetb

Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:<sip:[5555::l:2:3:4]:1357>

11.3.3.6从P-CSCF到TheresaUE

P-CSCF收到请求之后，它会按照惯例操作：将整个Route头删除，并将自己放入Record-Route和Via头中，并将请求发往最终目的地，也就是请求URI中指示的 TheresaUE。

INVITEsip:[5555::5:6:7:8]：1006SIP/2.0

Via:SIP/2.0/UDPpcscf2.home2.hu:1511;branch=dpcth

Via:SIP/2.0/UDPscscf2.home2.hu;branch=cscth

Via:SIP/2.0/UDPicscfl.home2.hu;branch=bicth

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

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Route:<sip:pcscf2.home2.hu:1511;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visited

Contact:<sip:[5555::l:2:3:4]:1357>

Via头中的P-CSCF条目还包含受保护的服务器端口的端口号（1511）,该端口号是在Theresa注册过程中与TheresaUE协商确定的，与10.7.5节介绍的Tobias注册过程相同。该条目迫使Theresa UE通过已建立的IPsec SA来发送对于该请求的所有响应。

完全相同的受保护服务器端口（1511）也被填入P-CSCF的Record-Route消息头的条目中，P-CSCF希望在这里收到该对话中所有后续的来自TheresaUE的请求。

当Theresa UE收到INVITE请求后,它保存所收到的Contact值和Record-Route消息头列表，因为它还要基于这些信息对该对话中的后续请求进行路由。

11.3.4首个响应的路由

11.3.4.1 从TheresaUE到P-CSCF

现在，Theresa UE根据先决条件（见11.6节）对收到的INVITE请求生成一个响应消息：183（会话进行中）响应。

UE在Contact消息头中填入自己的IP地址，指示它希望用此地址接收该对话中的后续请求。这个Contact地址还包括TheresaUE受保护的服务器端口（1006）,以确保所有后续请求都是通过已建立IPsec SA来接收的。

INVITE请求的Record-Route和Via消息头也会出现在响应中。之后，TheresaUE将该响应发送到Via消息头最顶端的地址和端口号，即P-CSCF的受保护的服务器端口号：

SIP/2.0183 SessioninProgress

Via:SIP/2.0/UDPpcscf2.home2.hu:1511;branch=dpcth

Via:SIP/2.0/UDPscscf2.home2.hu;branch=cscth

Via:SIP/2.0/UDPicscfl.home2.hu;branch=bicth

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

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Record-Route:<sip:pcscf2.home2.hu:1511;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:<sip:[5555::5:6:7:8]:1006>

TheresaUE对该INVITE请求而发出的所有的其他响应也都会包含与183（会话进行中）响应中相同的Via消息头。

11.3.4.2从Theresa的P-CSCF到Tobias的P-CSCF

P-CSCF通过Via消息头中自己设定的branch参数来标识该响应属于哪个INVITE事务。它会按照如下的方式来处理183（会话进行中）响应中的路由信息:

•  它将自己的地址从Via头中删除。

•  它重写自己的Record-Route条目。

•  它将请求发往Via头顶端的地址，即Theresa归属网络的S-CSCF。

P-CSCF为何要重写它的Record-Route条目呢？它这样做是为了确保除TheresaUE以外，其他任何实体都不会向P-CSCF的受保护的服务器端口发送消息，而这个端口只用于和UE之间的IPsecSAo如果TheresaS-CSCF向P-CSCF的受保护服务器端口（1511）发送下一个请求（PRACK）,则该请求会被P-CSCF协议栈的IPsec层丢弃，因为它在发送过程中没有经过IPsecSA的完整性保护。

SIP/2.0183 Session in Progress

Via:SIP/2.0/UDPscscf2.home2.hu;branch=cscth

Via:SIP/2.0/UDPicscfl.home2.hu;branch=bicth

Via:SIP/2.0/UDPscscfl.homel.fir;branch=asctb

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

Via:Sip/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

Record-Route:<sip:pcscf2.home2.hu;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:<sip:[5555::5:6:7:8]:1006>

从现在开始，直到它达到Tobias的P-CSCF之前，响应消息不会再发生任何重要变化——每一跳仅仅是删掉它自己的Via条目，并把消息发往Via中的下一个条目。Record-Route保持不变。请注意，允许返回途中的其他服务器改写它们的Record-Route条目，以区分来自不同方向的请求。但是，这在本例中没有这样做,因为这仅是CSCF具体实现中的可选功能。

11.3.4.3从Tobias的P-CSCF到他的UE

收到183（会话进行中）响应后，TobiasP-CSCF执行与TheresaP-CSCF相类似的操作。它也重写Record-Route消息头中关于它自己的条目，但是它不会删除受保护的服务器端口（与TheresaP-CSCF处理同一响应的方式完全相同），而是增加该端口（7531）。其结果就是强制TobiasUE必须通过巳建立的IPsecSA来发送所有后续的请求。

由于P-CSCF根据Via头来转发响应，它会将该响应发往TobiasUE的受保护的服务器端口（1357）,即通过IPsec SA发送：

SIP/2.0183 Session in Progress

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

Record-Route:<sip:pcscf2.home2.hu;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi:1357;lr>

Contact:<sip:[5555::5:6:7:8]:1006>

TobiasUE在收到响应消息后，会：

• 从Contact头中读出TheresaUE的IP地址并保存起来；

• 把Record-Route列表中的所有条目的顺序颠倒过来并保存起来。

11.3.5重传INVITE请求和100（尝试中）响应

发出INVITE请求之后，TobiasUE会等候来自TheresaUE的响应。它会等候计时器T1（在IMS中设置为2s）超时。每次超时之后，它就重传一个INVITE请求，直到收到对该请求的响应。如果128s（=64xT1）后还不能收到响应，它就告诉Tobias这次会话建立失败。

由于本例中的INVITE请求要经过欧洲各地的多个CSCF,因此它到达TheresaUE可能已经超过2s了，而且后者还要生成183（会话进行中）响应并沿原路长途跋涉返回芬兰。

为了避免Tobias UE频繁地重发INVITE请求，P-CSCF在收到INVITE请求后会发回一个100（尝试中）响应，这意味着现在开始P-CSCF会负责上述重传工作。

沿途的所有感知呼叫状态的其他SIP代理都会发出相同的100（尝试中）响应（见图11-1）,该响应总是终止于最后一个负责进行重传的SIP代理。例如-Theresa归属网络的S-CSCF发回一个100（尝试中）响应，它首先到达I-CSCF。由于I-CSCF并不是能感知呼叫状态的SIP代理，它只是再次转发（基于Via头）。接下来，响应到达Tobias归属网络的S-CSCF。Tobias的S-CSCF已经向P-CSCF发出过100（尝试中）响应，因此它已经承担起重传INVITE的任务。现在接收到了100（尝试中）响应，说明不需要继续重传INVITE请求，因为这个责任已经转移到Theresa的S-CSCF上。

11.3.6同一对话中后续请求的路由

当两个UE其中之一需要发起这一对话中的后续请求时，它将所存储的Record-Route条目复制到新请求的Route头中，并把对端UE的IP地址放入请求URI中。

这个请求会严格按照Route消息头中的条目路由到对端UE（见图11-3）。途

2

图11-3 后续请求及其相应的路由

中经过的每个CSCF都把自己的地址放在Via头中，以便得到对于该请求的所有响应。

由于I-CSCF从一开始就不记录任何路由，因此它不会再收到任何后续请求。例如，TobiasUE要返回一个PRACK请求来确认已收到183（会话进行中）响应

（见11.5.2节）。这个PRACK请求要包含如下路由信息：

PRACK sip:[5555::5:6:7:8]:1006SIP/2.0

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

Record:<sip:pcscfl.visitedl.fi:7531;lr>

Record:<sip:scscfl,homel.fr;lr>

Record:<sip:scscf2.home2.hu;lr>

Record:<sip:pcscf2.home2.hu;lr>

因此，该PRACK请求会被按照如下方式路由：

• 根据Route头，到达Tobias的P-CSCF和S-CSCF,之后是Theresa的S-CSCF和P-CSCF；

• Theresa的P-CSCF根据请求URI地址，通过IPsec SA,发往Theresa UE；请求URI取自TobiasUE从183（会话进行中）响应的Contact消息头。

一个对话中的后续请求中不再包含Contact消息头，因为两个UE的地址已经在初始请求及其初始响应的发送和接收过程中交换过了。此外，CSCF也不在请求中放入任何Record-Route头，因为在初始请求中已经记录下了路由。

TheresaUE将对PRACK请求发出一个200（OK）响应，并包含下列路由信息：

SIP/2.0200OK

Via:SIP/2.0/UDPscscf2.home2.hu;branch=c2scth

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

Via:SIP/2.0/UDPpcscfl.visited1.fi;branch=92pctb

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

该响应根据Via消息头中的条目而路由回去，不再返回Record-Route头。

11.3.7两个UE之间的独立事务

对于独立事务，例如MESSAGE和OPTION,将采用与初始请求相同的路由过程，只是不需要记录路由，因为独立事务不会生成对话。

11.3.8与AS之间的路由

11.3.8.1S-CSCF上的过滤准则评估

应用服务器（AS）实现了IMS的服务提供，要根据初始过滤准则来联系AS。当Tobias或Theresa的S-CSCF收到一个初始请求时，它会逐个检查这些过滤准则，如果匹配了其中一个或多个，它就会把请求发送给准则中指出的AS。过滤准则是注册过程中由S-CSCF从HSS中下载而来的，作为Tobias和Theresa服务配置的一部分，详细介绍请见3.13节。

在本例中，我们假设有三个AS为来自Tobias的请求设置了过滤准则（见表11-1）。Tobias的S-CSCF会针对INVITE请求中收到的信息来逐个检查这些过滤准则。

INVITE sip:theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPscscfl.honel.fr;branch=asctb

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

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

Route:<sip:orig@scscfl.homel.fr;lr>

From:nYourBrotherH<sip:tobi@brother.com>;tag=veli

To:"MybelovedSisterM<sip:Theresa@sister.com

P-Asserted-Identity:<sip:tobias@home1.fr>

Privacy:None

表11.1  TobiasS-CSCF中的过滤准则

注：星号表示任何值都可以匹配。

过滤准则#1不匹配，因为经检查为公共用户标识而设置的服务点触发器（SPT）,发现P-Asserted-Identity头中没有包含Tobias的telURL。

过滤准则#2获得了匹配，因为：

•  该INVITE请求来自会话发起用户——S-CSCF是通过它当初设置在Service-Route头条目中的用户部分得知这一情况的，并且现在这个用户部分随着Route头返回来了（见］0.5.8节）。

•  P-Asserted-Identity的设置满足过滤准则的公共用户标识之一（sip:tobias@homel.fr）。

• SIP方法是INVITE。

11.3.8.2从S-CSCF到AS

现在，S-CSCF需要将INVITE请求发往过滤准则2中指示的AS（图11-4）。S-CSCF还需要采取措施，来应付当AS完成操作后自己还会再次收到该INVITE请求，因为S-CSCF还要检查过滤准则3,以便将请求发往Theresa的归属网络。为了达到这个目的，S-CSCF增加一系列与路由有关的消息头：

图11-4   到应用服务器AS的路由

• 将它自己的地址放入Route头最顶端，以便可以接收到从AS发回的INVITE请求；

• 将AS的地址放入Route头最顶端，以便将AS作为INVITE请求路由的下一跳；

• 将它自己的地址放入Record-Route头最顶端，这样后续请求都会经过它；将它自己的地址放入Via头最顶端，以便它可以收到该请求的所有响应。

除此之外，S-CSCF还将Route头自己的条目中添加一个对话标识符，这个Route头是刚刚添加的，对话标识符特定于具体的实现方式。它将此对话标识符设置成某个值，使得它可以识别为此INVITE请求而生成的对话。进行这一操作的目的是什么呢？

AS（见3.13节介绍）有可能决定充当一个背靠背用户代理（B2BUA）,在本地终结这个INVITE请求。然后它发出一个新的INVITE请求给S-CSCF,带有新的CalMD。由于AS要使用Route头中的URI进行下一跳路由，因此S-CSCF将可以重新得到对话标识符。这样，它就可以知道这个新的Call-ID实际上是与早先收到的INVITE请求相关的。S-CSCF这时就可以正确地返回到向AS发出INVITE请求后的位置。

在本例中我们不再进一步分析AS作为B2BUA的情况：

INVITE sip:theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPscscfl.homel.fr;branch=9sc2as2tb

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Route:<sip:as2.homel.fr;lr>

Route:<sip:scscfl.homel.fr;lr>;dia-id=6574839201

Record-Route:<sip:scscfl.homel.fr;Ir>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

11.3.8.3从AS返回S-CSCF

收到INVITE请求后，AS会：

•  删除Route消息头最顶端的条目，它指向AS。

•  根据请求中的信息来提供服务。

•  可能依照[RFC3261]更改请求消息（例如增加另一个消息头）。

•  把自己的地址放入Via列表的顶端。

•  决定是否希望接收此对话的后续请求——如果希望，它就将自己的地址放在Record-Route列表的顶端（在本例中，我们假设AS希望将自己保留在Route头中）。

•  根据Route消息头中最顶端的地址将INVITE请求路由回S-CSCF。

INVITE请求现在如下所示：

INVITEsip:theresa@home2.huSIP/2.0

Via:SIP/2.0/UDP:as2.homel.fr;branch=vas2tb

Via:SIP/2.0/UDPscscfl.home1.fr;branch=9sc2as2tb

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

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;branch=8uetb

Route:<sip:scscfl.homel.fr;lr>;dia-id=6574839201

Record-Route:<sip:as2.homel.fr;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

11.3.8.4S-CSCF继续评估其他的过滤准则

当再次收到INVITE请求后，S-CSCF检查过滤准则3,因为SIP方法不是SUBSCIBE（如SPT所示），所以准则3不匹配。因此，S.CSCF继续执行正常路由过程，如11.3.3.3节所介绍（即它将INVITE请求发往Theresa归属网络的I-CSCF）。

由于服务提供会使得路由过程更加复杂，因此本例始终没有过多涉及；此处增加的Via、Route和Record-Route头也同样不再出现在本例的后续部分。

11.3.9相关标准

IMS服务提供体系的进一步介绍参见：

3GPPTS23.218:IPMultimedia（IM）sessionhandling;IMcallmodel;Stage2.