Re: Re: проксирование media stream

Здравствуйте,

Victor Sudakov wrote:
> Dmitry Akindinov wrote:

>>> Есть локальная сеть без выхода в Интернет (даже через NAT) и сервер
>>> CGP 4.3.8 с двумя интерфейсами (один в данной локальной сети, другой с
>>> публичным адресом).
>> А 5.0.3 использовать есть возможность?

Там постоянно что-то меняется. А многие проблемы с проксированием медиа проявились при использовании PBX приложений - уже в версии 5.0.х. Тк что, если есть возможность использовать 5.0.3 - лучше использовать эту версию.

>>> Наблюдается такая вещь. Иногда при попытке разговора (проявляется
>>> только с _некоторыми_ собеседниками за пределами локальной сети)
>>> tcpdump на рабочей станции показывает, что голосовой трафик пытается
>>> из моего WM 5.1 идти напрямую на публичный адрес UA собеседника,
>>> соответственно голосом поговорить не удаётся.  В большинстве же
>>> случаев всё нормально: голосовой трафик тоже идёт через CGP.
>>>
>>> В каких ситуация возможно такое, что проксирование не работает (не
>>> срабатывает)? Откуда WM узнаёт, должен ли он слать голосовой трафик
>>> напрямую или через CGP в качестве media proxy?
>> При достаточном уровне логов это должно быть видно в запросах INVITE и 
>> ответах 200 на эти запросы. Данные в таких пакетах обычно - это SDP, в 
>> котором вам будут интересны атрибуты 'c' (из которого можно узнать IP 
>> адрес RTP соединения) и 'm' (номер порта, помимо прочего).

Клиент шлет запрос CGPro "я по адресу 10.1.0.83, порт 2278". Понятно, что если этот адрес попадает в разряд NAT'ed (согласно настройкам сервера), наружу такое сервер не отдаст. Вместо этого скажет "85.64.73.29, 60002", где 85.64.73.29 - внешний адрес сервера (WAN). Это - near-end NAT traversal.
А может быть наоборот - из интернета приходит запрос, а в теле - "серые" адреса. Это far-end, и за решение только этой проблемы приходилось выкладывать немалые деньги.

> Ведь UA на той стороне не может знать, что
> мой UA должен направить media stream не в Интернет, а на внутренний
> интерфейс моего CGP сервера. Т.е. UA на той стороне поставит туда свой IP.

>> Ломаться что-то может, если клиент снаружи пришел из-за NAT файрвола, но 
>> это так, догадки.

Лучше бы попробовать с выключенным и внимательно посмотреть на логи.

> 2) пробовали делать статическую трансляцию для его машинки, но это не
> помогло.

Да и вряд ли поможет - порты для RTP назначаются динамически и, многими клиентами, даже без возможности указать диапазон.

> А какая топология должна быть на той стороне, чтобы ломалось?

Вот как раз такой файрвол, пытающийся сам поддержать протоколы, для работы через NAT в общем-то не предназначенные. Там пакет может приходить с одного адреса, заголовки - говорить о других, а в теле (SDP) - может быть вообще что-то третье. И вот все это аккуратно надо замаскировать. Если CGPro видит нетронутый пакет, по которому видно, что он пришел из-за NATа - с ним можно поработать. А вот если над ним уже поработали различные fixup'ы, но не доделали - то будут проблемы.

-- 
Best regards,
Dmitry Akindinov -- Stalker Labs.