Kamailio能否自动协商编解码？RTC端口与RTCEngine使用疑问

1. 编解码被拒问题处理 #

• 优先确保INVITE请求的SDP中包含PCMA（G.711 a-law）/PCMU（G.711 u-law），且放在编解码列表最前端。Asterisk 20默认对编解码匹配严格，若对方配置了仅允许这两种编码，非匹配请求会直接被拒。
• 用Kamailio的sdpops模块强制过滤或重排序编解码：

  # 仅保留PCMA和PCMU编码
  sdpops_filter_codec("PCMA,PCMU");
  # 或把PCMA/PCMU移至编解码列表首位
  sdpops_reorder_codec("PCMA,PCMU");
  

• 不要仅依赖sngrep抓包，直接获取对方Asterisk的日志（/var/log/asterisk/messages或pjsip.log），能看到具体拒接原因，比抓包更准确。

2. RTCEngine是否必须启用 #

• 无需强制启用。如果本地通话无需RTCEngine即可正常运行，说明你的基础媒体协商/转发逻辑已满足对接Asterisk的需求。RTCEngine主要用于处理WebRTC复杂场景（如ICE/DTLS/SRTP协商、媒体转码），后续涉及WebRTC终端对接时再启用即可。

3. Kamailio的编解码自动协商与RTC配置 #

• 编解码自动协商：Kamailio可通过sdpops模块实现自动匹配两端支持的编解码，过滤不兼容编码并生成协商后的SDP。若需精细化控制（如基于终端类型选编码），可结合dispatcher模块或自定义脚本逻辑。
• RTC端口范围配置：通过rtpproxy模块指定媒体端口区间，确保落在厂商要求的10K-40K范围内：

  modparam("rtpproxy", "port_range", "10000-40000")
  

  同时需开放防火墙对应UDP端口，避免媒体流被拦截。

4. 排查拒接的其他潜在原因 #

除编解码外，Asterisk 20拒接INVITE还可能因以下问题：

• SIP消息格式错误：缺少必要头字段（如From/To/Contact格式不规范、Call-ID重复）。
• 认证失败：对方开启IP白名单或Digest认证，你的请求未携带合法认证信息。
• 媒体端口超出范围：检查Kamailio转发的媒体端口是否落在10K-40K区间，可查看rtpproxy日志确认。
• SDP属性不匹配：Asterisk对a=rtpmap格式、a=fmtp参数有严格要求，需核对SDP细节。
• ACL限制：对方Asterisk配置了IP访问控制，你的IP未在允许列表内。

建议让对方提供Asterisk的pjsip show history <call-id>输出，能直接定位拒接的核心原因。

内容的提问来源于stack exchange，提问作者Chaeril