Question

我的家庭Sip服务器是OpenWRT嵌入式软件，称为“ PBX”或“ asterisk18 1.8.32.3-4”，它从主机向主机和端口发送UDP REGISTER请求的响应规范中指出

     > 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://tools.ietf.org/html/rfc3261#section-18.2.2

据我了解，在18.2.1节之前，这个“ received”参数由服务器本身设置。

我的Via标头中没有“ rport”参数，据我了解，该参数实际上会触发https://tools.ietf.org/html/rfc3581

这样的行为

这会破坏我的只能听一个的应用程序， 5060端口。（它基于Camel Netty，而不基于Jain Sip）

我是否缺少某些内容，例如较新的rfc或措辞？

Answer 1

答案：

我的简短回答是：是（不仅是“通过”规则，还有“联系”规则）！

使用“已接收”参数，没有“端口”和用于发送的其他套接字端口将不起作用：

原因与标准NAT行为有关。如果客户端向服务器发送UDP消息，则NAT将同时重写PORT和IP UDP数据包。服务器只能通过在反向路径上发送UDP消息来进行回复：即，使用NAT中的IP和PORT。在这种情况下，NAT将把UDP消息中继到套接字发送方。

这说明了为什么从LAN与Internet上的SIP服务器进行通讯时无法使用Via中的IP和PORT。

用于接收SIP答复的干净解决方案，而不会违反规范：

使用标准的“已接收”参数
使用标准的“ rport”扩展参数
发送请求并在SAME端口上监听答案

使用标准的“ received”参数和标准的“ rport”扩展参数是确保SIP服务器可以答复您的UDP消息的唯一解决方案。因此，唯一可以接收答复的端口就是您用来发送UDP消息的端口。

当然，上述解决方案是通用的：它还可以在LAN到LAN的通信中工作。

需要扩展解决方案才能接收来自代理的将来请求：

当然，这对于SIP答案是正确的。但是，对于将来应该由SIP服务发送的应发送到Contact标头的请求，也是如此。 Contact标头存在相同的限制，因此，我会尽量阅读并实现rfc5626

最糟糕的解决方案：SIP ALG

SIP规范以及某些扩展名（rfc3581和rfc5626）只是使SIP正常工作的最佳方法。修改SIP内容的SIP ALG一直是失败的一大重点。值得一提的是，因为许多人认为这是唯一的解决方案。（我非常不同意）

您的问题：为什么SIP服务器违反了RFC？

只有一种发送UDP答复（并转发SIP请求）的方法。如果服务器没有重新使用“反向UDP路径”：

对注册的答复将被NAT删除...
来电（邀请）将被NAT丢弃...

因此，从代理角度来看，没有理由不违反rfc。在大多数情况下，在代理上，违反“通过”和“联系”将解决SIP客户端缺少扩展的问题。它可能会使一些SIP客户端落后于ALG，但无论如何，我不喜欢很多ALG;）

是否有无声的阴谋违反sip rfc 3261 18.2.2

1 个答案: