Kamailio SIP+RTP双网卡SBC呼叫流程与媒体处理说明

本文档旨在详细解释基于提供的 kamailio_sbc_dual_nic.cfg 配置文件，在双网卡SBC（Session Border Controller）场景下，Kamailio (5.8.3) 如何与rtpengine协同工作，处理SIP信令以及音频、视频和RTCP媒体流的转发。该方案利用dispatcher模块实现对公网和私网多网关的负载均衡。

1. 系统概览

核心组件包括：

Kamailio (5.8.3)：作为SIP信令服务器，负责处理呼叫路由、负载均衡和与rtpengine的交互。
rtpengine (mr13.1.1.6)：作为媒体代理，负责处理RTP/RTCP媒体流的转发、NAT穿透（本场景为无NAT，但rtpengine仍管理媒体端口和IP）、以及可能的媒体处理（如编解码转换，本例未重点配置）。rtpengine配置为双网卡模式，拥有公网和私网IP接口。
Dispatcher模块：Kamailio内置模块，用于将呼叫分发到公网或私网的多个目标网关，实现负载均衡和高可用性。

Kamailio监听其公网IP和私网IP上的SIP请求。rtpengine通过NG协议与Kamailio在本地回环地址通信。

2. 呼叫流程：公网用户呼叫私网用户/网关

假设一个公网SIP用户通过互联网呼叫一个位于私网的企业IP-PBX分机或私网网关。

INVITE请求到达Kamailio公网接口：

公网用户发送SIP INVITE请求，目标是Kamailio的公网IP地址（例如 PUBLIC_IP:5060）。SDP中包含公网用户的媒体信息（IP和端口）。
Kamailio的request_route首先执行通用检查（Max-Forwards, Sanity Checks）。
通过if ($Ri == "PUBLIC_IP")判断请求来自公网接口，进入route[FROM_PUBLIC]逻辑。

选择私网目标网关 (Dispatcher)：

在route[FROM_PUBLIC]中，调用ds_select_dst("2", DS_ALGORITHM_PRIVATE)。这会从预定义的私网网关组（Set ID 2，例如 /etc/kamailio/dispatcher_private.list 中定义的网关）中根据指定算法（例如轮询）选择一个可用的私网网关。
如果选择失败（没有可用网关），则回复503 Service Unavailable。
选中的私网网关URI被存入$du。

rtpengine处理媒体协商 (Offer)：

如果INVITE请求中包含SDP (has_body("application/sdp"))，则调用rtpengine_manage(RTPENGINE_COMMON_FLAGS + " direction=public direction=private")。

RTPENGINE_COMMON_FLAGS 通常包含 trust-address replace-origin replace-session-connection RTP/AVP rtcp-mux-offer 等。
关键在于direction=public direction=private：这个flag指示rtpengine，对于这个呼叫的“对端”（即私网侧），应该使用rtpengine配置的“私网”接口来分配媒体端口和宣告IP地址。而对于“本端”（即公网用户侧），rtpengine会使用其“公网”接口。

rtpengine收到指令后：

在私网接口上为私网网关分配RTP/RTCP端口（例如 PRIVATE_RTPENGINE_IP:port_private）。
在公网接口上为公网用户分配RTP/RTCP端口（例如 PUBLIC_RTPENGINE_IP:port_public）。
修改INVITE中的SDP：将o=行和会话级c=行中的IP地址替换为rtpengine的公网接口IP (PUBLIC_RTPENGINE_IP)，并将媒体端口替换为rtpengine在公网接口上分配的端口 (port_public)。这个修改后的SDP将发往公网用户（在最终的200 OK中）。
rtpengine内部记录媒体流的映射关系：PUBLIC_RTPENGINE_IP:port_public <-> PRIVATE_RTPENGINE_IP:port_private。

如果rtpengine_manage失败，回复500 Media Proxy Error。

转发INVITE到私网网关：

Kamailio通过t_set_destination_uri($du)设置请求的目标为选中的私网网关。
record_route()确保后续请求（如ACK, BYE）经过Kamailio。
Kamailio通过t_relay()将带有rtpengine修改后SDP（此时SDP中的媒体地址是rtpengine的公网地址，这是发往私网网关的INVITE中SDP的视角，它应该宣告rtpengine的私网地址给私网网关）的INVITE请求转发给选定的私网网关。

更正与澄清：当rtpengine_manage在route[FROM_PUBLIC]中为发往私网的INVITE处理SDP时，它修改的SDP内容是准备给私网对端的。因此，SDP中的c=行和媒体端口应该是rtpengine的私网接口IP和端口。rtpengine知道呼叫的另一端（公网用户）的媒体信息，并将使用其公网接口与公网用户通信。

私网网关响应 (例如200 OK)：

私网网关处理INVITE，并回复一个包含其自身媒体信息（私网IP和端口）的200 OK。
200 OK通过Kamailio返回（由于Record-Routing）。

rtpengine处理媒体协商 (Answer)：

Kamailio的onreply_route捕获到200 OK。
如果响应中包含SDP，再次调用rtpengine_manage(RTPENGINE_ANSWER_FLAGS + " direction=private direction=public") (或者根据保存的呼叫方向上下文确定正确的direction)。

direction=private direction=public仍然适用，因为这是对始于公网、终于私网的呼叫的响应路径。

rtpengine接收到私网网关的SDP，确认媒体参数。它会修改200 OK中的SDP，将其中的媒体IP和端口替换为rtpengine的公网接口IP和端口 (PUBLIC_RTPENGINE_IP:port_public)。这个修改后的SDP将发往公网用户。

转发响应给公网用户：

Kamailio将带有rtpengine修改后SDP的200 OK转发给公网用户。

媒体流建立：

公网用户向PUBLIC_RTPENGINE_IP:port_public发送RTP/RTCP流。
rtpengine接收到后，根据内部映射，将媒体流从其公网接口转发到其私网接口，并发送给私网网关的媒体地址 PRIVATE_GW_IP:port_gw_private (此地址由rtpengine从私网网关的SDP中获知)。
反向媒体流：私网网关向PRIVATE_RTPENGINE_IP:port_private发送RTP/RTCP流。
rtpengine接收到后，转发给公网用户的媒体地址 PUBLIC_USER_IP:port_user_public (此地址由rtpengine从公网用户的初始SDP中获知)。
核心路径：公网用户 <-> rtpengine公网IP <-> rtpengine私网IP <-> 私网网关。

3. 呼叫流程：私网用户/网关呼叫公网用户

此流程与上述类似，但方向相反。

INVITE请求到达Kamailio私网接口：

来自私网用户/网关，目标是Kamailio的私网IP地址（例如 PRIVATE_IP:5060）。
Kamailio通过if ($Ri == "PRIVATE_IP")判断请求来自私网接口，进入route[FROM_PRIVATE]逻辑。

选择公网目标网关 (Dispatcher)：

调用ds_select_dst("1", DS_ALGORITHM_PUBLIC)选择公网网关组（Set ID 1）。

rtpengine处理媒体协商 (Offer)：

调用rtpengine_manage(RTPENGINE_COMMON_FLAGS + " direction=private direction=public")。

direction=private direction=public指示rtpengine，对于呼叫的“对端”（即公网侧），应使用rtpengine的“公网”接口。对于“本端”（私网用户），使用其“私网”接口。

rtpengine在公网接口分配媒体端口，在私网接口分配媒体端口。
修改INVITE中的SDP：将媒体IP和端口替换为rtpengine的私网接口IP和端口，准备发往公网网关（宣告rtpengine的公网地址）。

更正与澄清：当rtpengine_manage在route[FROM_PRIVATE]中为发往公网的INVITE处理SDP时，它修改的SDP内容是准备给公网对端的。因此，SDP中的c=行和媒体端口应该是rtpengine的公网接口IP和端口。

转发INVITE到公网网关。
公网网关响应 (例如200 OK)。
rtpengine处理媒体协商 (Answer)：

调用rtpengine_manage(RTPENGINE_ANSWER_FLAGS + " direction=public direction=private")。
rtpengine修改200 OK中的SDP，将其中的媒体IP和端口替换为rtpengine的私网接口IP和端口，准备发往私网用户/网关。

转发响应给私网用户/网关。
媒体流建立：

私网用户/网关 <-> rtpengine私网IP <-> rtpengine公网IP <-> 公网网关/用户。

4. rtpengine在媒体处理中的角色

音视频流 (Audio/Video)：rtpengine通过解析SDP中的m=audio和m=video行来识别不同的媒体流。它会为每个媒体流（及其对应的RTCP流）分配端口并进行转发。RTP/AVP flag确保了对标准音视频profile的支持。
RTCP流：rtpengine自动处理与RTP流配对的RTCP流。用户要求RTCP转发以处理视频丢包，这是rtpengine的默认行为。rtcp-mux-offer和rtcp-mux-answer flags用于协商是否将RTP和RTCP复用在同一端口上，这是推荐的做法，可以节省端口资源并简化NAT穿透（尽管本场景无NAT）。
接口选择：direction=public或direction=private flag是核心，它告诉rtpengine应该将哪个逻辑网络接口（公网或私网）视为呼叫的“远端”进行SDP宣告，并使用哪个接口与该远端通信。rtpengine的另一个接口则用于与呼叫的“近端”通信。
SDP操作：trust-address (信任SDP中的c=行IP作为媒体来源的初始判断，但最终会被rtpengine的IP替换掉), replace-origin (替换o=行), replace-session-connection (替换会话级c=行) 确保了SDP被正确修改以通过rtpengine路由媒体。

5. Dispatcher模块的角色

负载均衡：根据配置文件中定义的网关列表（例如/etc/kamailio/dispatcher_public.list和/etc/kamailio/dispatcher_private.list）和选择的算法（例如轮询），将出局呼叫（无论是到公网还是私网的网关）分发到多个目标网关之一。
网关健康检查：Dispatcher模块可以配置为定期ping目标网关（通过SIP OPTIONS请求），以检查其可用性，并自动将流量从不可用的网关移开。
分组管理：通过Set ID（例如公网组为1，私网组为2）对不同的网关进行分组管理，使得路由逻辑可以清晰地选择合适的目标组。

6. Kamailio配置关键点回顾

监听接口：Kamailio通过listen参数同时监听公网和私网IP地址，以便接收来自两个网络的SIP请求。
接口识别：在request_route中，通过$Ri (Received Interface IP) 变量判断请求到达的接口，从而决定呼叫的初始方向（公网到私网，或私网到公网）。
rtpengine模块参数：rtpengine_sock定义了与rtpengine守护进程的通信方式。
rtpengine_manage()调用：在INVITE请求和对应的2xx响应中（如果包含SDP）调用，以使rtpengine参与媒体会话。关键是根据呼叫方向正确设置direction flag。
Record-Routing：record_route()函数用于确保后续的请求（如ACK, BYE）和响应都通过Kamailio，从而使Kamailio能够保持对话状态并正确处理媒体会话的生命周期（例如调用rtpengine_delete()）。
rtpengine_delete()：在对话结束时（例如收到BYE或CANCEL后，或对话超时），调用rtpengine_delete()来释放rtpengine中占用的资源。
onreply_route中的逻辑：正确处理响应中的SDP至关重要。确定响应对应的原始请求方向，以便为rtpengine_manage设置正确的direction flag，是onreply_route中较为复杂的部分，通常需要借助事务标志或对话AVPs来传递上下文。

7. 关于音视频和RTCP的进一步说明

rtpengine本身设计为透明处理RTP和RTCP。只要SDP中正确描述了媒体类型（例如m=audio ... RTP/AVP ...，m=video ... RTP/AVP ...），rtpengine就会为它们分配端口并转发。RTCP通常使用RTP端口号+1（除非使用RTCP-Mux）。

用户要求RTCP转发以处理视频丢包，这是标准行为。RTCP报告（如Sender Reports, Receiver Reports）包含了丢包统计、抖动等信息，视频编解码器和播放器可以利用这些信息来调整码率、请求重传（如果协议支持）或进行错误隐藏，从而改善视频质量。

通过确保rtpengine正确桥接了双向的RTCP流，接收端可以向发送端报告网络状况，发送端也可以据此调整发送策略，这对于视频流的质量至关重要。

这份说明应该能帮助理解所提供Kamailio配置方案的工作原理。在实际部署前，务必替换所有占位符IP地址，并根据具体网络环境进行测试和调整。

空空如常

求真得真