目錄

S-CSCF 調用 RTPengine

整體路由

注意

IMS 注冊流程 和 IMS 會話流程 的區別

IMS注冊流程

IMS會話流程(如INVITE請求)

這種設計的原因

P-CSCF 調用 RTPengine

---

S-CSCF 調用 RTPengine

整體路由

UA a生成SDP offer，發送SIP INVITE請求(包含SDP offer)，發送到P-CSCF，然后轉發給S-CSCF(因為已經經過了IMS注冊流程之后，就會直接P-CSCF到S-CSCF，不會經過I-CSCF詢問了),然后到I-CSCF，然后I-CSCF通過HSS查詢被叫的S-CSCF，然后轉發SIP給他，然后調用RTPengine的offer函數，RTPengine解析SDP offer(然后分配媒體端口；修改SDP中的IP地址和端口信息，以確保媒體流經過RTPEngine；可能調整編解碼器列表；創建內部會話狀態)然后返回修改的SDP給被叫的S-CSCF，然后將SIP INVITE轉發給被叫P-CSCF，P-CSCF轉發給UA b，UA b基于收到的offer和自身能力生成SDP answer，然后發送SIP 200OK(包含SDP answer)給被叫P-CSCF，然后P-CSCF將消息轉發給被叫S-CSCF，在轉發之前再次調用RTPengine的answer函數，解析SDP answer(驗證與之前offer的兼容性；可能進行必要的SDP調整；更新內部會話狀態；準備RTP/RTCP處理器)返回可能修改過的SDP answer給S-CSCF，然后將包含可能修改后SDP的200 OK轉發給呼叫方側的S-CSCF(根據via頭域)，然后主叫S-CSCF將200 OK轉發給P-CSCF再轉給UA a，然后UA a接收200 OK響應之后發送ACK給其P-CSCF，然后到主叫S-CSCF，然后把ACK轉發給被叫S-CSCF，再到被叫P-CSCF，再到UA b。此時媒體會話建立RTPengine準備就緒，開始處理RTP/RTCP數據包，UA a和UA b之間的媒體流通過RTPEngine中轉。

注意

S-CSCF間的路由是基于SIP消息中的Via頭域：每個SIP請求經過的節點都會在Via頭域中添加自己的信息，響應消息會按照相反的順序進行路由。

主叫的S-CSCF在用戶注冊IMS網絡時就已確定：當用戶進行IMS注冊時，HSS會為其分配一個S-CSCF，并在后續的會話中使用這個S-CSCF。

I-CSCF確實參與了初始INVITE請求的路由，并且它的信息被添加到了Via頭域中。

雖然I-CSCF主要用于初始路由，但它仍然會處理返回的響應，因為它的信息在Via頭域中。 主叫S-CSCF的信息也在Via頭域中，所以200 OK響應會經過它，而不是直接從I-CSCF到P-CSCF。

IMS 注冊流程 和 IMS 會話流程 的區別

IMS注冊流程

UA -> P-CSCF -> I-CSCF -> HSS -> S-CSCF

在注冊過程中，I-CSCF確實先于S-CSCF接收請求，因為此時系統還不知道哪個S-CSCF負責該用戶。

I-CSCF查詢HSS以確定合適的S-CSCF，然后將注冊請求轉發給選定的S-CSCF。

IMS會話流程(如INVITE請求)

UA -> P-CSCF -> S-CSCF -> I-CSCF -> (被叫方的)S-CSCF

在已注冊用戶發起的會話中，請求首先到達用戶的S-CSCF，然后才到I-CSCF。

這是因為在注冊過程中，用戶已經被分配了一個S-CSCF，所有后續的會話請求都會先經過這個已知的S-CSCF。

這種設計的原因

注冊時，需要I-CSCF來幫助選擇合適的S-CSCF。 會話時，用戶已有指定的S-CSCF，可以直接處理請求，提高效率。 S-CSCF可以執行一些策略控制和路由決策，然后再將請求發送到I-CSCF以定位被叫方。

P-CSCF 調用 RTPengine