sip - 这个 SIP 呼叫出了什么问题？RTP 建立前连续多条 NOTIFY 消息

Question

长串 NOTIFY 消息发生在被叫号码应答之后。大约 20-30 秒后，503 发生，然后呼叫与音频连接良好。

Answer 1

如果该跟踪是针对单个调用的，那将是一个非常复杂的跟踪。在花了一些时间查看它之后，我认为它不是一个单一的呼叫，而是其中混合了一些不同的呼叫。10.10.20.1 是一个背靠背用户代理 (B2BUA) 并且正在启动它的 on 调用以响应不同的事件，这一事实使情况变得复杂。

至于您关于 NOTIFY 请求的问题，它最初是由 UAC 在 10.10.10.3 生成的，作为似乎有人参与的转移的一部分。REFER 请求是传输的开始。为 REFER 事务创建隐式订阅，这是 NOTIFY 请求的一部分（参见https://www.rfc-editor.org/rfc/rfc3515并参见https://www.rfc-editor。 org/rfc/rfc4488处理抑制隐式事务）。

对于有人参与的转移，NOTIFY 请求允许呼叫支路端点指示转移已成功处理。在这种情况下，看起来 10.10.10.3 的用户代理在收到对其 NOTIFY 请求的响应之前并不乐意接受传输。这是不寻常的行为，因为通常 NOTIFY 请求只是为了通知代理不控制呼叫流的事件。一旦 10.10.10.3 收到对其 NOTIFY 请求的 503 响应，它最终开始向 10.10.20.4 发送 RTP。它不必关心响应是什么，因为 503 是一个错误条件，通常会导致等待它失败的任何东西。