Re: Медиа Проксирование SIP

От: Александр Жданович <CGatePro_at_mx_ru>
Дата: Tue 29 Jun 2010 - 08:23:59 MSD

28.06.2010 17:43, Dmitry Akindinov пишет:
> Здравствуйте,
>
> Subscriber wrote:
>> 25.06.2010 18:49, Dmitry Akindinov пишет:
>>> Здравствуйте,
>>>
>>> Subscriber wrote:
>>>> 25.06.2010 16:16, Nikolay A. Kostyakov пишет:
>>>>> Subscriber пишет:
>>>>>> Здравствуйте коллеги.
>>>>>> Подскажите пожалуйста, можно ли заставить CGP принудительно
>>>>>> медиа проксировать какую то конкретную учетную запись, несмотря
>>>>>> на то что ее айпи находится в Установки - LAN - Адреса LAN или
>>>>>> нет? Или это делается только например так
>>>>>> 10.200.50.1-10.200.50.24, 10.200.50.26-10.200.50.254
>>>>>> (10.200.50.25 - айпи клиента с требуемой учеткой)?
>>>>>> CGP естественно считает ее в своей сети и проксировать
>>>>>> отказывается, клиенты пытаются соединится напрямую. И если
>>>>>> архитектура VPN звездочка, CGP в центре и отсуствуют связи между
>>>>>> точками в лучах, соединения естно между точками в лучах не
>>>>>> происходит. Приходится изворачиваться.
>>>>>>
>>>>> Да , можно проксировать , через gatewayincoming, например,
>>>>> как то так:
>>>>> S:<proxy-(6d)@*> = gatewayincoming{*,media}#pbx
>>>> То есть если я хочу проксировать все от учетки 1111
>>>> N:S:<proxy-*@*> = gatewayincoming{1111,media}#pbx
>>>
>>> Нет. Чтобы особым образом отрабатываь звонки "от учётки" придётся
>>> использовать правила или все звонки пропускать через приложение, а в
>>> нём уже включать проксирование, в заисимости от того, кто звонит.
>>>
>> Извините, не могли бы вы объяснить как то понятнее. Правила для
>> SIP можно создать только для всего сервера?
>
> Нет, их можнос оздавать и на уровне аккаунта или домена, но эти
> правила применяются для входящих сигналов, адресованных локальным
> аккаунтам.
> Общесерверные правила применяются ко всему.
> Однако управлять медиапроксированием из правил нельзя, для этого
> звонок должен управляться B2BUA приложением.
>
Эх.. учите матчасть называется :( Просьба ссылку если можно с примерами, придется вычитывать как это придумать.

>> Но я не увидел там ничего похожего на проксирование.
>>
>>>> ?
>>>>>> Еще хотелось бы понять, допустим сервер с GGP имеет несколько
>>>>>> сетевых интерфейсов. В Установки - LAN - Адреса LAN - Адрес
>>>>>> Сервера в LAN - выставлен какой то из них. В IPv4 WAN Адреc -
>>>>>> прописано айпи внешнего инета смотрящего в инет. Но запрос для
>>>>>> коннекта SIP произодет на интерфейс который ни LAN ни WAN не
>>>>>> значится и клиент с айпи не входящей в Адреса LAN. Какой
>>>>>> интерфейс CGP подаст как прокси? Это как то управляется
>>>>>> принудительно для конкретной учетной записи?
>>>
>>> В качестве медиа прокси CGPro всегда (по крайней мере - в текущих
>>> версиях) открывает сокет на [0.0.0.0]. Таким образом проксируемые
>>> пакеты будут уходить с IP адресов, которые ОС считает "дефолтными"
>>> для соответствующих сетей. Чтобы это всё совпадало сзаявлениями
>>> CGPro в SDP, надо для WAN и LAN IP адресов выбирать соответствующие
>>> "дефолтные" IP. А потом ещё для SIP UDP сокетов рекомендуется
>>> создавать отдельные сокеты на выбранных WAN и LAN IP адресах а в
>>> конце списка - сокет на All Available ([0.0.0.0]).
>>>
>> Мой опыт говорит о другом :( . WAN и LAN прописаны небыли, сети
>> клиентов были указаны как свои и после перезагрузки сервера,
>> (которая случается не часто поэтому и проблема выплыла не сразу),
>> отвалилась связь, tcpdump показал, что CGP стал отдавать как прокси
>> интерфейс который не виден для клиента. Перезапуск и CGP стал
>> отдавать опять другой (третий) интерфейс. То есть CGP не
>> руководствовался маршрутами системы.
>
> Возможно, при этих перезапусках менялись и маршруты по умолчанию в
> системе? Правда жизни такова, что свои медиа сокета CGPro ни к какому
> IP адресу не привязывает.
Нет не менялись, это точно и когда CGP выдал интерфейс для проксирования клиенту смотрящий в демилитаризованную зону где маршрутов минимум и звонок происходил вовсе не оттуда, я был очень удивлен. Согласен ситуация непростая, клиент звонящий из под нат, его подсеть (внутренняя) совпадает с LAN и LAN и WAN не были прописаны и логика выдачи интерфейса проксирования была не ясна. А прикрутить принудительное проксирование клиенту с ходу решив проблему с нахрапу не получается, как то был уверен, что есть галка а ля астериск для этого :( учить матчать пропускать через приложение B2BUA. Хех... придется учить, раз уж купили.
>
>> То есть в WAN я должен указать тот интерфейс который я хочу что бы
>> отдавался как медиапрокси и возможности сделать этот прокси различным
>> для каждого клиента нельзя.
>
> В настройке WAN IP лежит подсказка серверу, что указывать в SDP, когда
> SIP пакет уходит не всторону LAN IPs.
>
>> >А потом ещё для SIP UDP сокетов рекомендуется создавать отдельные
>> сокеты на выбранных WAN и LAN IP адресах а в конце списка - сокет >
>> на All Available ([0.0.0.0]).
>>
>> В настройках Установки- Сеть- LAN - есть возможность выбрать только
>> диапазон портов, но я не нашел как сделать то о чем вы написали.
>
> Я написал, что полезно иметь SIP сокеты, созданными явно на разных
> интерфейсах, в в порядке предпочтительного их использования и сокетом
> на [0.0.0.0] в качестве замыкающего. Речь не шла о сокетах, которые
> используются медиаканалами и для медиапроксирования.
>
>> Если честно я вобще не нашел как привязать к какому либо интрефейсу
>> порты от 60000.
>
> Ещё раз: сокеты для локальных медиаканалов и медиа прокси открываются
> на [0.0.0.0], самим CGPro к определённому интерфейсу не привязываются.
> Всё решает IP стек ОС - с какого локального IP будет отправлен пакет.
>
>> CGP 5.3.4.
>>
>

-- 
С уважением, Александр Жданович
Получено Tue Jun 29 04:24:11 2010

Этот архив был сгенерирован hypermail 2.1.8 : Tue 29 Jun 2010 - 12:14:52 MSD