Уважаемые коллеги, может кто сталкивался с такой проблемой:
Есть Циска 3845 ССМЕ - от оператора связи приходит поток 2ВСК. Для конвертации 2ВСК в PRI понимаемый Циской используем отечественную транзитную АТС переваривающую оба стандарта. На Циске настроен TCL-скрипт - реализующий функциональность IVR (то есть просто говорилка дающая возможность набрать внутренний номер абонента или дождаться ответа секретаря). Проблема в том что при звонке на номер выделенный для IVR с местных линий связи (городских телефонов) вызов проходит нормально - вызывающий абонент слышит звуковое сообщение, а при междугороднем звонке на то же номер, вызов отбивается после 10-15 сек. паузы, притом что междугородние вызовы на абонентов с закрепленными внешними номерами проходят нормально - связь устанавливается. Исходящие вызовы тоже нормально работают.
Информация о возможных решениях поступает противоречивая:
- связисты поставившие анализатор вызовов на АТС оператора связи заявили о том что якобы со стороны нашего оборудования приходит запрос АОН (на транзитной АТС отключен), полсе этого соединения рвется.
- изготовители транзитной АТС заявили буквально следующее: "проблема в том что циска при неуспешном вызове не видит сигнал подтверждения соединения CONNECT ASK от транзитной АТС и по выдержке получает DISCONNECT Поэтому соединение рвется" Почему тогда входящие городские вызовы дозваниваются на IVR непонятно.На потоке 2 ВСК 1-15 канальные интерфейсы служат для входящих городских вызовов, 16-24 исходящие вызовы, 25-30 входящие междугородние вызовы.
Дебаг при вызове на IVR:
Jan 7 04:20:41.247 XXX: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x01AD
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98389
Exclusive, Channel 9
Called Party Number i = 0x80, 'XXXX'
Plan:Unknown, Type:Unknown
Jan 7 04:20:41.255 KRS: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x81AD
Channel ID i = 0xA98389
Exclusive, Channel 9
Jan 7 04:20:41.255 KRS: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x81AD
Jan 7 04:20:41.287 KRS: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01AD
Jan 7 04:20:41.287 KRS: %ISDN-6-CONNECT: Interface Serial0/1/0:8 is now connected to N/A N/A
Jan 7 04:20:47.287 KRS: %ISDN-6-CONNECT: Interface Serial0/1/0:8 is now connected to N/A N/A
Jan 7 04:20:55.446 KRS: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8 callref= 0x01AD
Cause i = 0x8390 - Normal call clearing
Jan 7 04:20:55.446 KRS: %ISDN-6-DISCONNECT: Interface Serial0/1/0:8 disconnected from unknown , call lasted 14 seconds
Jan 7 04:20:55.446 KRS: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x81AD
незнаю как у Вас,а у нас 2ВСК линии для междугородних соединений были отдельные и имели свою "междугороднюю" сигнализацию. Если линии перепутать - эффект был именно такой.
формулировка "не видит CONNECT_ACK" довольно странная, учитывая что реакции на CONN ACK стандартом вроде не предусмотрено. Время поинтересоваться - а какую реакацию на CONN ACK ожидает АТС?А интересно АТС-конвертор какая?
>незнаю как у Вас,а у нас 2ВСК линии для междугородних соединений были
>отдельные и имели свою "междугороднюю" сигнализацию. Если линии перепутать
> - эффект был именно такой.Да, входящие вызовы приходят на указанные оператором КИ с 25 по 30 (КИ - канальные интерфейсы - в терминологии производителя транзитной АТС). Междугородние вызовы проходят, но только на выделенные номера для внутренних абонентов. Конвертер - MP-4 Питерской компании МТА http://www.m-200.com
А отклик с Циски должен быть типа сигнал Alert при звонке на закрепленный за абонентом внешний номер он приходит, а при звонке на IVR - нет. Я уж его и в скрипте прописал:
proc act_Setup { } {
global dest
global beepset beep 0
puts "\n proc act_Setup started"
leg alert leg_incoming -p 8
И на интерфейсе:interface Serial0/1/0:15
no ip address
encapsulation hdlc
no snmp trap link-status
isdn switch-type primary-net5
isdn incoming-voice voice
isdn send-alertingПока толку нет......
>А отклик с Циски должен быть типа сигнал Alert при звонке на
>закрепленный за абонентом внешний номер он приходит, а при звонке на
>IVR - нет.посмотрел на своей работующей CISCO c IVR (isdn PRI подключение)
нет никакого сигнала после CONNECT ACK и до DISCONNECTсигнал ALERTING означает что пошел сигнал КПВ. приходит он _до_ CONNECT\CONNECT ACK
в случае с IVR его нет и не должно быть, поскольку соединение происходит сразуже по приходу вызова.Можно попробовать в скрипте перед ответом ждать 5-10сек, тогда ALERTING появтся наверное.
а еще можно попробовать поставить на входящем dial-peer
чтото вродеtone ringback alert-no-PI
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
>а еще можно попробовать поставить на входящем dial-peer
>чтото вроде
>
>tone ringback alert-no-PI
>progress_ind alert enable 8
>progress_ind progress enable 8
>progress_ind connect enable 8Первую команду я подставил. А последних трех у меня нет.
Снял трассировку вызова с транзитной АТС:
#ID Time Dir PCM #1 SORM PCM #2 DSS1
101 610270.668 <-- TX SETUP:452[CdPN:4900 ]
106 610270.700 --> RX CALL PROCEEDING:452
107 610270.700 --> RX CONNECT:452 /// MP-4 получает от Циски коннект
123 610270.717 <-- TX CONNECT ACK:452 // МР-4 отправляет подтверждение Циске о коннекте
173 610284.916 <-- TX DISCONNECT:452 [Cause: Normal call clearing ] /// После этого видимо ничего не получив в ответ MP-4 (или оператор..??) шлет дисконнект Циске.
175 610284.940 --> RX RELEASE:452А это на Циске:
Jan 7 16:59:35.437 KRS: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x81D5
Channel ID i = 0xA98394
Exclusive, Channel 20
Jan 7 16:59:35.437 KRS: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x81D5
Jan 7 16:59:35.469 KRS: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01D5 /// Вроде как после этого Циска вероятно должна отправить алертинг или что то вроде того вызывающей стороне (Я правильно понимаю???)
Jan 7 16:59:36.433 KRS: //413//TCL :/tcl_PutsObjCmd: proc act_PlayWelcome started \\\Должно заиграть сообщение
Jan 7 16:59:36.433 KRS:
Jan 7 16:59:36.433 KRS: //413//TCL :/tcl_PutsObjCmd: Welcome
Jan 7 16:59:36.433 KRS:
Jan 7 16:59:46.484 KRS: //413//TCL :/tcl_PutsObjCmd: proc act_GotDest started
Jan 7 16:59:46.484 KRS:
Jan 7 16:59:46.484 KRS: //413//TCL :/tcl_PutsObjCmd: Don't numplan
Jan 7 16:59:46.484 KRS:
Jan 7 16:59:46.484 KRS: //413//TCL :/tcl_PutsObjCmd: Transfer to operator 100
Jan 7 16:59:46.484 KRS:
Jan 7 16:59:49.400 KRS: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8 callref= 0x01D5 \\\ А вот отбой приходящий от вызывающей стороны.....
Cause i = 0x8390 - Normal call clearing
Jan 7 16:59:49.400 KRS: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x81D5
должно быть вроде так
<-SETUP
-> CALL_PROC
-> ALERTING
(пошел КПВ\звонок)
-> CONNECT
<- CONNECT_ACK
(разговор)
<- DISCONNECT
->RELEASEcisco, если в скрипте сделан ответ сразу по приходу вызова, сигнал ALERTING действительно глотает. ибо ALERTING - сигнал о том что надо выдавать звонящему КПВ. А при звонке на IVR КПВ не выдается - не успевает. Все правильно по идее, но М200 видимо другого мнения.
как вставить задержку в tcl скрипт незнаю. У меня vxml скрипты.
ну например вставить восроизведение 5сек тишины. :)
>[оверквотинг удален]
>посмотрел на своей работующей CISCO c IVR (isdn PRI подключение)
>нет никакого сигнала после CONNECT ACK и до DISCONNECT
>
>сигнал ALERTING означает что пошел сигнал КПВ. приходит он _до_ CONNECT\CONNECT ACK
>
>в случае с IVR его нет и не должно быть, поскольку соединение
>происходит сразуже по приходу вызова.
>
>Можно попробовать в скрипте перед ответом ждать 5-10сек, тогда ALERTING появтся наверное.
>А как сделать паузу в скрипте??? set delay "время в секундах" - так пойдет???
>[оверквотинг удален]
>>сигнал ALERTING означает что пошел сигнал КПВ. приходит он _до_ CONNECT\CONNECT ACK
>>
>>в случае с IVR его нет и не должно быть, поскольку соединение
>>происходит сразуже по приходу вызова.
>>
>>Можно попробовать в скрипте перед ответом ждать 5-10сек, тогда ALERTING появтся наверное.
>>
>
> А как сделать паузу в скрипте??? set delay "время в секундах"
>- так пойдет???Та же самая беда приключилась с теми же потоками и сигнализацией(((( Самое обидное что все работало 3 года, а щас вот встало.
У кого нить получилось найти решение???
>[оверквотинг удален]
>>>
>>>Можно попробовать в скрипте перед ответом ждать 5-10сек, тогда ALERTING появтся наверное.
>>>
>>
>> А как сделать паузу в скрипте??? set delay "время в секундах"
>>- так пойдет???
>
>Та же самая беда приключилась с теми же потоками и сигнализацией(((( Самое
>обидное что все работало 3 года, а щас вот встало.
>У кого нить получилось найти решение???Нее. Год прошел так и сидят без IVR-а. Я трейсы транзитного коммутатора снимал, отсылал производителю в МТА, сказали что на городской АТС ждут Alerting, а скрипт его не отдает и связь рвется... На ISDN PRI таких косяков не замечал. Вручную вставить алертинг не получилось..
>[оверквотинг удален]
>>>- так пойдет???
>>
>>Та же самая беда приключилась с теми же потоками и сигнализацией(((( Самое
>>обидное что все работало 3 года, а щас вот встало.
>>У кого нить получилось найти решение???
>
>Нее. Год прошел так и сидят без IVR-а. Я трейсы транзитного коммутатора
>снимал, отсылал производителю в МТА, сказали что на городской АТС ждут
>Alerting, а скрипт его не отдает и связь рвется... На ISDN
>PRI таких косяков не замечал. Вручную вставить алертинг не получилось..Сдается мне что это общая трабла конвертации сигналки.
в моем случае идет так:
SI2000 --> 2ВСК --> КВАНТ-ЕВРО --> PRI30 --> CISCO5350Я здесь тему полднимал по этому поводу:
http://www.opennet.me/openforum/vsluhforumID6/18015.htmlгрешил на циску, а вот увидел этот топик и понял что не у меня одного косяки.
не могу понять почему все работало три года без-запинки???((9 Местные АТС-ники говорят "мы ничего не меняли" и т.п..... вот и думай теперь "что-же все таки случилось" (((((
>[оверквотинг удален]
>>>- так пойдет???
>>
>>Та же самая беда приключилась с теми же потоками и сигнализацией(((( Самое
>>обидное что все работало 3 года, а щас вот встало.
>>У кого нить получилось найти решение???
>
>Нее. Год прошел так и сидят без IVR-а. Я трейсы транзитного коммутатора
>снимал, отсылал производителю в МТА, сказали что на городской АТС ждут
>Alerting, а скрипт его не отдает и связь рвется... На ISDN
>PRI таких косяков не замечал. Вручную вставить алертинг не получилось..А что если сделать такой вариант:
Имеется циска 5300, с двумя Е1 потоками, в один - включается злополучная станция, а вот в другой ставиться "перемычка" или "петля" (как еще ее назвать не знаю, вообщем коннектор, в котором прием заведен на передачу и т.п.).
Так вот, принимаем звонок на IVR следующим образом - номер "ответа" снимаем с IVR и пробрасываем на нашу перемычку по правилу:
interface Serial3/0:15 (стыковка со станцией)
no ip address
isdn switch-type primary-net5
isdn incoming-voice modem 64
isdn guard-timer 20000
isdn send-alerting
isdn negotiate-bchan
isdn bchan-number-order ascending
isdn sending-complete
no cdp enable
!
interface Serial3/1:15 (порт перемычки)
no ip address
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice modem 64
isdn guard-timer 20000
isdn send-alerting
isdn negotiate-bchan
isdn sending-complete
no cdp enable
dial-peer voice 111 pots
description RAZVOROT-IVR-DLY-PETLI
destination-pattern 642222 (номер "ответа")
port 3/1:D (порт перемычки)
forward-digits 0 (все цифры удаляем)
prefix 642233 (ставим новый префикс)
dial-peer voice 222 pots (правило для самого IVR)
application debit1
incoming called-number 642233
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
direct-inward-dial
port 3/1:Dзвонок этот по идеи должен снова вернуться на циску, но так как он "прошел" по другому E1 - не даст ли нам это тот самый ALERT ??
>звонок этот по идеи должен снова вернуться на циску, но так как
>он "прошел" по другому E1 - не даст ли нам это
>тот самый ALERT ??пробовать надо, но хз, даст ли это нужный эффект.
И тем более доп затраты на порты и DSP ресурсы.