error,
Да не сложно, конечно. Просто занят был другим.
Я так понимаю Connect пришел в 1994212550ms. Потом от провайдера пришел алёрт в 1994218910 ms (через 6,3 секунды я сбросил вызов). Дисконнект прошел в 1994226020 ms (через еще 7,1 секунды я положил трубу на alcatel телефоне, с которого звонил).
Вместо алерта от isp должен был busy прийти? Я правильно понимаю? Или алерт и есть сигнал на разрыв соединения?
P.S.
Вот лог с той же циски, через другого sip провайдера. Тут написано - user busy.

vad, Неее. Если коннект проходит (вызываемый берет трубу), тогда все хорошо и дальше разрыв идет нормально. Беда если до коннекта сброс или абонент занят. В трубу идут короткие гудки, но обрыва не происходит (после 32 гудков - появляется надпись user busy в t3 и ЗАНЯТО на аппарате, гудки становятся еще короче и после этого происходит сброс. Но проходит секунд 30 наверное(точно не засекал)). Снифером попозже займусь.

На тестовой (h1.301.38)станции отключил фаст старт ребутнул gd, на incoming leg cisco - voice class h323 -> call start slow. Проблема сохранилась.
Плюсом проверил на этой же циске еще два других сиповых провайдера - таких проблем нет. Пока оставил заявку в техподдержку провайдера. Может они у себя че найдут.
К сожалению на счет cube и настройки туннелинга мне тут явно надо учить матчасть
Cube воообще существует для прошивок 12,4T ?

vad,   Пока пробовал на двух станциях. С релизами - g1.503-35h и f5.401.36b. Так же на пробовал на тестовом астериске ситуация аналогична алкателям. Щас попробую на других релизах поиграться.
error, Звонил разным операторам - никакой разницы. Для faststart нужна перезагрузка плат?

А на счет тон детектора? Он работает на IP тг?

Вот че т3 видит:
____________________________________________________________­__________________
| (364526:000002) 1137: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 115  desti: 0  source: 15  cryst: 2  cpl: 0  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05] Call ref : 65 02
|____________________________________________________________­__________________
|
| [9f] Non-locking shift. codeset : 7
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7
| IE:[05] EI_IP_INFOS (l=9) -> G723 Ece 1 Vad 0 Profil 2, IPv4 :192.168.100.1.
| [9f] Non-locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 1 Vad 0
| [9f] Non-locking shift. codeset : 7
| IE:[07] EI_IP_QOS (l=3) b8 a0 00
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
|    -> Port RTP     = 32704, IPv4 :   192.  168.    1.  236.
|    -> Port RTCP SR = 32705, IPv4 :   192.  168.    1.  236.
|    -> Port RTCP RR = 32705, IPv4 :   192.  168.    1.  236.
|    -> Port Fax     = 32707, IPv4 :   192.  168.    1.  236.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a8 83 81 -> T2 : No B channel
| IE:[6c] CALLING_NUMBER (l=6) -> 01 81 Num : 1717
| IE:[70] CALLED_NUMBER (l=15) -> 81 Num : #2189123456789
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (364528:000005) Physical-Event :
| long: 21  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  e5 02
|____________________________________________________________­__________________
|
| IE:[18] CHANNEL (l=1) a8 -> T2 : No B channel
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (364702:000006) Physical-Event :
| long: 61  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : ALERT (01)  Call ref :  e5 02
|____________________________________________________________­__________________
|
| IE:[1e] PROGRESS_ID (l=2) 80 88
| IE:[34] SIGNAL (l=1) 01
| [97] Locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 0 Vad 0
| IE:[0a] EI_RTP_INFO (l=30)
|    -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
|    -> Transm_Bande=0 detection_Q23=1
|    -> Port RTP     = 19316, IPv4 :   192.  168.  100.    1.
|    -> Port RTCP SR = 19317, IPv4 :   192.  168.  100.    1.
|    -> Port RTCP RR = 19317, IPv4 :   192.  168.  100.    1.
|    -> Port Fax     = 0, IPv4 :     0.    0.    0.    0.
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (364767:000008) Physical-Event :
| long: 58  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : PROGRESS (03)  Call ref :  e5 02
|____________________________________________________________­__________________
|
| IE:[1e] PROGRESS_ID (l=2) 80 88
| [97] Locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 0 Vad 0
| IE:[0a] EI_RTP_INFO (l=30)
|    -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
|    -> Transm_Bande=0 detection_Q23=1
|    -> Port RTP     = 19316, IPv4 :   192.  168.  100.    1.
|    -> Port RTCP SR = 19317, IPv4 :   192.  168.  100.    1.
|    -> Port RTCP RR = 19317, IPv4 :   192.  168.  100.    1.
|    -> Port Fax     = 0, IPv4 :     0.    0.    0.    0.
|____________________________________________________________­__________________

Последний блок - когда нажимается сброс на called аппарате. Номер #2189123456789 подменяется циской на мой сотовый.

Обнаружилась новая проблема в той же конфигурации=(
Звонок с cisco отправляется на sip-провайдера. Если called абонент сбрасывает вызов - то на стороне абонента Alcatel идут короткие гудки, а на экране надпись - "Вызывается". Через 32 гудка следуют более короткие гудки и уже тогда следует отбой. На циске пока идут 32 гудка висят два лега (h323 до алкатель и sip до провайдера). Такое ощущение, что по сипу пришел отбой, циска его неправильно съела и повисла сессия. И в этой время циска выдает какие то непонятные тоны на алкатель
Раньше связь между alcatel и cisco была через медные порты. И эта проблема решалась настройкой Tone Detector. Щас пытаюсь поколдовать с этим - не получается.
Вообще тон детектор на ip тг работает? и куда вообще копать.

Ну я на cisco подаю #100"номер". А можно подать "номер"#100
?

Прошу прощения за невнимательность . И правда работает. А в конец номера можно как-нибудь дописать?

error,
Ну вы все правильно пишите и так работать будет без лишних цифр на экране телефона. Только у меня задача другая. Я хочу чтобы моя cisco увидела от alcatel какой нибудь префикс (желательно с решеткой) и уже на основании этого префикса роутила (например если к ней подключены несколько сиповых провайдеров). По такой схеме тоже все работает, только на экране абонента alcatel проскакивает лишние цифры в номере.

error,
да - h323
vad,
Да это все правильно. Просто этот дополнительный префикс #100 будет используется оборудованием после alcatel. Этот префикс увидит cisco, и по нему перенаправит звонок дальше.

Это поле в SD стоит #*100 и эти цифры не отображаются (если как у меня выходить на SD через ARS). На экране дописывается то, что идет после #*100. А именно #100.

Здравствуйте все еще раз!
Ситуация такова:
1) Идет набор номера: 0 - выход на ARS, далее "номер"
2) В ARS (digits to add) alcatel добавляет цифры #*100#100 и ТГ = -1
3) Снова попадаем в префикс и видим - #*100 - выход на SD
4) C SD едем на IP ТГ и звонок уходит на cisco
5) Cisco по префиксу #100 уже принимает решение, что делать дальше.

Неудобство в том, что при наборе номера на экране телефона отображается #100"номер". Этот номер висит до тех пор, пока идет вызов. Когда трубку снимают - на экране отображается имя ТГ. Думаю пользователи будут пугаться при виде такого странного номера. Вопросов два:
1) Можно ли как-нибудь поиграться с отображаемым номером, который видят юзеры?
2) Можно ли как-нибудь дописать дополнительные цифры (например #100) в конце номера? NPD или еще как? И как это сделать?

Поставил галку на тестовой - и перезагрузил gd. Звонок оборвался.   Похоже надо было просто перезагрузить плату кодеков. Ночью перезагружу рабочие. Кстати за что эта галка отвечает?

Проблема в следующем.
Есть сеть 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. Какие-нибудь таймеры сессий или что-нибудь что может обрывать звонок. Или хотя бы как выцепить лог разговора на маршрутизаторе  

P.S. Cнимал - ставил галочку Round trip delay request - ставил никакой разницы. Не влияет ни на тестовую, ни на рабочие.

Да на тестовой сразу поменять не смог. Зато смог после обновления. Только что проделал это на рабочей. Все вроде работает. Диапазон тоже изменить можно.