Genesys Engage呼叫录制中SIP INVITE字段处理与媒体流未投递问题咨询

核心现象解读 #

• 抓包观测到的网段广播包不是媒体服务器主动发送广播类INVITE，是SIP栈的默认兜底行为：INVITE报文头里明确携带指向GVP服务器的Route头，说明请求完全遵循SIP逐跳路由规则，不会无目的广播。出现广播的根因是你配置的my_socket_host_name没有在媒体服务器、GVP服务器的域名解析体系中正常解析，SIP栈触发ARP广播查询目标主机MAC地址时，在Wireshark上表现为发往.252/.255的广播流量。这个阶段根本没有生成可路由的SIP INVITE报文，只是在网络层做主机发现。
• 你看到的特殊格式Request URI、To头域是Genesys GVP的专属SIP扩展，完全符合RFC3261定义的SIP URI结构规范：sip:record=KOAG2VPNA57H1BTJ81493PTKGK000001@my_socket_host_name:5060 中，record=xxx是URI的user-part字段，CallUUID/recordDN/DN是URI的header参数，和通用SIP流程里把user-part设置为分机号的逻辑没有本质区别，只是通用SIP场景很少将录制标识嵌入user-part，公开示例较少。

根据RFC3261对SIP URI的定义，user-part字段允许携带任意字符串作为用户标识，没有强制要求必须是数字分机号，因此将录制会话ID嵌入user-part的设计本身完全合规。

• 当前socket收不到连接的核心断点不在已验证过的环节：你从其他服务器telnet验证socket状态正常，仅证明录制服务本身的监听逻辑没问题，没有覆盖媒体服务器、GVP服务器对配置的主机名的解析连通性——这是该类问题最高发的故障点。

SIP 体系通用特殊INVITE处理逻辑 #

• 这类携带自定义user-part、扩展业务参数的INVITE，属于第三方呼叫控制场景的标准实现：不需要录制服务提前在SIP核心上完成注册，仅在业务侧发起录制请求时，将录制端点信息传递给媒体服务器，后续媒体服务器按配置的端点地址构造INVITE发起协商。
• 媒体服务器发出的INVITE不需要等待其他节点返回录制端点的精确地址：从当前报文的Route头可以看到，请求首先发往GVP服务器做会话合法性校验（校验录制请求的授权状态、会话ID匹配性），GVP校验通过后会按SIP Record-Route规则逐跳将请求转发到录制端点。如果转发流程中断，本质是GVP在解析录制端点主机名时遇到了和媒体服务器相同的DNS解析问题，触发网段广播查询目标主机。

可直接落地的验证步骤 #

• 从媒体服务器、GVP服务器分别发起连通性测试，测试时必须使用你配置的my_socket_host_name而非直接使用录制服务器IP，模拟SIP栈的真实解析流程。
• 在媒体服务器、GVP服务器的hosts文件中，手动绑定my_socket_host_name到录制服务器的实际IP，排除内部DNS解析故障。
• 抓包时过滤sip协议和录制服务器IP相关的流量，确认hosts配置生效后，INVITE报文可以正常到达录制服务的5060监听端口。
• 录制服务收到INVITE后需要返回携带本地收流地址/端口SDP的200 OK响应，完成SIP协商流程后，媒体服务器才会将sendonly属性对应的RTP音频流，发送到200 OK协商出的端口。

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