RE: не регистрируется на sip шлюзе AlterPSS

От: Эдуард Ковалев <CGatePro_at_mx_ru>
Дата: Fri 27 Feb 2009 - 11:17:47 MSK


Может кто сталкивался с регистрацией CGP в AlterPSS? Танцы с бубном пока ни к чему не привели...

> -----Original Message-----
> From: CommuniGate Pro Russian Discussions [mailto:CGatePro@mx.ru]
> Sent: Friday, January 30, 2009 3:38 PM
> To: CommuniGate Pro Russian Discussions
> Subject: Re: [CGP] не регистрируется на sip шлюзе
>
> Здравствуйте,
>
> Andrew V.Statsenko wrote:
> > В Птн, 30/01/2009 в 13:17 +0300, Dmitry Akindinov пишет:
> >> Здравствуйте,
> >>
> >> Эдуард Ковалев wrote:
> >>>>>> 3. Можно разрешить релеинг запросов с машины с eyebeam и
> настроить
> >>>> его
> >>>>>> чтобы CGPro использовался в качестве прокси. Сравнить запросы на
> >>>>>> регистрацию, которые сервер проксирует от eyebeam с теми, что
> сервер
> >>>>>> посылает сам.
> >>>>> Где прочитать как настроить? (ткните плз в раздел справки)
> >>>> В webAdmin ->settings -> Real-Time - SIP -> Sending -> protocol ->
> >>>> Relay
> >>>> to Any IP Address for: clients и добавьте IP, с которого работает
> >>>> айБим,
> >>>> в список клиентских.
> >>>>
> >>>> В айБиме укажите IP сервера в качестве адреса прокси.
> >>> Айбим через CGP регистрируется, но когда пытаюсь позвонить извне -
> сбрасывает на занято, причем в логах CGP входящий звонок фиксируется
> >>> Если регистрируюсь айбимом напрямую - звонок доходит
> >>>
> >>> Лог со звонком:
> >>>
> >>> 22:19:12.546 5 SIP [0.0.0.0]:5060 <- [88.87.64.228]:5060 inp(803):
> INVITE sip:xxxxxx@94.180.199.34 SIP/2.0\r\nVia: SIP/2.0/UDP
> 88.87.64.228;branch=88
> >>> 22:19:12.546 2 SIPDATA-001614 inp: req [0.0.0.0]:5060 <-
> udp[88.87.64.228]:5060 INVITE(803 bytes) sip:xxxxxx@94.180.199.34
> >> Ерунда какая-то. При регистрации айБим (если звонок вообще идет на
> рего
> >> регистрацию) указывал
> >> Contact: <sip:xxxxxx@192.168.0.12:7106;rinstance=6d9c8a8acf3ad8d8>
> >> и сервер вставлял еще
> >> Path: <sip:94.180.199.34:5060;lr>
> >
> > Есть сильное подозрение, что AlterPPS, собственно, не умеет PATH.
> >
> > Насколько видно по логу шлюз в ответ на REGISTER возвращает 200 OK в
> > котором
> >
> > Supported: path
> > Path: <sip:94.180.199.34:5060;lr>
> >
> > как-то совершенно не просматривается.
>
> Кстати - да. Спасибо за подсказку. Можно попробовать добавить IP этого
> шлюза в WebAdmin -> Settings -> Real-Time -> SIP -> Workarounds ->
> Domain Name и включить галочку noPath. Может помочь.

[Эдуард Ковалев]
> тем не менее CGP продолжает вставлять Path
[техподдержка]
Да, для исходящих регистраций этот workaround сейчас не используется, к сожалению. Точнее - заголовок все равно вставляется, с расчетом на то, что шлюз, не поддерживающий Path, его просто проигнорирует. Здесь же шлюз пытается использовать его значение во входящих звонках и, по-видимому, при регистрации, но всегда неправильно. Пока ничего поделать нельзя - напишу разработчикам, возможно получится не вставлять этот заголовок совсем.

[Эдуард Ковалев]
> дополнительно попробовал подключить eyebeam к провайдеру через CGP:
1. если стоит NoPath, то eyebeam не авторизуется 2. если выключить компенсацию NoPath, то eyebeam авторизуется и совершает исходящие звонки, однако входящие звонки не приходят   - похоже alterpss звонит на хххххх@94.180.227.3 и CGP резонно полагает что звонок ему, не находя номер - отвергает 3. при подключении eyebeam напрямую (без CGP) оказалось не все так радужно:   - исходящие звонки проходят через раз (закономерность определить не хватает опыта, единственное выявлено, что после регистрации должно пройти некоторое время, примерно 5 мин)   - тем не менее входящие звонки приходят

> >> Здесь же шлюз присылает запрос на URI, который явно является
> производным
> >> из этих двух URI, что неправильно. Правильно послать запрос на адрес
> в
> >> Path и в RURI использовать URI из Contact регистрации. Допустимо в
> RURI
> >> указать адрес из Path, а URI из Contact регистрации вставить в виде
> >> заголовка Route.
> >
> > А видя Contact:
> > <sip:xxxxxx@192.168.0.12:7106;rinstance=6d9c8a8acf3ad8d8> с серым IP
> и
> > rport пытается таким своеобразным способом решать задачу NAT
> travesal.
> >
> > Как вариант решения - в AlterPPS направить звонок на CGP не через
> > регистрацию, а через route, ну и на CGP поймать этот "route".
> >
> >
> > В Альтертехе, AFAIR, вообще сообственное представление о SIP'е.
> >
> >
> > ---
> > С уважением,
> > Андрей Стаценко
>
> --
> Best regards,
> Dmitry Akindinov -- Stalker Labs.
Получено Fri Feb 27 08:18:00 2009

Этот архив был сгенерирован hypermail 2.1.8 : Fri 27 Feb 2009 - 12:14:39 MSK