文/張陽，本文來源于微信公衆号：網優小談（wireless_talk）
VoLTE的被叫信令流程相比主叫信令流程要複雜一點，一般通信系統的被叫信令流程相比主叫信令流程都要複雜一點，因為往往不知道使用者的位置需要進行相應的尋呼尋址，基于IMS架構的VoLTE被叫尋呼流程也是一樣的，往往不知道使用者是處于何種狀态，例如，漫遊狀态、歸屬地、非LTE網絡（UMTS/GSM/PSTN）等等，雖然涉及到的内容略顯複雜，但是整體信令脈絡是大緻相似的，涉及到的不同狀态，無非就是新增一些網元以及專屬信令流程而已。
縱觀被叫終端分别在漫遊地和歸屬地的信令流程，除了涉及到P-CSCF的位置不同外，沒有什麼太大的差別，我們以漫遊地的信令流程入手進行解讀。
1、主叫發送SIP INVITE請求，包含初始SDP，經理主叫流程以及中間流程，最終發送到被叫側的S-CSCF；
2、被叫側S-CSCF校驗服務請求同時觸發服務邏輯單元。這裡基于使用者訂閱的多媒體服務情況，對請求的SDP進行鑒權；
3、S-CSCF根據之前UE注冊時的資訊，将INVITE請求轉發到之前記憶的P-CSCF;
4、如果P-CSCF決定被叫是MPS會話（多媒體優先級會話），P-CSCF擷取對話資訊并且調用動态政策，将擷取的使用者資訊發送PCRF網元。P-CSCF通過之前UE注冊時記憶的UE位址，将INVITE轉發至UE；
下述信令截圖就是INVITE的消息内容，從這裡我們可以看出一些資訊：
(1)主叫與被叫遵從電信URI的格式，即用tel方式進行公共使用者辨別表征，可以看出主叫來電号碼是18407404056，被叫電話号碼是18407404056；
(2)Call-ID:amCa[email protected]zteims,Call-ID是為了對同一使用者的會話進行辨別，是以在對話中同一個使用者的請求和響應中，Call-ID是唯一的，另外對于同一使用者，該Call-ID也應該是全球唯一的辨別符，同時一般Call-ID以一種随機加密的方式（RFC1750）出現，使用該随機加密方式可以保護會話不被非法截獲，同時可以減少Call-ID的沖突，一般call-ID是由随機加密序列結合主機名稱或者IP位址産生。值得注意的是，在單一多媒體會議中，對于使用者發起的對同一實體邀請，可能每次配置設定的Call-ID都不盡相同。有趣的是，主叫的Call-ID與被叫接收的INVITE資訊的Call-ID不一樣，主叫Call-ID是終端發起的，是以與終端配置設定的IP位址有關，被叫Call-ID是被叫所處IMS域S-CSCF發起的，是以打上了被叫域S-CSCF的标簽；
(3)Cseq: 1000 INVITE。Cseq對消息處理進行辨別和排序。INVITE需要與對應的消息類型保持一緻（INVITE）。對于對話外非注冊消息的Cseq，可以是設定為任意值。在同一對話内，該值随着消息每傳遞一次進行+1的增量同步。其中一種設定方式可在初始設定時将其與時間（秒級）關聯；
(4) Record-Route: <sip:[email protected][2409:8099:0:20::1]:5062;lr>,Record-Route是由P-CSCF插入的，目的是為了使後續的請求(Request)依然能通過該代理進行路由，在請求從主叫路由到被叫所經曆的一些代理伺服器中，Record-Route是可以被替換或者改寫的；
(5) Contact: <sip:[email protected][2409:8099:0:20::1]:5062;zte-did=2-9-20481-567-12-662>;audio;video;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Contact裡面包含一個SIP URI位址，<>裡面包含的就是SIP URI位址以及相應的URI參數，<>之外的是標頭參數，而不是URI參數。一般可以認為Contact與Via是對應出現的，Via告訴後續的響應消息（Response）将要發送的位址，而Contact則訓示了後續的請求消息（Request）将要發送的位址。除了SIP URI位址這些資訊之外，Contact裡面還包含了一些支援主叫UE能夠支援的特性以及能力；
(6) Via: SIP/2.0/UDP [2409:8099:0:20::1]:5062;branch=z9hG4bK-*5*01eb3dceecc83856d94btaN0
Via裡包含了期望響應消息發送的位址。Branch參數區分了該請求建立的交易。并且在用戶端以及伺服器端，除了Cancel以及Ack請求，Branch參數被唯一使用。Cancel消息裡的Branch參數需要與被Cancel的請求裡的Branch參數保持一緻。Ack裡的Branch參數應該與Invite裡的Branch參數
(7) Content-Disposition: session, 這裡對使用者端（含用戶端和伺服器）描述了消息實體的類型為session(會話)，如果這一欄丢失，則接收端置為預設設定，如果沒有預設設定，則置為render(展示)類型
(8) P-Called-Party-ID: <tel:+8618407404056>, 這項報頭内容隻在被叫中出現，裡面包含的資訊就是被叫UE的公共使用者辨別。
(9)Supported: 100rel,precondition,timer。這裡可選項100rel的出現可以判定SIP message來自于MGCF，也意味着主叫電話來自于交換域
(10) Session-Expires: 3600;refresher=uac
Min-SE: 90
這兩條報頭往往需要結合一起來看，Min-SE決定了session在代理伺服器或者UE之間最小的更新間隔，意味着代理伺服器在處理request時不允許惡意将其修改更低，而Session-Expire則決定了更新的上限，在該值逾時前如果沒有收到周期的re-INVITE或者UPDATE消息，則會話認為結束。同時更新是由發起request的一方（uac）來啟動；一般可以設定30分鐘（1800秒），這是由于認為95%的會話在30小時内就結束了，不過随着新技術的實施，将該值适當拉大也可以接受（詳見 RFC4028）。
(11) P-Asserted-Identity: <tel:18407404348>，該標頭域應該與主叫UE發出的P-Preferred-Identity捆綁起來解讀。這裡涉及了一個trust domain的概念，如果在信任域之間發送，代理伺服器收到了P-Preferred-Identity，如果同在可信域之内，該值作為伺服器可參考值，可在被插入後續的P-Asserted-Identity標頭域中，P-Preferred-Identity值。Asserted Identity意味着該值已被證明，這個值對于接收端的UE來講，意味着比From標頭域的值更值得信任。Asserted的值出現是為了簡化鑒權（防止惡意篡改，更改，重放主叫号碼）來電号碼而産生，這樣在信任域内的不同SIP服務節點轉發該值，無需再重新進行該值的修改。但是發送到信任域之外，需要将該值删除或者進行一些私有加密的處理。這兩個標頭域的取值設定可以是SIP,SIPs URI或者Tel格式，同時對于中間轉發的伺服器，最多可添加一個SIP或者SIPs URI和最多一個Tel URI；
(12)Feature-Caps: *;+g.3gpp.srvcc;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting, Feature-Caps標頭域說明了在SIP信令傳送中途徑的SIP實體所支援的特性和能力，與Contact標頭域的URI裡所支援的特性和能力形成對比的是，Contact標頭域裡的SIP URI表征的SIP實體支援的能力不允許出現在Feature-Caps裡面。一個SIP消息中可以包含多個SIP實體所添加的Feature-Caps標頭域，采取先到先添的原則，後一個添加得保證都在這些標頭域的置頂位置。從這裡我們可以解讀到在信令消息轉發途徑的SIP實體會支援SRVCC，mid-call，甚至支援在alerting過程中的SRVCC切換流程；
(13) Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio,該標頭域是主叫端對被叫端UE所具備的能力偏好要求，在經過一系列的IMS網元後，伺服器會參考該標頭域所規定内容，依據偏好選擇設定，對被叫端進行選擇；
5、UE根據自身是否支援主叫端發起媒體流的子集情況，回報Offer Response消息。SDP消息中表示多媒體對話中一個或者多個媒體資訊。該回報響應發送至P-CSCF
183階段主要做的語音編解碼協商，m=audio 50010 RTP/AVP 104 105，可以看出被叫UE支援的是104、105編碼格式，含意如下
a=rtpmap:104 AMR-WB/16000/1
a=fmtp:104 mode-change-capability=2;max-red=0
a=rtpmap:105 telephone-event/16000/1
a=fmtp:105 0-15，這裡采用的是AMR寬帶語音編碼方式，采樣率為16000Hz，同時telephone-event說明了一些支援DTMF信令的情況（雙音多頻，主要發送号碼用的）；
6、P-CSCF對該對話的所需資源進行授權，值得注意的是，在第4步的時候，P-CSCF就可以根據PCRF回報資訊确認為主叫所進行的資源預留情況；
7、P-CSCF将Offer Response消息轉發到S-CSCF;
8、S-CSCF将Offer Response消息轉發到主叫所處IMS域；
9、主叫側發送響應确認（Response Confirmation）。響應确認中可以包含SDP資訊，這些SDP代表的媒體流資訊可以與第8步中的包含的SDP資訊保持一緻，互或者也可以是其子集。如果SDP中定義了新的媒體，在第12步後P-CSCF（PCRF授權）重複第6步，進行重新的資源授權。主叫可以很靈活的在這一步添加新的媒體和在後續用Update方法添加，但每一次新媒體的添加都會導緻P-CSCF（PCRF）重複第6步的資源授權；
10，S-CSCF将響應确認轉發到拜訪地的P-CSCF，其間可根據營運商配置政策經由I-CSCF路由送達；
11、P-CSCF将響應确認發送被叫UE；
12、UE對Response Confirmation進行應答（200ok）。如果可選的SDP資訊被包含在Response Confirmation裡，那應答中應該也包含SDP響應。如果SDP資訊變化了，P-CSCF授權資源可以被使用；
13、根據營運商IP網絡政策，這裡需要進行IP資源預留。IP資源預留可以在第6步之後由IP接入網發起，或者可以在這裡由UE發起；
14-15、P-CSCF将确認應答消息通過S-CSCF轉發到主叫節點；
16-18、當主叫節點完成了資源預留，發送資源預留成功消息到S-CSCF，S-CSCF将該消息轉發到被叫側；
19、被叫UE振鈴
20-22、被叫UE回報資源預留成功；
23-25，UE進行180持續振鈴響應；
26、當被叫UE接通電話，向P-CSCF發送200 ok的最終響應
27、P-CSCF啟動為該會話預留的媒體流資源；
28、被叫UE啟動媒體流資源；
29-30，P-CSCF轉發200 ok最終響應；
31-33、主叫側對200-ok最終響應進行SIP ACK響應應答，該消息通過中間伺服器轉發到被叫側；
注：這裡被叫UE側的log截取有一些奇怪的現象，有可能是網絡側的一些設定問題，雖然不影響該次電話的接通，但是仍然值得進行後續的研究；
問題1:
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=46000E38A708F302;"sbc-domain=sbc.0731.hn.chinamobile.com";"ue-ip=10.185.184.130";"ue-port=5068";"raw-ip=10.185.184.130";"raw-port=5068"
Supported: 100rel,precondition,timer
這些現象說明主叫電話在TD-SCDMA上，但是現網TD-SCDMA并不與IMS互通，也不承載VoIP話音，同時檢索主叫側log，發現主叫UE是在LTE網絡上進行起呼的，至于具體原因為什麼會導緻這樣，建議逐SIP節點進行定位确認；
問題2:
SIP UPDATE信令消息中含有如下SDP内容
m=audio 20686 RTP/AVP 104 105 8 0 18 101，
意味着到達被叫的UPDATE消息進行最終編解碼協商時同時支援104，105，8，0，18，101，但是檢索主叫側UPDATE消息，隻涵蓋了104,105，也就是說其他編解碼消息是網絡側附加上去的，至于具體原因是什麼，隻能通過IMS廠家進行輔助定位了。