Есть ли молчаливый заговор с целью нарушения sip rfc 3261 18.2.2

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.

В моем заголовке Via нет параметра 'rport', который, как я понимаю, должен на самом деле вызывать такое поведение в соответствии с https://tools.ietf.org/html/rfc3581

Это нарушает мое приложение, которое способно толькослушать один, порт 5060.(Он основан на Camel Netty, а не на Jain Sip)

Я что-то упустил, например, более новый rfc или формулировку?

Answer 1

Ответ:

Мой краткий ответ будет: ДА (и не только правила Via, но и правила контакта)!

При использовании параметра «Receive» никакой «rport» и другой PORT сокета для отправки не будут работать:

Причина связана со стандартным поведением NAT.Если клиент отправит UDP-сообщение на сервер, NAT перезапишет и PORT, и IP-UDP-пакет.Сервер может ответить, отправив сообщение UDP только по обратному пути: то есть, используя IP и PORT от NAT.В этом случае NAT будет передавать UDP-сообщение отправителю сокета.

Это объясняет, почему нельзя использовать IP и PORT в Via при разговоре из локальной сети с сервером SIP в Интернете.

Чистое решение для получения SIP-ответов без нарушения спецификации:

• с использованием стандартного параметра «полученный»
• с использованием стандартного «rport»«параметр расширения
• отправка запроса и прослушивание ответов на тот же порт

Использование стандартных« полученных »параметров И стандартный параметр расширения« rport »- единственное решение, гарантирующееSIP-сервер может отвечать на ваши UDP-сообщения.Как следствие, единственным портом, где вы можете получить ответ, является порт, который вы использовали для отправки UDP-сообщения.

Конечно, вышеупомянутое решение универсально: оно также работает в режиме связи LAN-LAN.

Требуется расширение решения для получения будущего запроса от прокси:

Конечно, это верно для ответов SIP.Однако то же самое относится и к будущим запросам, отправленным службами SIP, которые должны быть отправлены в заголовок контакта.Те же ограничения существуют для заголовков контактов, и поэтому я хотел бы прочитать и реализовать rfc5626

Худшее решение: SIP ALG

Спецификация SIP, а также некоторые расширения ( rfc3581 и rfc5626 ) - лучший способ работы SIP.SIP ALG, изменяющий содержание sip, всегда был одной большой точкой отказа.Об этом стоит говорить, потому что многие думают, что это было единственное решение.(Я очень не согласен)

Ваш вопрос: почему SIP-серверы нарушают rfc?

Существует только один способ отправить ответ UDP (и переслать запрос SIP),Если серверы повторно не используют «обратный путь UDP»:

• ответ на запрос REGISTER будет отброшен NAT ...
• входящий вызов (INVITE) будет отброшенпо NAT ...

Таким образом, с точки зрения прокси-сервера нет причин не нарушать rfc.В большинстве случаев на прокси нарушение Via и Contact решит проблему отсутствия расширения на SIP-клиентах.Это может нарушить работу некоторых SIP-клиентов за ALG, но в любом случае мне не нравится ALG;)