0

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

以下是常规流程的示例：

  1. 客户端向 SIP-Proxy 发送 INVITE，SIP-Proxy 向 Asterisk 重新发送 INVITE
  2. Asterisk 回答 200 OK，SIP-Proxy 向客户端重新发送 200 OK。
  3. 客户端用 ACK 应答，SIP-Proxy 向 Asterisk 重新发送 ACK
  4. 每当其中一方发送 BYE 时，对话就应该结束。

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

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

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

4

2 回答 2

0

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

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

于 2014-07-21T13:19:44.037 回答
0

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

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

于 2014-07-29T17:18:36.513 回答