IMS多媒體電話會話舉例

IMS多媒體電話會話舉例Page1培訓目標學完本課程后，您應該能：描述IMS域內及與CS域互通呼叫流程中的信令處理。列出INVITE請求及其臨時響應的關鍵頭域。完成呼叫流程中的相關配置和進行基本故障定位P-CSCF功能(會話期間)會話期間P-CSCF處理過程判斷用戶是否合法判斷是否是緊急呼叫進行承載控制進行接入網判斷頭域處理，計費處理呼叫轉發(fā)到UE或S-CSCFI-CSCF功能(會話期間)會話期間I-CSCF處理過程通過查詢HSS獲取為用戶服務的S-CSCF的地址。進行拓撲隱藏S-CSCF功能(會話期間)會話期間S-CSCF處理過程頭域處理路由處理緊急呼叫處理用戶身份確認計費處理業(yè)務觸發(fā)處理HSS功能(會話期間)會話期間HSS處理過程支持LIR查詢，給I-CSCF返回給被叫用戶服務的S-CSCFPage6目錄IMS多媒體電話會話案例分析Page7目錄呼叫IMS多媒體電話會話1.1主叫和被叫身份標識1.2路由1.3媒體協(xié)商1.4資源預留1.5會話的釋放1.6IMS會話建立過程的替代方案Page8多媒體電話會話舉例本節(jié)將介紹一個IMS多媒體電話會話的例子：

?該會話發(fā)生在Tobias和Theresa之間，兩者都在各自的歸屬網絡中注冊，并且目前都在外地漫游。

?IMS利用SIP和SDP來確保Tobias和Theresa之間相互交談，并且在手機屏幕上能看到對方。Page9概述提問：注冊過程中，IMS用戶如何得知他能用哪些公共用戶身份，以及哪些身份標識是已經注冊過的？在每種IMS對話中（本例中為INVITE對話），有兩個身份標識是最基本的：

?請求中需要給出已注冊并已認證的主叫用戶（Tobias）的公共用戶身份，以便歸屬網絡識別出該用戶，并且判斷其對于擴展服務的執(zhí)行權限。

?

請求中需要給出已注冊并已認證的被叫用戶（Theresa）的公共用戶身份，以便找到該用戶并為其提供服務。Page10From和To消息頭TobiasUE發(fā)給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可以設置為發(fā)送者所希望的任何值在除REGISTER之外的任何請求消息中，這兩個消息頭的值都絲毫不會影響IMS路由和安全過程，它們可以隨意設置。這兩個消息頭中，協(xié)議本身惟一需要的信息就是tag參數(shù)。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發(fā)出的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是否是發(fā)送方用戶當前已注冊的公共用戶身份。如查檢查通過，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還會針對該消息頭中的公共用戶身份，來檢查認證和注冊狀態(tài)。應用服務器AS也可以將這個消息頭作為身份識別甚至認證的依據。Tobias的S-CSCF可以在P-Asserted-Identity消息頭中增加一個附加的URI，本例中它在消息頭中增加了Tobias的電話統(tǒng)一資源定位符：

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將請求轉發(fā)到Theresa的歸屬網絡之前，它還要檢查該網絡是否位于其信任域之內。如果該S-CSCF與Theresa的歸屬網絡不處于相同的信任域，只要Privacy消息頭設置為”id”，那么S-CSCF會從請求中刪除P-Asserted-Identity消息頭。在本例中，我們假設兩個網絡具有信任關系，該消息頭可以繼續(xù)轉發(fā)。Page16被叫一側的P-Asserted-IdentityThereas的P-CSCF需要檢查請求中的Privacy，如果它的值沒有設置為”id”，P-CSCF就可以將P-Asserted-Identity消息頭轉發(fā)給TheresaUE。Page17被叫用戶身份標識Tobias發(fā)出的INVITE消息，其第一行，就是請求URI。INVITEsip:theresa@home2.huSIP/2.0請求URI被設置為該請求的最終目的地，即Theresa的SIPURI。SIP和IMS路由會使用該URI。該URI同時還用于在Theresa的歸屬網絡中標識她為被叫用戶。Theresa的S-CSCF會檢查這個公共用戶身份目前是否已經完成注冊并通過認證。如果Theresa現(xiàn)在還沒有注冊這個公共用戶身份，S-CSCF將會對INVITE請求返回一個404（未發(fā)現(xiàn)）響應，宣布呼叫失敗，或者將INVITE請求前轉到Theresa的語音郵箱。Page18請求URI和P-Called-Party-ID當TheresaS-CSCF將請求轉發(fā)給被叫方的P-CSCF時，S-CSCF會用Theresa已注冊的聯(lián)系地址覆蓋請求URI。Theresa不能信任請求中的To的消息頭，因為主叫方可以將其設置為任意值。為了不丟失Tobias呼叫Theresa時所使用的公共用戶身份，S-CSCF在使用已注冊的聯(lián)系地址覆蓋請求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會執(zhí)行與前文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媒體協(xié)商1.4資源預留1.5會話的釋放1.6IMS會話建立過程的替代方案Page22目錄1.2IMS路由1.2.1INVITE1.2.21831.2.3重傳INVITE請求和100響應1.2.4同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page23概述TobiasUE發(fā)送初始INVITE請求給Theresa，其結果是，建立了一個SIP對話，并通過它發(fā)送若干后續(xù)的請求，如ACK、PRACK、UPDATE和BYE。TobiasUE發(fā)送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發(fā)送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的每個后續(xù)請求都具有比前一個請求更高的CSseq。Page26會話、對話、事務和分支每個實體，包括UE和CSCF，都基于分支（branch）參數(shù)把收到的響應與發(fā)出的請求關聯(lián)起來。Branch參數(shù)是作為Via消息頭的參數(shù)而添加的。

INVITEsip:Theresa@home2.huSIP/2.0Via:SIP/2.0/UDPpcscf1.visited1.fi;branch=9pctb這個branch參數(shù)在P-CSCF處標識了INVITE事務。它的構造是通過請求中的To和From消息頭的標簽、Call-ID、Cseq值以及Via消息頭中的branch參數(shù)來完成的。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消息頭中可以包含許多額外的參數(shù)，例如：

?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要執(zhí)行服務提供過程（此過程在后面討論）。S-CSCF要進一步轉發(fā)該請求的消息，但是，沒有Route消息頭來指示下一跳的地址。S-CSCF取出請求URI中的Theresa的公共用戶身份的域名部分，并且通過DNS找到Theresa歸屬網絡的一個或多個I-CSCF的地址，它從中選取一個，并將請求轉發(fā)過去。Page35從Tobias的S-CSCF到Theresa歸屬網絡當S-CSCF知道這個I-CSCF可以作為寬松路由器時，它惟一能做的就是將I-CSCF地址放入Route消息頭。但在本例中，S-CSCF和I-CSCF在不同的網絡中，因此假設S-CSCF無法知道I-CSCF的能力，因此它通過UDP包將初始INVITE請求發(fā)往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現(xiàn)在Theresa歸屬網絡的I-CSCF需要找到為Theresa分配的S-CSCF地址。為用戶所分配的S-CSCF的信息存儲在HSS中。網絡中可能同時存在多個HSS，I-CSCF首先需要查詢訂購關系定位功能（SLF）來找到保存Theresa數(shù)據的HSS。為簡單起見，我們假定在網絡中僅有一個可用的HSS，并且它的地址已在I-CSCF中配置好了。Page38從I-CSCF到Theresa的S-CSCFI-CSCF經由Cx接口向HSS發(fā)送一條Diameter位置請求消息，以此來執(zhí)行用戶位置查詢，該查詢包含如下信息：

?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行，因為它不需要再收到該對話中的任何后續(xù)請求。?I-CSCF把從HSS獲取的S-CSCF地址放在Route行請求消息再次發(fā)往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執(zhí)行服務提供過程（此過程后面討論）。然后，S-CSCF就執(zhí)行注冊服務器功能。在Theresa的注冊過程中，S-CSCF從P-CSCF處收到了Path消息頭。它現(xiàn)在必須把Path消息頭中的條目放到INVITE請求的Route消息頭中去。因此，S-CSCF增加了一個新的Route消息頭，并填入P-CSCF地址，由于現(xiàn)在這就是最頂端的條目，因此該請求會立刻發(fā)往該地址。

Page44從Theresa的S-CSCF到P-CSCFTheresa的S-CSCF發(fā)往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消息頭中，并將請求發(fā)往最終目的地，也就是請求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同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page48從Theresa

UE到P-CSCFTheresa的UE收到INVITE請求后，它保存所收到的Contact值和Record-Route消息頭列表。TheresaUE根據預置條件對收到的INVITE請求生成一個響應消息：183（會話進行中）響應。UE在Contact消息頭中填入自已的IP地址，指示它希望用此地址接收對話中的后續(xù)請求。INVITE請求中的Record-Route和Via消息頭也會出現(xiàn)在響應中。TheresaUE將該響應發(fā)送到Via消息頭最頂端的地址和端口號，即P-CSCF的受保護的端口。

Page49從Theresa

UE到P-CSCFTheresaUE對該INVITE請求而發(fā)出的所有的其他響應也都會包含與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參數(shù)來標識該響應屬于哪個INVITE事務。它會按照如下的方式來處理183響應中的路由信息：

?它把自已的地址從Via消息頭刪除

?重寫自已的Record-Route條目

?

它將請求發(fā)往Via消息頭最頂端的地址，即Theresa歸屬網絡的S-CSCF

Page51從Theresa的P-CSCF到Tobias的P-CSCFP-CSCF向S-CSCF發(fā)送的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從現(xiàn)在開始，直到達到Tobias的P-CSCF之前，響應消息不會再發(fā)生任何重要改變：每一跳僅僅是刪掉它自已的Via條目，并把消息發(fā)往Via中的下一個條目。Record-Route保持不變。

Page53從Tobias的P-CSCF到他的UE收到183響應后，TobiasP-CSCF執(zhí)行與TheresaP-CSCF相類似的操作。它也重寫Record-Route消息頭中關于它自已的條目，但是它不會刪除受保護的端口，而是增加該端口。其結果就是強制TobiasUE必須通過已建立的IPSECSA來發(fā)送所有后續(xù)的請求。P-CSCF根據Via消息頭來轉發(fā)響應，它會將該響應發(fā)往TobiasUE的受保護的服務器端口1357，即通過IpsecSA發(fā)送：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同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page56重傳INVITE請求和100（嘗試）響應發(fā)出INVITE請求之后，TobiasUE會等候來自TheresaUE的響應。它會等候計時器T1超時。每次超時后，它會重傳一個INVITE請求，直到收到該對話的響應。如果128s之后還不能收響應，它就告訴TobiasUE這次會話建立失敗。在漫游的過程中，INVITE請求要經過各地的多個CSCF，因此它到達TheresaUE可能已經超過T1了，而且后者還要生成183響應并沿原路長途跋涉返回TobiasUE。為了避免TobiasUE頻繁地重發(fā)送INVITE請求，P-CSCF在收到INVITE請求后，會發(fā)回一個100（嘗試）響應。這意味著現(xiàn)在開始P-CSCF會負責上述重傳工作。

Page57重傳INVITE請求和100（嘗試）響應沿途的所有感知呼叫狀態(tài)的其它SIP代理都會發(fā)送出相同的100（嘗試）響應，該響應總是終止于最后一個負責進行重傳的SIP代理。

Page58目錄1.2IMS路由1.2.1INVITE1.2.21831.2.3重傳INVITE請求和100響應1.2.4同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page59同一對話中后續(xù)請求的路由當兩個UE其中之一需要發(fā)起這一對話中的后續(xù)請求時，它將所存儲的Record-route條目復制到新的請求的Route消息頭中，并把對端的UE的IP地址放入請求URI中。這個請求會嚴格按照Route消息頭中的條目路由到對端UE。途中經過的每個CSCF都把自已的地址放在Via消息頭中，以便得到對于該請求的響應。I-CSCF會收到后續(xù)的請求嗎？

Page60同一對話中后續(xù)請求的路由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,，發(fā)往TheresaUE。請求URI取自TobiasUE從183響應的Contact消息頭。

Page61同一對話中后續(xù)請求的路由TheresaUE將對PRACK請求發(fā)出一個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同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page63S-CSCF上的過濾準則評估當Tobias或Theresa的S-CSCF收到一個初始請求時，它會逐個檢查這些過濾準則。如果匹配了其中一個或多個，它會把請求發(fā)送給準則中指出的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現(xiàn)在，S-CSCF需要將INVITE請求發(fā)往過濾準則2中指示的AS，在本例中指的是電話應用服務器（TAS)。S-CSCF還需要采取措施，來應付當AS完成操作后自已還會再次收該INVITE請求，因為S-CSCF還要檢查過濾準則3，以便將請求發(fā)往Theresa的歸屬網絡。為了達到這個目的，S-CSCF增加一系列與路由有關的消息頭：

?將它自已的地址放入Route消息頭最頂端。

?將AS的地址放入Route消息頭的最頂端，以便將AS作為INVITE消息頭的下一跳。

?將它自已的地址放入Record-Route消息頭最頂端，以便后續(xù)的請求都會經過它。

?將它自已的地址放入Via消息頭的最頂端，以便它可以收到該請求的所有響應。

Page66從S-CSCF到電話應用服務器ASS-CSCF還將Route消息頭自已的條目中添加一個對話標識，對話標識特定于具體的實現(xiàn)方式。它將此對話標識設置成某個值，使得它可以識別為此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列表的頂端

?決定是否希望接收此對話的后續(xù)請求，如果希望，它將自已的地址放在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繼續(xù)評估其它過濾準則當再次收到INVITE請求后，S-CSCF檢查過濾準則3，因為SIP方法不是SUBSCRIBE，所以過濾準則3不匹配。因此，S-CSCF繼續(xù)執(zhí)行正常路由過程：即把INVITE請求發(fā)往Theresa歸屬網絡的I-CSCF。

Page71目錄1.2IMS路由1.2.1INVITE1.2.21831.2.3重傳INVITE請求和100響應1.2.4同一對話中的后續(xù)請求1.2.5與AS間的路由1.2.6IMS通信服務標識Page72概述當Tobias呼叫Theresa的時候，利用的是他手機上的多媒體電話應用。Tobias希望：

?

按照IMS網絡中的IMS多媒體電話規(guī)范來處理該呼叫。

?傾向于讓呼叫到達Theresa支持IMS多媒體電話業(yè)務的那個終端。為實現(xiàn)這個目的，IMS使用了兩個獨立的擴展：

?定義了P-Preferred-Service和P-Asserted-Service消息頭，用來標識IMS網絡中的特定通信業(yè)務。

?定義了主叫方偏好，它允許主叫方終端根據被叫方終端是否支持該通信業(yè)務來選擇被叫方的終端設備。

Page73IMS通信服務標識和服務提供在發(fā)送初始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用戶配置信息中的過濾準則。如果過濾準則中存在過濾準則觸發(fā)器的服務觸發(fā)點（STP）P-Asserted-Service，且它所對應的值為urn:urn-xxx:3gpp-service-ims.icis.mmtel。則由于SIPINVITE請求匹配該SPT，該請求被發(fā)送至相關的應用服務器，在本例中是電話應用服務器（TAS）。TAS現(xiàn)在開始執(zhí)行應用于本呼叫的所有附加服務，然后將該請求發(fā)回至S-CSCF。在完成過濾準則評估后，Tobias的S-CSCF將SIPINVITE請求轉發(fā)至Theresa的IMS網絡。Theresa的S-CSCF觸發(fā)器在發(fā)現(xiàn)P-Asserted-service消息頭中有多媒體電服務出現(xiàn)時，也會將請求路由至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基本的主叫方偏好處理當發(fā)送初始的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基本的主叫方偏好處理我們看到發(fā)起方UE也需要在Contact消息頭中添加它自已所支持的特性標簽。在Accept-Contact消息頭中表達出呼叫方想要連接被叫方中支持指明功能的終端的意愿。當Theresa的S-CSCF接收到SIPINVITE請求后，它將驗證需要向哪個終端發(fā)送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媒體協(xié)商1.4資源預留1.5會話的釋放1.6IMS會話建立過程的替代方案Page80目錄1.3IMS媒體協(xié)商1.3.1概述1.3.2臨時響應的可靠性1.3.3IMS中的SDP提議/應答Page81概述

媒體協(xié)商和對預制條件的處理（Procondition)在IMS中是兩個密切相關的概念。兩者都是與SDP中會話參數(shù)的描述更為相關。然而他們對于SDP信令也具有重要的影響。在本節(jié)中給出一個正常的會話建立過程，該會話是在兩個經由GPRS接入技術連接到IMS的電話之間建立的。這僅是眾多場景的其中一種，基于接入網的特性，以及資源預留情況和電話支持功能的不同，后面將給出不同形式的會話建立過程。Page82概述

通過媒體協(xié)商，兩個UE之間，就本次會話中使用的媒體組合以及各類媒體使用的編解碼方案達成一致。為此，使用了SDP提議/應答機制。在IMS中，該機制基本上按照以下方式工作：TobiasTheresaINVITE第一次SDP提議：所有希望的媒體和編解碼方案183（SessionProgress)第一次SDP應答：支持的媒體