目录
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
