Re: _outboundsip._udp

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Wed 22 Feb 2006 - 22:08:33 MSK

On Wed, 22 Feb 2006 22:18:27 +0600
  "Victor Sudakov" <CGatePro@mx.ru> wrote:

>> Для вашего удобства я переведу и прокомментирую оба абзаца по второй 
>>ссылке.

>
> [dd]
>> 
>> "Чтобы позволить другим пользователям совершать звонки клиенту, 
>> расположенному за NAT, CGatePro сохраняет открытой дырочку между 
>> клиентом и сервером, периодически отправляя клиенту фиктивные пакеты. 
>> Используйте установочный параметр Ping NATed Clients для указания 
>> частоты, с которой Сервер должен отправлять эти пакеты". /* И фиктивные, 
>> и рабочие пакеты отправляются на 1054, а не на 5060. */

>
> Ну. А на 1054 никто не слушает, UA слушает на 5060 (смотрим
> подчеркнутое), да только NAT откуда об этом узнает.
>
> Может я недостаточно ясно формулирую вопрос? Вот UA посылает запрос с
> адреса 10.0.0.1:4567.

Какой запрос? STUN, REGISTER, любой другой SIP?
> NAT транслирует адрес источника в 212.73.127.1:4567.
> При этом в его таблице создается запись:
>
> Global 212.73.127.1(4567) Local 10.0.0.1(4567)
>
> А UA уже забыл про 4567, прописал в Contact или Via порт 5060 и ждет на
>нем ответа. В таблице NAT про 5060 ничего нет. Будь CGP хоть трижды умный,
> ответ до UA не дойдет.

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

---
RFC 3261            SIP: Session Initiation Protocol           June 2002

    For unreliable unicast transports, the client transport MUST be
    prepared to receive responses on the source IP address from which the
    request is sent (as responses are sent back to the source address)
    and the port number in the "sent-by" field.  Furthermore, as with
    reliable transports, in certain cases the response will be sent
    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, с 
которого посылали, но и на том же порту.

Так что если у вас standard-compliant дивайс, то CGatePro его прекрасно 
поддержит. Как настоящий SBC. А не игрушечный :-). Игрушечные с выходом 4.3 
стали тоже выходить - из бузинессу :-).


> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:sudakov@sibptus.tomsk.ru
Sincerely, Vladimir
Получено Wed Feb 22 19:08:05 2006

Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:14:45 MSK