SIP协议中的重传机制

[导读]SIP协议中的重传机制是如何工作的，为什么会触发重传，以及如何避免不必要的重传。

SIP中的重传机制的基本原理

包括事务层和应用层的重传，比如INVITE和non-INVITE请求的不同处理。然后，结合他之前的问题，说明为什么FreeSWITCH会重复发送200 OK，可能是因为ACK未被正确接收或处理，导致服务端认为响应未被确认，从而触发重传。

SIP 重传机制的作用

SIP 基于 UDP（默认）或 TCP 传输，而 UDP 不保证消息可靠性。为了确保关键消息（如 INVITE、200 OK、ACK）的送达，SIP 协议定义了事务层的自动重传机制：

客户端重传：发送方未收到响应时，自动重传请求。

服务端重传：服务端未收到 ACK 时，重传 2xx 响应（仅针对 INVITE 事务）。

区分请求和响应的重传

对于INVITE事务，客户端会重传请求直到收到临时响应，而服务端会重传响应直到收到ACK。对于非INVITE事务，客户端也会重传请求直到收到最终响应，但服务端不会重传响应，因为这类事务没有ACK机制。

重传触发的场景

(1) INVITE 事务的客户端重传

触发条件：客户端发送 INVITE 后未收到任何响应（如 100 Trying 或 180 Ringing）。

初始重传间隔为 T1（默认 500ms），每次重传间隔翻倍（500ms → 1s → 2s → 4s ...），直到达到 T2（默认 4s）。最大重传次数为 6 次，总超时时间为 64*T1 ≈ 32秒。若超时后仍无响应，客户端终止事务并触发 408 Request Timeout。

(2) INVITE 事务的服务端重传

触发条件：服务端发送 2xx 响应后未收到 ACK。

服务端会重复发送 200 OK，间隔时间为 T1（500ms），最多重传 7 次。若始终未收到 ACK，服务端认为事务失败，可能释放会话资源。非 2xx 响应（如 4xx）不需要 ACK，因此不会重传。

(3) Non-INVITE 事务的重传

适用于 BYE、OPTIONS、REGISTER 等请求。

客户端重传：未收到最终响应（如 200 OK）时重传请求，规则与 INVITE 相同。

服务端不重传响应：因为 Non-INVITE 事务没有 ACK 机制。

为什么 FreeSWITCH 会重复发送 200 OK？

FreeSWITCH 作为服务端发送 200 OK 后未收到合法的 ACK，触发以下流程：FreeSWITCH 发送 200 OK。等待 ACK，若超时（初始 500ms），重传 200 OK。每次重传间隔加倍，直到达到 T2（4s），最终超时（总时间约 32秒）。若始终未收到 ACK，FreeSWITCH 认为会话建立失败，释放资源。