【发布时间】：2023-03-26 02:30:01
【问题描述】：
假设 SIP 对话（INVITE, 200 OK, ACK）已通过 UDP 建立；并且发送了一条需要 TCP 作为传输的大消息。 在为所有其他后续（和正常大小）消息发送大消息之后应用的传输协议是什么？
协议是否切换到 TCP 以处理所有进一步的请求/响应，还是继续使用最初协商的传输 - UDP - 处理标准大小（不是大）的消息？
我的发现（基于 RFC 3261）：
所有 SIP 元素必须实现 UDP 和 TCP。 SIP 元素可能
实现其他协议。 - 来自rfc3261#18
ACK 必须发送到相同的地址， 原始请求发送到的端口和传输。 - 来自rfc3261#18
好吧，不是所有请求（尤其是 ACK）都能够独立选择传输。
使 UA 强制使用 TCP 是对 RFC 的重大改变 2543. 它的出现是为了处理更大的消息， 必须使用 TCP，如下所述。因此，即使一个元素 从不发送大消息，它可能会收到一个并且需要 能够处理它们。 - 来自rfc3261#18
在已建立的对话期间，UAS/UAC 永远不知道是否需要大消息 - 从 UDP 切换到 TCP 就可以了（无需任何 RE-INVITE 提前将传输更改为实际请求）。
301（永久移动）或 302（临时移动）响应可能 还提供与目标相同的位置和用户名 初始请求，但指定其他传输参数，例如 要尝试的不同服务器或多播地址，或更改 SIP 从 UDP 传输到 TCP，反之亦然。 - 来自rfc3261#8.3
不真正相关 - UAS 可能想要更改 UAC 建议的传输；但这仅基于对某些 INVITE（或 RE-INVITE）的反应
目的地址， 取消的端口和传输必须与用于取消的那些相同 发送原始请求。 - 来自rfc3261#9.1
好的，CANCEL（如 ACK）也不能独立选择传输。
如果请求在路径 MTU 的 200 字节内，或者如果它更大 超过 1300 字节且路径 MTU 未知，必须发送请求 使用 RFC 2914 [43] 拥塞控制传输协议，例如 作为 TCP。如果这导致传输协议从一个 顶部 Via 中的值，必须更改顶部 Via 中的值。
也就是说，如果 SIP 对话是通过 UDP 建立的，它还必须能够接收 TCP 请求。
适用于任何端口和接口 服务器侦听 UDP，它必须在同一个端口上侦听，并且 TCP 接口。这是因为可能需要发送消息 如果它太大，则使用 TCP，而不是 UDP。结果， 反过来是不正确的。服务器不需要监听 UDP 特定的地址和端口只是因为它正在侦听相同的 TCP的地址和端口。当然，可能还有其他原因 服务器需要在特定地址和端口上侦听 UDP。
好的，这就解释了从 UDP 到 TCP 的无缝切换是如何工作的。 - 对于另一个方向，它不是必需的，但是（我的理解是：它仍然可以工作）。
【问题讨论】：
标签： sip