Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Не отправляются INVITE
АРТКОМ Форум > Форумы для специалистов > Техническая поддержка ipLDK
mike71
Понимаю что задача тривиальная, но решения пока найти не могу. Итак: станция ipLDK-60
VoIB: GS88H-B.1Ed
MPB: GS88PXC.8Bc JUN/08
SysType:ipLDK 60 OFFICE
PCADMIN: 3.7

Задача: выход на провайдера VoIP по 6. Для тестирования использую sipnet. На станции поднят LCR для выхода на ГТС через аналоговые CO без набора 9.
Все VoIP линии (7-14) принадлежат группе 2 СО.
Станция выполняет регистрацию на sip-прокси, но запросов INVITE я на выходе интерфейса VOIBE не фиксирую, хотя в окне трассировки mon, сообщение INVITE формируется. Вопрос, что сделано не так и почему запросы INVITE не отправляются. Ниже привожу дампы экрана.
Astra
Цитата(mike71 @ 28.8.2009, 11:20) *
Понимаю что задача тривиальная, но решения пока найти не могу. Итак: станция ipLDK-60
VoIB: GS88H-B.1Ed
MPB: GS88PXC.8Bc JUN/08
SysType:ipLDK 60 OFFICE
PCADMIN: 3.7

Задача: выход на провайдера VoIP по 6. Для тестирования использую sipnet. На станции поднят LCR для выхода на ГТС через аналоговые CO без набора 9.
Все VoIP линии (7-14) принадлежат группе 2 СО.
Станция выполняет регистрацию на sip-прокси, но запросов INVITE я на выходе интерфейса VOIBE не фиксирую, хотя в окне трассировки mon, сообщение INVITE формируется. Вопрос, что сделано не так и почему запросы INVITE не отправляются. Ниже привожу дампы экрана.

Посмотрите в теме форума от 23.12.2008г. "Помогите с настройкой VOIBE на sipnet.ru" На самом деле очень просто.
Для себя не много не понял по LCR. Почему стоит режим BOTH, а не INT?
harris
Цитата(Astra @ 28.8.2009, 12:01) *
Посмотрите в теме форума от 23.12.2008г. "Помогите с настройкой VOIBE на sipnet.ru" На самом деле очень просто.
Для себя не много не понял по LCR. Почему стоит режим BOTH, а не INT?

2 Astra:
Both = INT + COL. Т.е. проверять данный код и как внутренний код (INT LCR, сразу же при поднятии трубки) и как внешний код (СOL LCR, после набора кода доступа к исходящей связи, 9-ки например).
Я не встречал ситуаций, когда нужен именно код BOTH. Обычно либо INT, либо COL - это логично и понятно. Но вероятно, кому-то может пригодится и ситуация с BOTH.

В данном случае, поскольку коды набираются сразу после поднятия трубки, то они срабатывают просто как коды типа INT. На работе это не сказывается, но указание типа INT было бы просто логичней и наглядней.
mike71
ставили и INT и BOTH - результат одинаковый - связи нет.
При анализе сетевых пакетов Wireshark-ом на тестовый SIP proxy - регистрацию видим (Register-> 200ok),
а Invite-а в канале нет, хотя в трассировке платы он есть (((
Вот почему его нет ? Куда он отправляется ?
harris
Цитата(mike71 @ 28.8.2009, 12:25) *
ставили и INT и BOTH - результат одинаковый - связи нет.
При анализе сетевых пакетов Wireshark-ом на тестовый SIP proxy - регистрацию видим (Register-> 200ok),
а Invite-а в канале нет, хотя в трассировке платы он есть (((
Вот почему его нет ? Куда он отправляется ?

Я как раз и говорю о том, что в данном случае BOTH и INT - это одно и тоже (срабатывает все равно как код типа INT !!!).

Каналы, используемые для осуществления VoIP-вызовов, должны быть описаны в ПГМ322!!!!
Т.е. в ПГМ322 нужно линии 7-14 прописать в сетевой транк (назначить сетевую группу типа PSTN) и указать там, что этот транк использует протокол SIP.
mike71
прилагаю скрин
Astra
Цитата(mike71 @ 28.8.2009, 13:38) *
прилагаю скрин

Почему у Вас DTMF MODE RFC2833? По умолчанию Inband DTMF, так прописано и в настройках платы VOIB.
mike71
а при чем здесь режим передачи DTMF? Насколько я понимаю сообщение INVITE должно формироваться после окончания набора номера вызываемого абонента, а DTMF посылки в режиме inband могут быть переданы в RTP пакетах уже после передачи INVITE и согласования параметров передачи контента (после получения 200 ОК от вызываемой стороны) и открытия RTP потоков.
mike71
И еще вопрос: что должно быть в 324, как я понял в моем случае направление на SIP будет маршрутизироваться посредством LCR. Нужно ли указывать направление на SIP в 324?
Astra
Цитата(mike71 @ 28.8.2009, 17:48) *
а при чем здесь режим передачи DTMF? Насколько я понимаю сообщение INVITE должно формироваться после окончания набора номера вызываемого абонента, а DTMF посылки в режиме inband могут быть переданы в RTP пакетах уже после передачи INVITE и согласования параметров передачи контента (после получения 200 ОК от вызываемой стороны) и открытия RTP потоков.

Трудно сказать. Сначало INVITE, затем 100 Trying, 180 Ringing и 200 ОК. Посмотрите присылается ли ACK и регистрируются ли разговоры в статистике sipnet.
mike71
кроме сообщений REGISTER и ответов 200 ОК на них ничего не передается.
Astra
Цитата(mike71 @ 28.8.2009, 18:19) *
кроме сообщений REGISTER и ответов 200 ОК на них ничего не передается.

Если все сделано правильно сервер sipnet должен отправить 200 ОК, а станция отправить подтверждение ACK. У меня было один раз, когда плата VOIBE зависла и не отправляла ACK, но скорее всего станция просто не получает ОК из-за настроек маршрутизатора или NAT. Но если пакеты проходят в sipnet они точно Вам скажут в чем причина. Тех. поддержка у них работает хорошо.
2. В настройках 324 ничего не надо указывать - ведь SIP это внешнее направление т.е. PSTN, а 324 это для линий NET т.е. межстанционных (внутренних). В LCR просто направляете коды нужные коды на группу линий SIP - у Вас 2.
mike71
Как я понял по спецификации SIP 3261, в процессе регистрации после 200 ОК финальное подтверждение ACK не передается.
Astra
Цитата(mike71 @ 28.8.2009, 19:22) *
Как я понял по спецификации SIP 3261, в процессе регистрации после 200 ОК финальное подтверждение ACK не передается.

Ну не знаю. В трубке хоть что-нибудь слышите?
mike71
после набора номера и # тишина
mike71
может быть выполнить анализ трассировки из mon?
Astra
Цитата(mike71 @ 28.8.2009, 20:04) *
может быть выполнить анализ трассировки из mon?

Для начала попробуйте набрать номер с системного телефона. Посмотрите какая занимается линия. Должна быть из группы SIP. Набор обязательно блоком. Если занимается нужная линия уже хорошо. Дальше будем думать почему набор не уходит.
mike71
по трассировке видно что занимается 14-я линия. также это подтверждается выводом состояния портов платы VOIB
mike71
Возможна ли проблема из-за параметра Call Type в 143. У меня он national, а не subscriber. А также индексы CLIP и COLP не установлены
Astra
Цитата(mike71 @ 28.8.2009, 23:12) *
Возможна ли проблема из-за параметра Call Type в 143. У меня он national, а не subscriber. А также индексы CLIP и COLP не установлены

У меня работает со следующими параметрами: индексы CLIP и COLP по 50,national, CLI transit - ORI. Остальное такое же.
vldmr
для начала версии обновите на станции и VoIB - см на сайте

Contact number - тот что Вам дали в SIPNET ( 2643689)
mike71
Проблема решена, оказалось что в данной плате VOIB только 4 первых канала активны для VoIP ( т.е. 7-10 в общей нумерации каналов CO ), а система почему-то занимала постоянно 14. Спасибо за консультации и поддержку.
harris
Цитата(mike71 @ 1.9.2009, 1:28) *
Проблема решена, оказалось что в данной плате VOIB только 4 первых канала активны для VoIP ( т.е. 7-10 в общей нумерации каналов CO ), а система почему-то занимала постоянно 14. Спасибо за консультации и поддержку.

blink.gif
На плате VOIM - 4 канала VoIP. При установки модуля расширения каналов - VOIU - кол-во каналов увеличивается до 8.
У Вас модуль VOIU установлен??? Прописан????
mike71
Нет, платы расширения нет. Хотя в конфигурации VOIB платы присутствуют 8 каналов ( 7-14 ).
harris
Цитата(mike71 @ 1.9.2009, 10:24) *
Нет, платы расширения нет. Хотя в конфигурации VOIB платы присутствуют 8 каналов ( 7-14 ).

Значит они там не должны присутствовать!!!
Если у Вас физически не установлен модуль VOIU на плате VOIM,
то в ПГМ101 для платы VOIM должно быть указано только 4 канала!!

Как получилось, что там у Вас прописано 8 каналов??? При исходной инициализации ("с нуля") станция сама прописывает кол-во каналов, обеспеченных "железом".
Вы что, добавляли плату VOIM позже и сами указали в ПГМ101 наличие 8 каналов???
mike71
Сегодня вечером постараюсь проверить. Плату расширения я не прописывал.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2025 IPS, Inc.