Re: _outboundsip._udp

Vladimir A. Butenko wrote:
> >>
> >>"Чтобы позволить другим пользователям совершать звонки клиенту,
> >>расположенному за NAT, CGatePro сохраняет открытой дырочку между
> >>клиентом и сервером, периодически отправляя клиенту фиктивные пакеты.
> >>Используйте установочный параметр Ping NATed Clients для указания
> >>частоты, с которой Сервер должен отправлять эти пакеты". /* И фиктивные,
> >>и рабочие пакеты отправляются на 1054, а не на 5060. */
> >
> >Ну. А на 1054 никто не слушает, UA слушает на 5060 (смотрим
> >подчеркнутое), да только NAT откуда об этом узнает.
> >
> >Может я недостаточно ясно формулирую вопрос? Вот UA посылает запрос с
> >адреса 10.0.0.1:4567.
>
> Какой запрос? STUN, REGISTER, любой другой SIP? Не STUN, конечно, а любой SIP.

> 

> 
> Такие клиенты если еще и есть, то по ним трактор давно проехал. То есть 
> ожидается, естественно, что если клиент сидит за far-end firewall, и 
> оттуда, из-за NAT что-то булькает со своего порта X, то он должен уметь и 
> принять SIP траффик на этом порту X.

Хорошо, если это соблюдается, например как в DNS.

> 
> Заметим, что даже среди сильно кривых клиентов, можно видеть следующее: 
> послал с порта X, прописал в хедерах порт Y, но на X тоже слушает. И, что 
> самое удивительное, это еще и в стандарте прописано:

А вот в стандарте прописано несколько иное, если я конечно правильно истолковал.

>    elsewhere.  The client MUST be prepared to receive responses on any
>    address and port that would be selected by a server based on the
>    procedures described in Section 5 of [4].
> ---
> 
> вот это вот милое "elsewhere" и ссылка на Section 5 в другом RFC говорят 
> Вам о том, что Вы должны уметь получить SIP траффик не только на том IP, с 
> которого посылали, но и на том же порту.

Не-а. Section 5 в RFC3263 говорит другое:

   In these cases, the server examines the value of the sent-by    construction in the topmost Via header. If it contains a numeric IP    address, the server attempts to send the response to that address,    using the transport protocol from the Via header, and the port from    sent-by, if present, else the default for that transport protocol.    The transport protocol in the Via header can indicate "TLS", which    refers to TLS over TCP. When this value is present, the server MUST    use TLS over TCP to send the response.

   If, however, the sent-by field contained a domain name and a port    number, the server queries for A or AAAA records with that name. It    tries to send the response to each element on the resulting list of    IP addresses, using the port from the Via, and the transport protocol    from the Via (again, a value of TLS refers to TLS over TCP). As in    the client processing, the next entry in the list is tried if the one    before it results in a failure.

   If, however, the sent-by field contained a domain name and no port,    the server queries for SRV records at that domain name using the    service identifier "_sips" if the Via transport is "TLS", "_sip"    otherwise, and the transport from the topmost Via header ("TLS"    implies that the transport protocol in the SRV query is TCP). The    resulting list is sorted as described in [2], and the response is    sent to the topmost element on the new list described there. If that    results in a failure, the next entry on the list is tried.

Если обломились послать по порту, указанному в Via, или в Via вообще нет порта, то посылать следует не на тот порт, откуда пришёл запрос, а а) на порт по умолчанию для данного протокола или б) согласно SRV-записи, а она как известно определяет и порт.

Как видите, порт c которого посылали (в Вашем примере порт X) тут никак фигурировать не будет. Если, конечно, Вы покажете в стандарте место, где написано "послать ответ можно на тот порт, с которого пришёл запрос", тогда дело другое, но я не увидел.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru