SIP (RFC 3261) 服务器事务超时
根据 RFC 3261，服务器事务没有超时PROCEEDING 或 TRYING 状态。据我了解，这意味着 TU 必须发送对交易的响应。然而，如果 TU 失败，应该有一种方法让事务知道并终止。
根据 RFC 3261，哪种行为是正确的？
服务器事务是否应该检测 TU 故障？
我应该添加自己的超时吗？假设另一端的客户端事务无论如何都会超时，那么在一段超时后终止服务器事务应该是安全的。预期的客户端事务超时。
还有其他行为吗？
According to the RFC 3261, there is no timeout for server transactions in PROCEEDING or TRYING states. As I understand, that means that TU MUST send response to the transaction. However, if TU fails, there should be a way for transaction to know about that and terminate.
Which behavior is correct according to the RFC 3261?
Should server transaction detect TU failure?
Should I add my own timeout? Assuming that client transaction on the other side will time-out anyway, it should be safe to terminate server transaction after some timeout > expected client transaction timeout.
Any other behavior?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事务中的超时用于处理远程故障 - 网络分区、远程计算机故障等。SIP
不会告诉您在发生本地故障时该怎么做> 失败，比如你的交易用户层崩溃了。
您的 TU 是整个 SIP 堆栈的“大脑”，因此如果它失败，您的 SIP 堆栈就会整体失败。我认为事务层尝试继续运行是不明智的。
有些事务可能会在应用程序重新启动后有意义地持续存在（例如，存在订阅），而其他事务（例如呼叫）可能不会。您可以将这些“持久”事务的状态存储在磁盘上，并在重新启动应用程序后恢复它们。
The timeouts in the transactions are to handle remote failures - network partitions, the remote machine falling over, etc.
SIP doesn't tell you what to do in the event of a local failure, like your Transaction-User layer falling over.
Your TU's the "brain" of the entire SIP stack, so if it fails, your SIP stack fails as a whole. I don't think it's sensible for the transaction layer to attempt to continue functioning.
Some transactions might meaningfully persist across your application reboot - presence subscriptions, say - while others like calls probably can't. You might store the state of these "persistable" transactions on disk, and restore them after you restart your application.