是否有无声阴谋违反sip rfc 3261 18.2.2
Is there a silent conspiracy to violate sip rfc 3261 18.2.2
我的家庭 sip 服务器是一个名为“PBX”或“asterisk18 1.8.32.3-4”的 OpenWRT 嵌入式软件，它向主机 和端口[发送对 UDP REGISTER 请求的响应=26=] 从中发出请求，而规范说，
> Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter, using the port indicated
in the "sent-by" value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP "port
unreachable" response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.
https://www.rfc-editor.org/rfc/rfc3261#section-18.2.2
而这个‘received’参数是服务器自己设置的，据我理解eggs previous section 18.2.1.
我的 Via header 中没有“rport”参数，据我所知，这实际上应该会触发 https://www.rfc-editor.org/rfc/rfc3581
这样的行为
这破坏了我的应用程序，它只能听一个，
5060端口。 （它基于 Camel Netty，而非 Jain Sip）
我是不是遗漏了什么，比如更新的 rfc 或措辞？
答案：
我的简短回答是：是（不仅是 Via 规则，还有 Contact 规则）！
使用“received”参数，没有“rport”和用于发送的不同套接字端口将不起作用：
原因与标准 NAT 行为有关。如果客户端向服务器发送 UDP 消息，NAT 将重写 PORT 和 IP UDP 数据包。服务器只能通过在反向路径上发送 UDP 消息来回复：即，使用来自 NAT 的 IP 和 PORT。在这种情况下，NAT 会将 UDP 消息中继到套接字发送方。
这解释了为什么从 LAN 与 Internet 上的 SIP 服务器通话时无法使用 Via 中的 IP 和 PORT。
在不违反规范的情况下接收 SIP 回复的干净解决方案：
- 使用标准的“接收”参数
- 使用标准的“rport”扩展参数
- 在同一端口上发送请求并侦听答案
使用标准的“received”参数和标准的“rport”扩展参数是确保 SIP 服务器可以回复您的 UDP 消息的唯一解决方案。因此，您可以接收回复的唯一端口是您用来发送 UDP 消息的端口。
当然，上述解决方案是通用的：它也适用于 LAN 到 LAN 通信。
需要扩展解决方案以接收来自代理的未来请求：
当然，SIP 应答也是如此。然而，对于应该发送给联系人 header 的 SIP 服务发送的未来请求也是如此。 Contact headers 存在相同的限制，因此，我建议阅读并实施 rfc5626
最差方案：一个SIP ALG
SIP 规范以及一些扩展（rfc3581 和 rfc5626）只是让 SIP 工作的最佳方式。 SIP ALG 修改 sip 内容一直是一大失败点。值得一提的是，许多人认为这是唯一的解决方案。 （我很不同意）
你的问题：为什么SIP服务器会违反rfc？
只有一种方法可以发送 UDP 回复（并转发 SIP 请求）。如果服务器不是 re-using“反向 UDP 路径”：
- REGISTER 的回复将被 NAT 丢弃...
- 来电 (INVITE) 将被 NAT 挂断...
所以，从代理的角度来看，没有理由不违反 rfc。在大多数情况下，在代理上，违反 Via 和 Contact 将解决 SIP 客户端上缺少扩展的问题。它可能会破坏 ALG 背后的一些 SIP 客户端，但无论如何，我不太喜欢 ALG ;)
我的家庭 sip 服务器是一个名为“PBX”或“asterisk18 1.8.32.3-4”的 OpenWRT 嵌入式软件，它向主机 和端口[发送对 UDP REGISTER 请求的响应=26=] 从中发出请求，而规范说，
> Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter, using the port indicated
in the "sent-by" value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP "port
unreachable" response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.
https://www.rfc-editor.org/rfc/rfc3261#section-18.2.2
而这个‘received’参数是服务器自己设置的，据我理解eggs previous section 18.2.1.
我的 Via header 中没有“rport”参数，据我所知，这实际上应该会触发 https://www.rfc-editor.org/rfc/rfc3581
这样的行为这破坏了我的应用程序，它只能听一个， 5060端口。 （它基于 Camel Netty，而非 Jain Sip）
我是不是遗漏了什么，比如更新的 rfc 或措辞？
答案：
我的简短回答是：是（不仅是 Via 规则，还有 Contact 规则）！
使用“received”参数，没有“rport”和用于发送的不同套接字端口将不起作用：
原因与标准 NAT 行为有关。如果客户端向服务器发送 UDP 消息，NAT 将重写 PORT 和 IP UDP 数据包。服务器只能通过在反向路径上发送 UDP 消息来回复：即，使用来自 NAT 的 IP 和 PORT。在这种情况下，NAT 会将 UDP 消息中继到套接字发送方。
这解释了为什么从 LAN 与 Internet 上的 SIP 服务器通话时无法使用 Via 中的 IP 和 PORT。
在不违反规范的情况下接收 SIP 回复的干净解决方案：
- 使用标准的“接收”参数
- 使用标准的“rport”扩展参数
- 在同一端口上发送请求并侦听答案
使用标准的“received”参数和标准的“rport”扩展参数是确保 SIP 服务器可以回复您的 UDP 消息的唯一解决方案。因此，您可以接收回复的唯一端口是您用来发送 UDP 消息的端口。
当然，上述解决方案是通用的：它也适用于 LAN 到 LAN 通信。
需要扩展解决方案以接收来自代理的未来请求：
当然，SIP 应答也是如此。然而，对于应该发送给联系人 header 的 SIP 服务发送的未来请求也是如此。 Contact headers 存在相同的限制，因此，我建议阅读并实施 rfc5626
最差方案：一个SIP ALG
SIP 规范以及一些扩展（rfc3581 和 rfc5626）只是让 SIP 工作的最佳方式。 SIP ALG 修改 sip 内容一直是一大失败点。值得一提的是，许多人认为这是唯一的解决方案。 （我很不同意）
你的问题：为什么SIP服务器会违反rfc？
只有一种方法可以发送 UDP 回复（并转发 SIP 请求）。如果服务器不是 re-using“反向 UDP 路径”：
- REGISTER 的回复将被 NAT 丢弃...
- 来电 (INVITE) 将被 NAT 挂断...
所以，从代理的角度来看，没有理由不违反 rfc。在大多数情况下，在代理上，违反 Via 和 Contact 将解决 SIP 客户端上缺少扩展的问题。它可能会破坏 ALG 背后的一些 SIP 客户端，但无论如何，我不太喜欢 ALG ;)