Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1
RSS
Проблема с H323 транком, Разговор обрывается на 38 секунде
 
Проблема в следующем.
Есть сеть ABC-F (прошивки на станциях разные) соединенная через маршрутизаторы cisco. Также имеется тестовая alcatel (не в ABC-F) и тестовый астериск с h323-транком (просто для совершения тестовых звонков). Схема работы следующая:
1)На алкателе звоним например на номер 2002 и через ARS выходим на SD
2)В SD ip адрес следующего узла (например cisco 3825)
3)Дальше попадаем на IP ТГ (это та же ТГ, что используется для ABC-F связей)
4)Звонок приходит на cisco. Та посылаем звонок на астериск тоже по h323 (у которого есть исходный абонент 2002)
5)Итог. Все замечательно работает и идет разговор в течение 38 секунд. После чего следует обрыв.
Если позвонить в обратном направлении то же самое (38 секунд и обрыв).
(Астериск используется чисто как стендовая атс. На самом деле не имеет значения, что будет после cisco маршрутизатора - тфоп с е1 или sip isp, все равно звонок продлится 38 секунд.)
Ситуация изменится если из этой схемы исключить маршрутизатор cisco. Если звонок с alcatel бросить сразу в астериск - обрыва не будет.
Вы наверное подумаете, что дело в не в алкателе и я ошибся форумом. Но есть небольшое "но".
Существует тестовая станция не в ABC-F сети. На ней все прекрасно работает (через те же самые маршрутизаторы cisco). Единственное отличие, на мой взгляд, между тестовой и рабочими - то, что ТГ для h323 у тестовой станции не используется для abc-f. На тестовой станции выставил такие же настройки ТГ, как у рабочих (пытался ее "сломать")- все-равно работает без проблем. Кроме того если астериска позвонить на сотовый через cisco (cisco подключена к isp) - тоже все работает.
Кто инициатор обрыва непонятно. При обрыве t3 выдает следующее:
|____________________________________________________________­__________________
| (847699:000032) Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : RELEASE [4d] Call ref : e2 6c
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 a9 -> [a9] TEMPORARY FAILURE
|____________________________________________________________­__________________
Для себя сделал вывод: проблема в том, что ТГ для ABC-F не подходит для h323-транка.

У меня несколько вопросов к знатокам:
1) Можно ли для одной станции сделать насколько IP ТГ (одна для ABC-F, одна для H323 например)?
2) Нужно ли для этого выделить отдельную плату ga,gd или можно на 1 плату создать несколько IP ТГ?
3) Можно ли вывести плату ga,gd из ТГ используемую для сети ABC-F и чем это грозит?
4) Может кто-нибудь подскажет по настройке cisco. Какие-нибудь таймеры сессий или что-нибудь что может обрывать звонок. Или хотя бы как выцепить лог разговора на маршрутизаторе  :oops:

P.S. Cнимал - ставил галочку Round trip delay request - ставил никакой разницы. Не влияет ни на тестовую, ни на рабочие.
Изменено: Сергей Челышев - 10.01.2014 14:53:17
 
IP/IP parameters - round trip delay request. Выключите и будет вам счастье. Не внимательно прочитал - что вы ею пользовались. Не помню - надо ли VoIP плату после этого перегружать.
 
1) Приведите всю трассировку - у вас при установлении соединения (если проблема не в round trip delay request) - что-то отсутствует - например подтверждение сообщения Connect и соответственно соединение разваливается.
2) TG через которую идут сетевые звонки (VPN overflow) - обычная IP TG - H323, наличие второй TG вам ничего не даст. Или у вас ABC-F IP транковая группа (объединения разных сетей ABC-F, а не разных узлов внутри одной сети)?
 
Как работает ABC-F (VPN overflow - звонки внутри ОДНОЙ сети между РАЗНЫМИ узлами):
1) исходная позиция - есть обычная IP TG, ходят H323 звонки через SD.
2) станции (процессора) договариваются по IP о желании позвонить.
3) входящая сторона сообщает, а исходящая отзванивается на номер VPN префикса. При этом понимаем - что сигнализация идет отдельно (например IP между процессорами), а голос отдельно (ОБЫЧНЫЙ VoIP звонок на VPN overflow префикс).

Соответственно - ничего особого в IP TG нет (в отличии от Т2 - когда важна сигнализация в TG - ABC-F, QSIG, ISDN и т.д.)
 
Поставил галку на тестовой - и перезагрузил gd. Звонок оборвался.  :) Похоже надо было просто перезагрузить плату кодеков. Ночью перезагружу рабочие. Кстати за что эта галка отвечает?
 
По сути - измерение времени прохождения пакетов - некоторый аналог ping.
 
У вас проблема с настройкой циски.
Чтобы удостоверится что тут циска не приделах соедените тестовую охе с астериск без чего либо, уверен что будет работать если конечно охе не 7.0

По поводу узла с работающим h323 транком где-то вы еще скажите что версия софта охе совпадает до коппейки с тестовой
Пути IP-пакета неисповедимы
 
На моей памяти - все это связано с использованием round trip delay request. В свое время Алкатель и Циско кивали друг на друга (что проблема с противоположной стороны). Потом в Алкатель появилась возможность выключения данного пункта.

Больше проблем такого плана с Циско не встречалось.
Страницы: 1
Читают тему