Полная версия этой страницы:
Не отправляются INVITE
Понимаю что задача тривиальная, но решения пока найти не могу. Итак: станция 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 не отправляются. Ниже привожу дампы экрана.
Цитата(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?
Цитата(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 было бы просто логичней и наглядней.
ставили и INT и BOTH - результат одинаковый - связи нет.
При анализе сетевых пакетов Wireshark-ом на тестовый SIP proxy - регистрацию видим (Register-> 200ok),
а Invite-а в канале нет, хотя в трассировке платы он есть (((
Вот почему его нет ? Куда он отправляется ?
Цитата(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 @ 28.8.2009, 13:38)

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

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

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

Как я понял по спецификации SIP 3261, в процессе регистрации после 200 ОК финальное подтверждение ACK не передается.
Ну не знаю. В трубке хоть что-нибудь слышите?
после набора номера и # тишина
может быть выполнить анализ трассировки из mon?
Цитата(mike71 @ 28.8.2009, 20:04)

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

Возможна ли проблема из-за параметра Call Type в 143. У меня он national, а не subscriber. А также индексы CLIP и COLP не установлены
У меня работает со следующими параметрами: индексы CLIP и COLP по 50,national, CLI transit - ORI. Остальное такое же.
для начала версии обновите на станции и VoIB - см на сайте
Contact number - тот что Вам дали в SIPNET ( 2643689)
Проблема решена, оказалось что в данной плате VOIB только 4 первых канала активны для VoIP ( т.е. 7-10 в общей нумерации каналов CO ), а система почему-то занимала постоянно 14. Спасибо за консультации и поддержку.
Цитата(mike71 @ 1.9.2009, 1:28)

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

Нет, платы расширения нет. Хотя в конфигурации VOIB платы присутствуют 8 каналов ( 7-14 ).
Значит они там не должны присутствовать!!!
Если у Вас физически не установлен модуль VOIU на плате VOIM,
то в ПГМ101 для платы VOIM должно быть указано только 4 канала!!
Как получилось, что там у Вас прописано 8 каналов??? При исходной инициализации ("с нуля") станция сама прописывает кол-во каналов, обеспеченных "железом".
Вы что, добавляли плату VOIM позже и сами указали в ПГМ101 наличие 8 каналов???
Сегодня вечером постараюсь проверить. Плату расширения я не прописывал.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.