如何确定 SIP 呼叫何时开始答案

【问题标题】：How to figure out when SIP call is started如何确定 SIP 呼叫何时开始
【发布时间】：2014-07-20 16:12:10
【问题描述】：

我正在编写简单的 SIP 代理应用程序，它位于 Astreisk 和 SIP 客户端（任何软件电话）之间。该应用程序的目的是计算通话的持续时间。

以下是常规流程的示例：

在第 2 步，我假设呼叫已启动（例如 rtp 媒体流已启动）。然后我等待 BYE 消息来计算通话时间。但是我注意到有些客户从不进入第 3 步和第 4 步。在第 2 步之后没有收到任何一方的通话结束通知。并且这种通话的持续时间是无限的。

在不嗅探 RTP 流的情况下找出 SIP 呼叫的开始/停止时间的最佳方法是什么？我应该等待第 3 步来标记通话的开始吗？如果客户端忽略 ACK 或网络中丢失带有 ACK 的 UDP 数据报怎么办？

现在我曾经认为没有可靠的方法来确定 SIP 呼叫是否已启动。也许我应该使用 Astrisk 通道 API 来跟踪活动调用。

【问题讨论】：

【解决方案1】：

另一个选项是生成一个 RE-INVITE 来测试 Session 的存在。不必协商计时器或任何东西。仅使用重新邀请可能会有所帮助。重用 SDP 以确保不会发生媒体更改。但是随后您的应用程序将不再是调用路径中的代理，而是成为应用程序服务器。

此外，此重新邀请请求的持续时间只能限制为最近的时间间隔，而不一定是释放呼叫的确切时间。

【讨论】：

最后在调试后我设法弄清楚它发生在 BYE 数据包由于重传而丢失时。例如，如果我们有 10 秒的网络峰值，再见数据包将丢失。如果我确实重新邀请了 1-2 分钟，是否有助于检查通话是否仍然存在？
是的，使用 Re-INvite 定期 ping 应该可以帮助您确定远程服务器上是否存在呼叫。要么它根本不响应，要么用 481 / 408 回复。在任何一种情况下，您都可能会挂断电话。

【解决方案2】：

您的问题似乎在 SIP 级别，因为您的代理没有使用 Route 标头将自身添加到消息路径中。此过程称为记录路由。如果这样做，对话中的所有后续请求也将遍历它（包括 ACK 和 BYE）。

您不应该通过编写 SIP 代理来重新发明轮子。例如，您可以使用开源、灵活、强大且完全可定制的 SIP 代理来构建您能想到的任何可能的场景：OpenSIPS!

【讨论】：