IMS多媒体电话会话举例

IMS多媒体电话会话举例Page1培训目标学完本课程后，您应该能：描述IMS域内及与CS域互通呼叫流程中的信令处理。列出INVITE请求及其临时响应的关键头域。完成呼叫流程中的相关配置和进行基本故障定位P-CSCF功能(会话期间)会话期间P-CSCF处理过程判断用户是否合法判断是否是紧急呼叫进行承载控制进行接入网判断头域处理，计费处理呼叫转发到UE或S-CSCFI-CSCF功能(会话期间)会话期间I-CSCF处理过程通过查询HSS获取为用户服务的S-CSCF的地址。进行拓扑隐藏S-CSCF功能(会话期间)会话期间S-CSCF处理过程头域处理路由处理紧急呼叫处理用户身份确认计费处理业务触发处理HSS功能(会话期间)会话期间HSS处理过程支持LIR查询，给I-CSCF返回给被叫用户服务的S-CSCFPage6目录IMS多媒体电话会话案例分析Page7目录呼叫IMS多媒体电话会话1.1主叫和被叫身份标识1.2路由1.3媒体协商1.4资源预留1.5会话的释放1.6IMS会话建立过程的替代方案Page8多媒体电话会话举例本节将介绍一个IMS多媒体电话会话的例子：

▪该会话发生在Tobias和Theresa之间，两者都在各自的归属网络中注册，并且目前都在外地漫游。

▪IMS利用SIP和SDP来确保Tobias和Theresa之间相互交谈，并且在手机屏幕上能看到对方。Page9概述提问：注册过程中，IMS用户如何得知他能用哪些公共用户身份，以及哪些身份标识是已经注册过的？在每种IMS对话中（本例中为INVITE对话），有两个身份标识是最基本的：

▪请求中需要给出已注册并已认证的主叫用户（Tobias）的公共用户身份，以便归属网络识别出该用户，并且判断其对于扩展服务的执行权限。

▪

请求中需要给出已注册并已认证的被叫用户（Theresa）的公共用户身份，以便找到该用户并为其提供服务。Page10From和To消息头TobiasUE发给Theresa的INVITE请求中包含以下与他们俩的身份标识有关的消息头：INVITEsip:Theresa@home2.huSIP/2.0From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>P-Preferred-Identity:<sip:tobias@home1.fr>Privacy:NoneFrom和To可以设置为发送者所希望的任何值在除REGISTER之外的任何请求消息中，这两个消息头的值都丝毫不会影响IMS路由和安全过程，它们可以随意设置。这两个消息头中，协议本身惟一需要的信息就是tag参数。Tobias的归属网络可以对To消息头中可设置的内容进行一定的限制。这种情况下，如果From和To消息头中的值不符合运营商的策略，归属网络只能拒绝该请求。Page11P-Preferred-Identity在INVITE请求中，包含了一个可选的P-Preferred-Identity消息头。如果使用了该消息头，它应该包含该用户的一个已注册的公共用户身份。如果Tobias希望对Theresa完全隐藏自己的标识，他必须将Privacy消息头的值设置为“id”。该值迫使Thereas的P-CSCF从INVITE请求中删除P-Asserted-Identity消息头。这样Theresa只能将From消息头中的身份作为主叫身份。Page12P-Asserted-IdentityTobiasUE发出的INVITE请求首先将到达P-CSCF。P-CSCF检查该请求是否来自于一个有效的IpsecSA。如果收到的请求没有受到保护，P-CSCF将拒绝它。之后，P-CSCF在INVITE请求中添加一个P-Asserted-Identity消息头，并且如果INVITY请求中包含P-Preferred-Identity消息头，则它会被P-Asserted-Identity消息头取而代之。在IMS对话中，P-Asserted-Identity消息头是惟一的、肯定包含了该用户已注册并已认证的公共用户身份的标识。如果INVITE请求中没有包含P-Preferred-Identity消息头，则P-CSCF添加的P-Asserted-Identity消息头中的用户标识是如何获取的？也就是说P-CSCF是怎样知道用户已注册并已认证的公共用户标识的。Page13P-Asserted-Identity如果有P-Preferred-Identity消息头，P-CSCF会检查该消息头中的URI是否是发送方用户当前已注册的公共用户身份。如查检查通过，P-CSCF就会用P-Asserted-Identity消息头来替换P-Preferred-Identity消息头，但内容是相同的。如果P-Preferred-Identity消息头中不包含已注册的公共用户身份，P-CSCF会用P-Asserted-Identity消息头来替换P-Preferred-Identity消息头，但内容为该用户的默认公共用户身份。

INVITEsip:Theresa@home2.huSIP/2.0From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>P-Asserted-Identity:<sip:tobias@home1.fr>Privacy:NonePage14主叫方S-CSCF与P-Asserted-Identity收到INVITE请求后，Tobias归属网络的S-CSCF将根据P-Asserted-Identity消息头中的信息把他识别出来。S-CSCF还会针对该消息头中的公共用户身份，来检查认证和注册状态。应用服务器AS也可以将这个消息头作为身份识别甚至认证的依据。Tobias的S-CSCF可以在P-Asserted-Identity消息头中增加一个附加的URI，本例中它在消息头中增加了Tobias的电话统一资源定位符：

INVITEsip:Theresa@home2.huSIP/2.0From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>P-Asserted-Identity:<sip:tobias@home1.fr>，<tel:+44123456789>Privacy:NonePage15主叫方S-CSCF与P-Asserted-IdentityTobias归属网络S-CSCF将请求转发到Theresa的归属网络之前，它还要检查该网络是否位于其信任域之内。如果该S-CSCF与Theresa的归属网络不处于相同的信任域，只要Privacy消息头设置为”id”，那么S-CSCF会从请求中删除P-Asserted-Identity消息头。在本例中，我们假设两个网络具有信任关系，该消息头可以继续转发。Page16被叫一侧的P-Asserted-IdentityThereas的P-CSCF需要检查请求中的Privacy，如果它的值没有设置为”id”，P-CSCF就可以将P-Asserted-Identity消息头转发给TheresaUE。Page17被叫用户身份标识Tobias发出的INVITE消息，其第一行，就是请求URI。INVITEsip:theresa@home2.huSIP/2.0请求URI被设置为该请求的最终目的地，即Theresa的SIPURI。SIP和IMS路由会使用该URI。该URI同时还用于在Theresa的归属网络中标识她为被叫用户。Theresa的S-CSCF会检查这个公共用户身份目前是否已经完成注册并通过认证。如果Theresa现在还没有注册这个公共用户身份，S-CSCF将会对INVITE请求返回一个404（未发现）响应，宣布呼叫失败，或者将INVITE请求前转到Theresa的语音邮箱。Page18请求URI和P-Called-Party-ID当TheresaS-CSCF将请求转发给被叫方的P-CSCF时，S-CSCF会用Theresa已注册的联系地址覆盖请求URI。Theresa不能信任请求中的To的消息头，因为主叫方可以将其设置为任意值。为了不丢失Tobias呼叫Theresa时所使用的公共用户身份，S-CSCF在使用已注册的联系地址覆盖请求URI的同时，还在INVITE请求中增加P-Called-Party-ID消息头。P-Called-Party-ID消息头中包含了请求URI中的那个公共用户身份。

INVITEsip:[5555::5:6:7:8]:1006SIP/2.0P-Called-Party-ID:sip:theresa@home2.huPage19被叫方设置P-Asserted-Identity消息头收到INVITE请求后，TheresaUE在对INVITE请求的第一个183（会话进行中）响应中包含P-Preferred-Identity消息头，其中会包含Theresa的公共用户身份中的某一个。

SIP/2.0183SessioninProcessFrom:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>;tag=schwester

P-Preferred-Identity:<sip:theresa@home2.hu>Privacy:NonePage20被叫方设置P-Asserted-Identity消息头Theresa的P-CSCF会执行与前文TobiasP-CSCF所作的相同的检查，并将P-Preferred-Identity消息头更换为P-Asserted-Identity消息头。

SIP/2.0183SessioninProcessFrom:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>;tag=schwester

P-Asserted-Identity:<sip:theresa@home2.hu>Privacy:NonePage21目录呼叫IMS多媒体电话会话1.1主叫和被叫身份标识1.2路由1.3媒体协商1.4资源预留1.5会话的释放1.6IMS会话建立过程的替代方案Page22目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page23概述TobiasUE发送初始INVITE请求给Theresa，其结果是，建立了一个SIP对话，并通过它发送若干后续的请求，如ACK、PRACK、UPDATE和BYE。TobiasUE发送INVITE请求时并不知道如何才能达到Theresa的UE，它所能提供的所有信息仅包括：

▪INVITE请求的最终目的地：Theresa的SIPURI

▪P-CSCF地址：即TobiasUE的出站代理

▪S-CSCF地址Page24会话、对话、事务和分支会话描述了两个用户之间的媒体连接。SIP对话是两个UE之间用于建立、更改和释放媒体会话的信令关系。对话首先通过INVITE请求建立起来，并且在与相关的会话保持活跃期间一直存在。每个SIP对话通过SIP请求中的Call-ID消息头的值，以及To和From消息头中的标签来标识。From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>;tag=schwester

Call-ID:apb03a0s09dkjdfgikj49555Tobias和Theresa间多媒体会话的SIP对话起始于INVITE请求，并终止于对BYE请求的200响应。Page25会话、对话、事务和分支一个SIP事务由一个SIP请求和所有对它的响应构成。为建立会话，TobiasUE发送INVITE请求给TheresaUE。首先，它会收到P-CSCF对该请求的100（尝试中）响应。之后，TheresaUE返回一个183（会话进行中）、180（振铃中），并最终给出一个200响应。所有这5个消息属于同一个事务，并具有相同的Cseq值。From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>;tag=schwester

Call-ID:apb03a0s09dkjdfgikj49555Cseq:1112INVITE来自TobiasUE的每个后续请求都具有比前一个请求更高的CSseq。Page26会话、对话、事务和分支每个实体，包括UE和CSCF，都基于分支（branch）参数把收到的响应与发出的请求关联起来。Branch参数是作为Via消息头的参数而添加的。

INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctb这个branch参数在P-CSCF处标识了INVITE事务。它的构造是通过请求中的To和From消息头的标签、Call-ID、Cseq值以及Via消息头中的branch参数来完成的。Page27会话流程会话S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF2主叫被叫1.INVITE信令媒体HSSAS1AS2sip:tobias@home1.frSip:theresa@home2.huPage28从TobiasUE到P-CSCFTobiasUE将在初始的INVITE请求中包含如下与路由相关的消息头：INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:[5555::a:b:c:d]:7531;lr>Route:<sip:orig@scscf1.home1.fr;lr>Contact:<sip:[5555::1:2:3:4]:1357该请求的目的地是Theresa的SIPURI。Page29从TobiasUE到P-CSCF该Contact消息头中可以包含许多额外的参数，例如：

▪UE支持的被叫用户能力，如视频和音频

▪UE支持的IMS通信服务标识

▪对压缩的支持等等

Contact:<sip:[5555::1:2:3:4]:1357;comp=sigcomp>;audio;video;mobility;methods=“INVITE,BYE,ACK,OPTIONS,CANCEL,NOTIFY,MESSAGE,PRACK,UPDATE”;g.3gpp.icsi_ref=“urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel”Page30会话流程会话S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF2主叫被叫1.INVITE信令媒体HSSAS1AS22.INVITESip:tobias@home1.frsip:theresa@home2.huPage31从Tobias的P-CSCF到S-CSCF当接收到消息时，P-CSCF会：

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

▪

检查该请求包含的路由信息是否与注册过程中所保存的进一步路由信息相一致

▪在Via消息头的顶端填入自己的地址

▪添加第一个Record-Route消息头，并在其中填写自已的地址完成这些之后，P-CSCF再次将分组路由到Route消息头最顶端的地址。

INVITEsip:Theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

Record-Route:<sip:pcscf1.visited1.fi;lr>Route:<sip:orig@scscf1.home1.fr;lr>Contact:<sip:[5555::1:2:3:4]:1357Page32会话流程会话S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF2主叫被叫1.INVITE信令媒体HSSAS1AS22.INVITE3.INVITEsip:tobias@home1.frsip:theresa@home2.huPage33会话流程S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE会话主叫被叫信令媒体sip:tobias@home1.frsip:theresa@home2.huPage34从Tobias的S-CSCF到Theresa归属网络Tobias的S-CSCF把自已的地址从Route消息头的顶端除去，之后，Route消息头就空了，可以被删除。S-CSCF将自己的地址放在Record-Route和Via消息头的顶端。S-CSCF要执行服务提供过程（此过程在后面讨论）。S-CSCF要进一步转发该请求的消息，但是，没有Route消息头来指示下一跳的地址。S-CSCF取出请求URI中的Theresa的公共用户身份的域名部分，并且通过DNS找到Theresa归属网络的一个或多个I-CSCF的地址，它从中选取一个，并将请求转发过去。Page35从Tobias的S-CSCF到Theresa归属网络当S-CSCF知道这个I-CSCF可以作为宽松路由器时，它惟一能做的就是将I-CSCF地址放入Route消息头。但在本例中，S-CSCF和I-CSCF在不同的网络中，因此假设S-CSCF无法知道I-CSCF的能力，因此它通过UDP包将初始INVITE请求发往I-CSCF地址。INVITEsip:Theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::1:2:3:4]:1357Page36会话流程S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE6.INVITE会话主叫被叫信令媒体sip:tobias@home1.frsip:theresa@home2.huPage37从I-CSCF到Theresa的S-CSCF现在Theresa归属网络的I-CSCF需要找到为Theresa分配的S-CSCF地址。为用户所分配的S-CSCF的信息存储在HSS中。网络中可能同时存在多个HSS，I-CSCF首先需要查询订购关系定位功能（SLF）来找到保存Theresa数据的HSS。为简单起见，我们假定在网络中仅有一个可用的HSS，并且它的地址已在I-CSCF中配置好了。Page38从I-CSCF到Theresa的S-CSCFI-CSCF经由Cx接口向HSS发送一条Diameter位置请求消息，以此来执行用户位置查询，该查询包含如下信息：

▪Theresa的公共用户身份：theresa@home2.hu

▪I-CSCF的地址：icscf1.home2.hu

▪I-CSCF所在运营商网络的域名：home2.hu

▪SLF/HSS的归属域：home2.hu

▪HSS的地址HSS根据SIPURI，即sip:theresa@home2.hu，确定它属于Theresa，并且用于theresa注册的S-CSCF地址为scscf2.home2.hu。HSS向I-CSCF返回一条Diameter位置信息应答，该应答包含以下信息：

▪

查询成功标志

▪

为theresa分配的S-CSCF地址：scscf2.home2.huPage39从I-CSCF到Theresa的S-CSCF路由头域处理

▪I-CSCF把自己的地址放到Via行顶部

▪I-CSCF不会把自己的地址放在Record-Route行，因为它不需要再收到该对话中的任何后续请求。▪I-CSCF把从HSS获取的S-CSCF地址放在Route行请求消息再次发往Route消息头最顶端的地址，这次是theresa的S-CSCF

NVITEsip:Theresa@home2.huSIP/2.0

Via:SIP/2.0/UDPicscf1.home2.hu;branch=bicthVia:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:scscf2.home2.hu;lr>Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::1:2:3:4]:1357

Page40会话流程S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE6.INVITE7.INVITE会话主叫被叫信令媒体sip:tobias@home1.frsip:theresa@home2.huPage41会话流程S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE6.INVITE7.INVITE7.INVITE7.INVITE8.INVITE会话主叫被叫信令媒体Sip:tobias@home1.frsip:theresa@home2.huPage42会话S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE6.INVITE7.INVITE7.INVITE7.INVITE8.INVITE9.INVITE会话主叫被叫信令媒体sip:tobias@home1.frsip:theresa@home2.huPage43从Theresa的S-CSCF到P-CSCFTheresa的S-CSCF收到INVITE请求。同样，它也从Route消息头删除自已地址的条目，并把自已的地址放入Via和Record-Route列表。为Theresa执行服务提供过程（此过程后面讨论）。然后，S-CSCF就执行注册服务器功能。在Theresa的注册过程中，S-CSCF从P-CSCF处收到了Path消息头。它现在必须把Path消息头中的条目放到INVITE请求的Route消息头中去。因此，S-CSCF增加了一个新的Route消息头，并填入P-CSCF地址，由于现在这就是最顶端的条目，因此该请求会立刻发往该地址。

Page44从Theresa的S-CSCF到P-CSCFTheresa的S-CSCF发往P-CSCF的消息头如下：

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

Via:SIP/2.0/UDPscscf2.home2.hu;branch=cscthVia:SIP/2.0/UDPicscf1.home2.hu;branch=bicthVia:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:pcscf2.home2.hu;lr>

Record-Route:<sip:scscf2.home2.hu;lr>Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::1:2:3:4]:1357

Page45会话流程S-CSCF1I-CSCF2P-CSCF2P-CSCF1S-CSCF21.INVITEHSSAS1AS22.INVITE3.INVITE4.INVITE5.INVITE6.INVITE7.INVITE7.INVITE7.INVITE8.INVITE9.INVITE10.INVITE会话主叫被叫信令媒体sip:tobias@home1.frsip:theresa@home2.huPage46从P-CSCF到Theresa的UEP-CSCF收到请求后，它会按照惯例操作：将整个Route消息头删除，并将自已的地址放入到Record-Route和Via消息头中，并将请求发往最终目的地，也就是请求URI中指示的——TheresaUE。NVITEsip:[5555::5:6:7:8]:1006SIP/2.0

Via:SIP/2.0/UDPpcscf2.home2.hu:1511;branch=dpcthVia:SIP/2.0/UDPscscf2.home2.hu;branch=cscthVia:SIP/2.0/UDPicscf1.home2.hu;branch=bicthVia:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRecord-Route:<sip:pcscf2.home2.hu:1511;lr>

Record-Route:<sip:scscf2.home2.hu;lr>Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::1:2:3:4]:1357

Page47目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page48从Theresa

UE到P-CSCFTheresa的UE收到INVITE请求后，它保存所收到的Contact值和Record-Route消息头列表。TheresaUE根据预置条件对收到的INVITE请求生成一个响应消息：183（会话进行中）响应。UE在Contact消息头中填入自已的IP地址，指示它希望用此地址接收对话中的后续请求。INVITE请求中的Record-Route和Via消息头也会出现在响应中。TheresaUE将该响应发送到Via消息头最顶端的地址和端口号，即P-CSCF的受保护的端口。

Page49从Theresa

UE到P-CSCFTheresaUE对该INVITE请求而发出的所有的其他响应也都会包含与183响应中相同的Via消息头。SIP/2.0183SessioninProgressVia:SIP/2.0/UDPpcscf2.home2.hu:1511;branch=dpcthVia:SIP/2.0/UDPscscf2.home2.hu;branch=cscthVia:SIP/2.0/UDPicscf1.home2.hu;branch=bicthVia:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

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

Record-Route:<sip:scscf2.home2.hu;lr>Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::5:6:7:8]:1006

Page50从Theresa的P-CSCF到Tobias的P-CSCFP-CSCF通过Via消息头中自已设定的branch参数来标识该响应属于哪个INVITE事务。它会按照如下的方式来处理183响应中的路由信息：

▪它把自已的地址从Via消息头删除

▪重写自已的Record-Route条目

▪

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

Page51从Theresa的P-CSCF到Tobias的P-CSCFP-CSCF向S-CSCF发送的183消息如下：SIP/2.0183SessioninProgressVia:SIP/2.0/UDPscscf2.home2.hu;branch=cscthVia:SIP/2.0/UDPicscf1.home2.hu;branch=bicthVia:SIP/2.0/UDPscscf1.home1.fr;branch=asctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia: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:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::5:6:7:8]:1006

Page52从Theresa的P-CSCF到Tobias的P-CSCF从现在开始，直到达到Tobias的P-CSCF之前，响应消息不会再发生任何重要改变：每一跳仅仅是删掉它自已的Via条目，并把消息发往Via中的下一个条目。Record-Route保持不变。

Page53从Tobias的P-CSCF到他的UE收到183响应后，TobiasP-CSCF执行与TheresaP-CSCF相类似的操作。它也重写Record-Route消息头中关于它自已的条目，但是它不会删除受保护的端口，而是增加该端口。其结果就是强制TobiasUE必须通过已建立的IPSECSA来发送所有后续的请求。P-CSCF根据Via消息头来转发响应，它会将该响应发往TobiasUE的受保护的服务器端口1357，即通过IpsecSA发送：SIP/2.0183SessioninProgressVia: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:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi:7351;lr>Contact:<sip:[5555::5:6:7:8]:1006

Page54从Tobias的P-CSCF到他的UETobias的UE在收到响应消息后，会：

▪从Contact消息头中读出TheresaUE的IP地址并保存起来。

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

Page55目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page56重传INVITE请求和100（尝试）响应发出INVITE请求之后，TobiasUE会等候来自TheresaUE的响应。它会等候计时器T1超时。每次超时后，它会重传一个INVITE请求，直到收到该对话的响应。如果128s之后还不能收响应，它就告诉TobiasUE这次会话建立失败。在漫游的过程中，INVITE请求要经过各地的多个CSCF，因此它到达TheresaUE可能已经超过T1了，而且后者还要生成183响应并沿原路长途跋涉返回TobiasUE。为了避免TobiasUE频繁地重发送INVITE请求，P-CSCF在收到INVITE请求后，会发回一个100（尝试）响应。这意味着现在开始P-CSCF会负责上述重传工作。

Page57重传INVITE请求和100（尝试）响应沿途的所有感知呼叫状态的其它SIP代理都会发送出相同的100（尝试）响应，该响应总是终止于最后一个负责进行重传的SIP代理。

Page58目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page59同一对话中后续请求的路由当两个UE其中之一需要发起这一对话中的后续请求时，它将所存储的Record-route条目复制到新的请求的Route消息头中，并把对端的UE的IP地址放入请求URI中。这个请求会严格按照Route消息头中的条目路由到对端UE。途中经过的每个CSCF都把自已的地址放在Via消息头中，以便得到对于该请求的响应。I-CSCF会收到后续的请求吗？

Page60同一对话中后续请求的路由TobiasUE要返回一个PRACK请求来确认已收到的183响应：PRACKsip:[5555::5:6:7:8]:1006SIP/2.0Via:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb

Route:<sip:pcscf1.visited1.fi:7531;lr>

Route:<sip:scscf1.home1.fr;lr>Route:<sip:scscf2.home2.hu;lr>Route:<sip:pcscf2.home2.hu;lr>该PRACK请求会被按照如下方式路由：

▪根据Route消息头，到达TobiasP-CSCF和S-CSCF，之后是TheresaS-CSCF和P-CSCF。

▪TheresaP-CSCF根据请求URI地址，通过IpsecSA,，发往TheresaUE。请求URI取自TobiasUE从183响应的Contact消息头。

Page61同一对话中后续请求的路由TheresaUE将对PRACK请求发出一个200响应，并包含下列路由信息：SIP/2.0200OKVia:SIP/2.0/UDPscscf2.home2.hu;branch=c2scthVia:SIP/2.0/UDPscscf1.home1.fr;branch=a2sctbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=92pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=82uetb该响应根据Via消息头中的条目路由回去。不再返回Record-Route消息头。

Page62目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page63S-CSCF上的过滤准则评估当Tobias或Theresa的S-CSCF收到一个初始请求时，它会逐个检查这些过滤准则。如果匹配了其中一个或多个，它会把请求发送给准则中指出的AS。本例中，我们假设有三个AS为来自Tobias的请求设置了过滤准则，Tobias的S-CSCF会针对INVITE请求中收到的信息来逐个检查这些过滤准则。Page64S-CSCF上的过滤准则评估Tobias的S-CSCF收到的INVITE请求消息如下：

INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:orig@scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Contact:<sip:[5555::1:2:3:4]:1357From:“YourBrother”<sip:tobi@>;tag=veliTo:“MybelovedSister”<sip:Theresa@>P-Asserted-Identity:<sip:tobias@home1.fr>过滤准则1不匹配。过滤准则2获得匹配。

Page65从S-CSCF到电话应用服务器AS现在，S-CSCF需要将INVITE请求发往过滤准则2中指示的AS，在本例中指的是电话应用服务器（TAS)。S-CSCF还需要采取措施，来应付当AS完成操作后自已还会再次收该INVITE请求，因为S-CSCF还要检查过滤准则3，以便将请求发往Theresa的归属网络。为了达到这个目的，S-CSCF增加一系列与路由有关的消息头：

▪将它自已的地址放入Route消息头最顶端。

▪将AS的地址放入Route消息头的最顶端，以便将AS作为INVITE消息头的下一跳。

▪将它自已的地址放入Record-Route消息头最顶端，以便后续的请求都会经过它。

▪将它自已的地址放入Via消息头的最顶端，以便它可以收到该请求的所有响应。

Page66从S-CSCF到电话应用服务器ASS-CSCF还将Route消息头自已的条目中添加一个对话标识，对话标识特定于具体的实现方式。它将此对话标识设置成某个值，使得它可以识别为此INVITE请求而生成的对话。INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDPscscf1.home1.fr;branch=9sc2as2tbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:as2.home1.fr;lr>Route:<sip:scscf1.home1.fr;lr>;dia-ID=6574839201Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Page67从S-CSCF到电话应用服务器AS到应用服务器AS的路由：Page68从AS返回S-CSCF收到INVITE请求后，AS会：

▪

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

▪

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

▪可能根据需要更改请求消息

▪把自已的地址放入Via列表的顶端

▪决定是否希望接收此对话的后续请求，如果希望，它将自已的地址放在Record-Route列表的顶端

▪根据Route消息头中最顶端的地址将INVITE请求路由回S-CSCFPage69从AS返回S-CSCF由AS返回的INVITE消息如下：INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDP

as2.home1.fr;branch=vas2tbVia:SIP/2.0/UDPscscf1.home1.fr;branch=9sc2as2tbVia:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctbVia:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetbRoute:<sip:scscf1.home1.fr;lr>;dia-ID=6574839201Record-Route:<sip:as2.home1.fr;lr>Record-Route:<sip:scscf1.home1.fr;lr>Record-Route:<sip:pcscf1.visited1.fi;lr>Page70S-CSCF继续评估其它过滤准则当再次收到INVITE请求后，S-CSCF检查过滤准则3，因为SIP方法不是SUBSCRIBE，所以过滤准则3不匹配。因此，S-CSCF继续执行正常路由过程：即把INVITE请求发往Theresa归属网络的I-CSCF。

Page71目录1.2IMS路由1.2.1INVITE1.2.21831.2.3重传INVITE请求和100响应1.2.4同一对话中的后续请求1.2.5与AS间的路由1.2.6IMS通信服务标识Page72概述当Tobias呼叫Theresa的时候，利用的是他手机上的多媒体电话应用。Tobias希望：

▪

按照IMS网络中的IMS多媒体电话规范来处理该呼叫。

▪倾向于让呼叫到达Theresa支持IMS多媒体电话业务的那个终端。为实现这个目的，IMS使用了两个独立的扩展：

▪定义了P-Preferred-Service和P-Asserted-Service消息头，用来标识IMS网络中的特定通信业务。

▪定义了主叫方偏好，它允许主叫方终端根据被叫方终端是否支持该通信业务来选择被叫方的终端设备。

Page73IMS通信服务标识和服务提供在发送初始SIPINVITE请求时，Tobias的UE通过P-Preferred-Service消息头中指明的ICSI来识别IMS多媒体电话通信服务：

INVITEsip:theresa@home2.huSIP/2.0P-Preferred-Service:urn:urn-xxx:3gpp-service-ims.icis.mmtel一旦SIPINVITE请求到达了Tobias的S-CSCF，它将检查是否已经订阅了相关的服务。S-CSCF从HSS中下载的Tobias的用户信息表明他已经订阅了多媒体电话通信服务。S-CSCF将通过使用P-Asserted-Service消息头代替P-Preferred-Service消息头，来声明所指定的ICSI。

INVITEsip:theresa@home2.huSIP/2.0P-Asserted-Service:urn:urn-xxx:3gpp-service-ims.icis.mmtelPage74IMS通信服务标识和服务提供S-CSCF开始应用Tobias用户配置信息中的过滤准则。如果过滤准则中存在过滤准则触发器的服务触发点（STP）P-Asserted-Service，且它所对应的值为urn:urn-xxx:3gpp-service-ims.icis.mmtel。则由于SIPINVITE请求匹配该SPT，该请求被发送至相关的应用服务器，在本例中是电话应用服务器（TAS）。TAS现在开始执行应用于本呼叫的所有附加服务，然后将该请求发回至S-CSCF。在完成过滤准则评估后，Tobias的S-CSCF将SIPINVITE请求转发至Theresa的IMS网络。Theresa的S-CSCF触发器在发现P-Asserted-service消息头中有多媒体电服务出现时，也会将请求路由至Theresa的TAS.P-Asserted-Service消息头在信任域的边界被移除。

Page75基本的主叫方偏好处理我们假定Theresa已经为三个支持不同功能的电话进行了注册。这就意味着Theresa的S-CSCF当前为公共用户身份，sip:theresa@home2.hu的用户保留着三种绑定：

Page76基本的主叫方偏好处理电话B1，移动电话：

▪Contact地址：[5555::5:6:7:8]:1006

▪

特性标签（被叫方能力）：;audio;video;g.3gpp.icso_ref=“urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel电话B2，办公室电话

▪Contact地址：[5555::97：98：99：00]:1010

▪

特性标签（被叫方能力）：;audio;g.3gpp.icso_ref=“urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel电话B3，家庭电话：

▪Contact地址：[5555::55：44：33：22]:1010

▪

特性标签（被叫方能力）：;audio;video=false

Page77基本的主叫方偏好处理当发送初始的SIPINVITE请求后，Tobias的电话表求更希望能连接到支持音频、视频、以及IMS多媒体电话通信服务的电话。Tobias的这种愿望在Accept-Contact消息头中表达出来，该消息头被添加到SIPINVITE请求当中。

INVITEsip:theresa@home2.huSIP/2.0P-Preferred-Service:urn:urn-xxx:3gpp-service-ims.icis.mmtelAccept-Contact:;audio;video;g.3gpp.icso_ref=“urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtelContact:sip:[5555::1:2:3:4]:1357;audio;video;mobility;methods=“INVITE,BYE,ACK,OPTIONS,CANCEL,NOTIFY,MESSAGE,RPACK,UPDATE”;g.3gpp.icso_ref=“urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel,urn%3Arun-xxx%3Aother-vendor-service-ims.icsi.ongame”

Page78基本的主叫方偏好处理我们看到发起方UE也需要在Contact消息头中添加它自已所支持的特性标签。在Accept-Contact消息头中表达出呼叫方想要连接被叫方中支持指明功能的终端的意愿。当Theresa的S-CSCF接收到SIPINVITE请求后，它将验证需要向哪个终端发送SIPINVITE请求，按照如下的简化方式进行：

▪电话B1将会立即接收到SIPINVITE请求，因为它是用Accept-Contact消息头中指明的所有三个特性标签来注册的。

▪

电话B2将会立即接收到SIPINVITE请求，它仅注册了Accept-Contact消息头中指明的两个标签，而没有显式注册“video”特性标签。

但是因为电话B2没有明确地指明它不支持“video”，则假设它有这个功能。

▪

电话B3仅在电话B1和B2都不接受该呼叫或者由于其它的原因连接失败的时候，才会接收该呼叫。尽管电话B3指明“video=false”，它依然可以接收该呼叫，这是因为在Accept-Contact消息头中指明的特性标签仅仅是意愿，也就是说，它们并不是被叫终端的强制要求的功能。

Page79目录呼叫IMS多媒体电话会话1.1主叫和被叫身份标识1.2路由1.3媒体协商1.4资源预留1.5会话的释放1.6IMS会话建立过程的替代方案Page80目录1.3IMS媒体协商1.3.1概述1.3.2临时响应的可靠性1.3.3IMS中的SDP提议/应答Page81概述

媒体协商和对预制条件的处理（Procondition)在IMS中是两个密切相关的概念。两者都是与SDP中会话参数的描述更为相关。然而他们对于SDP信令也具有重要的影响。在本节中给出一个正常的会话建立过程，该会话是在两个经由GPRS接入技术连接到IMS的电话之间建立的。这仅是众多场景的其中一种，基于接入网的特性，以及资源预留情况和电话支持功能的不同，后面将给出不同形式的会话建立过程。Page82概述

通过媒体协商，两个UE之间，就本次会话中使用的媒体组合以及各类媒体使用的编解码方案达成一致。为此，使用了SDP提议/应答机制。在IMS中，该机制基本上按照以下方式工作：TobiasTheresaINVITE第一次SDP提议：所有希望的媒体和编解码方案183（SessionProgress)第一次SDP应答：支持的媒体