Re: _outboundsip._udp

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Fri 24 Feb 2006 - 13:46:35 MSK

On Thu, 23 Feb 2006 17:04:15 +0600
  "Victor Sudakov" <CGatePro@mx.ru> wrote:
> Vladimir A. Butenko wrote:

>> >Может я недостаточно ясно формулирую вопрос? Вот UA посылает запрос с
>> >адреса 10.0.0.1:4567.
>> 
>> Какой запрос? STUN, REGISTER, любой другой SIP?

>
> Не STUN, конечно, а любой SIP.
Почему "конечно". Сейчас на SIP-листе бурно обсуждается, не сделать ли еще и STUN унутре 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.

>
> Хорошо, если это соблюдается, например как в 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 говорит другое:
>

Да, я с прямым углом перепутал.

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

Это, в общем-то - RFC3581. Клиент говорит, что он его поддерживает, при помощи вставки слова "rport" в свой Via. Но мы считаем, что клиент его поддерживает всегда, если он за far-end NAT. Потому что если он играет разными портами, и, к тому же, не слышит на том своём порту, с которого он посылает - то работать это через NAT не будет. Поэтому CGatePro с far-end NAT клиентами работает по-другому, не так, как написано в стандарте. А начиная с 5.0.7, кажется - еще и пишет всякие upport в свои Via чтобы поддерживать клиентов, которые rport не пишут.

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

Sincerely,
Vladimir Получено Fri Feb 24 10:46:09 2006