As it can be seen from the figure, the PBX of side B erroneously takes the last bit of the first sample of the first timeslot as the first bit of the second timeslot, the last bit of the second timeslot as the first bit of the third timeslot, and so on. There is an overlap of neighboring timeslots. This phenomenon is called “slip”. “Slips” lead to the fact that, first of all, fax transmission is disrupted in the E1 links, analog modem connections do not work, clicks, crackles, and noise can be heard in the speech.
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#controller e1 1/0
Router(config-controller)#clock source line
2) It is necessary to specify from which E1 port clocking will be performed. This is done using the network-clock-select command in global configuration mode. Even if only one E1 link is used in your gateway, this command must still be configured. Without it, the gateway does not know where to get clocking from. If this is not done, then you will get an out-of-sync E1 link.
Then look at the value of the “slip” counter for the given E1 link. If the stream is synchronized, then “slips” are not observed:
Router#sh controller E1
E1 1/0 is up.
Applique type is Channelized E1 – balanced
Description: PSTN_E1
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20090408, FPGA: 255, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Current port master clock:recovered from backplane
Data in current interval (396 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 4 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
If the stream is not synchronized, then the number of “slips” is not equal to zero and is constantly growing:
Router#sh controller E1
E1 1/0 is up.
Applique type is Channelized E1 – balanced
Description: PSTN_E1
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20090408, FPGA: 255, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Current port master clock:recovered from backplane
Data in current interval (396 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 4 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations,
130 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
130 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
а что если источник синхронизации не ГТС, а другой роутер ? что нужно настроить на роутере который будет являться источником синхронизации ?
Добрый день,
В таком случае на этом роутере для порта Е1 прописываете команду clock source internal.
Встречный роутер (т.е ведомый) настраиваете так, как я описал в посте.
Здравствуйте!
А если к циске подключено несколько разных АТС (например, по четырем портам Е1), то глобальная команда "network-clock-select 1 e1 1/0" все равно указывает только на один из этих портов Е1? А как же три остальных порта? Ведь на каждом "висит" своя АТС, а значит и своя синхронизация должна быть?
Здравствуйте,
Нет с этим никаких проблем 🙂 в команде network-clock-select параметр 1 (перед е1) обозначает приоритет синхронизации. Если потоков будет несколько, то роутер все равно будет синхронизироваться только от одного (наиболее приоритетного). Обычно таким потоком будет поток от городской АТС. Если необходимо указать, что есть запасной источник синхронизации, то прописывают команду network-clock-select 2 e1 slot итд.
Тут зависит все от того, какая будет топология сети.
Ведомственная АТС всегда синхронизируется от городской. Если к этой ведомственной АТС подключен поток от другой ведомственной АТС, а вторая АТС не имеет подключения к городу по е1, то эта вторая ВАТС синхронизируется от первой (т.е в случае роутеров на втором роутере нужно прописать network-clock select 1).
Если же вторая АТС имеет подключение по е1 к городу, то тогда
она тоже синхронизируется от ГАТС. В этом случае синхронизация между двумя ведомственными АТС получается автоматически(потому как, по сути, обе засинхронизированы от одного источника – ГАТС).
Спасибо за ответ.
Скажите, а в чем тогда смысл команды
"network-clock-participate" из режима глобальной конфигурации?
И якобы ее можно изменить на интерфейсе?
Добрый вечер,
Команда network-clock-participate предназначена для синхронизации DSР. Она дается в режиме глобальной конфигурации. На интерфейсе она не применяется.
Проблема синхронизации DSP состоит в следующем. DSP синхронизируются от внутреннего источника роутера, а платы Е1, как мы уже разобрали, от внешнего (например, от ГАТС). Может так оказаться, что тактовые частоты внутреннего генератора синхронизации и внешнего источника не совпадут. Поэтому DSP неправильно может интерпретировать данные тайм-слотов в потоке E1, и, соответственно, сформировать пакеты с искаженными данными.
Для того, чтобы такого не было, и применяют данную команду. Она обеспечивает синхронизацию DSP от платы Е1. Это, если рассказывать кратко. 🙂
Вот тут есть еще дополнительная интересная информация по данному вопросу:
http://www.cisco.com/en/US/products/hw/routers/ps259/products_tech_note09186a008031a072.shtml
Здравствуйте.
К сожалению теханглийский мне пока сложноват.
Ознакомилась уже с несколькими русскими книгами по CISCO, но ответа на мой вопрос там почему то не было.
Вы прояснили ситуацию, спасибо.
Остается вопрос с командой "clock source line".
В ней есть еще параметр primary, который задает приоритет именно данного потока Е1. Но ведь приоритет потока задается еще командой "network-clock-select".
Получается дублирование?
Здравствуйте,
Нет, никакого дублирования нет. Просто network-clock-select есть в IOS не для всех шлюзов. Для некоторых шлюзов вместо нее (например, AS5200) применяется clock source line primary.
Ну а в тех шлюзах, где есть network-clock-select, параметра primary в clock source нет. Посмотрите, что отображает контекстный хелп для роутера 2811:
HQ-1(config)#controller e1 1/0
HQ-1(config-controller)#clock source line ?
bits Bits Clocking
Хорошего дня! 🙂
Спасибо огромное,
буду разбираться дальше.
Доброе утро,
Рад помочь. 🙂 Если нужна дополнительная помощь – пишите.
Хорошего дня!
Здравствуйте.
А если версия cisco ios 12.3 где нет команды clock source line, какие могут быть ещё методы синхронизации между АТС и cisco ?
заранее спасибо
Доброе утро.
Прошу извинить меня за задержку с ответом. Команда clock source line появилась в более ранних версиях IOS, в частности она есть IOS 12.2.
А можете, пожалуйста, сказать, какая точно версия и тип IOS установлены на Вашем роутере? (sh version) Возможно, что там базовый IOS, и поэтому команда clock source line отсутствует.
Хорошего дня!
Доброе утро.
RAS#sh ver
Cisco Internetwork Operating System Software
IOS ™ 5350 Software (C5350-IS-M), Version 12.3(17a), RELEASE SOFTWARE (fc2)
Теперь становится более понятно, почему так. У Вас шлюз 5350. Насколько я понимаю, в нем синхронизация по-другому настраивается. К сожалению, у меня не было практики именно с этим шлюзом, но руководства на cisco.com говорят о том, что для 53хх шлюзов нужно использовать команду в режиме глобальной конфигурации
tdm clock priority
Попробуйте погуглить насчет этой команды и вариантов ее использования.
Вот, что удалось найти мне (к сожалению, на английском):
http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a008014f8a6.shtml
http://www.cisco.com/en/US/docs/ios/12_3/dial/command/reference/dia_s6g.html#wp1140246
Почитайте еще вот тут небольшое обсуждение (уже на русском):
http://fido7.ru.cisco.narkive.com/AnLmFUNM/clock-source
И подскажите пожалуйста,
Total Data (last 24 hours)
3186732 Line Code Violations, 122913 Path Code Violations,
48 Slip Secs, 471 Fr Loss Secs, 539 Line Err Secs, 72 Degraded Mins,
180 Errored Secs, 9 Bursty Err Secs, 169 Severely Err Secs, 461 Unavail Secs
Где можно взять информацию по этим ошибкам, что они значат и как понять причину их появления ?
А поток у вас вообще работает? Звонки по нему ходят? Уж очень большое количество ошибок в этом потоке (и ошибки линейного кодирования, и потери фреймов).
Некоторое описание ошибок вот здесь:
http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00800f99bb.shtml
Совсем забыл сказать, это вывод #sh contr e1 3/0
Вот еще немного инфы по траблшутингу
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/voice_troubleshooting/old/vts_dgtl.html
Поток работает, но периодически отваливается, пытаюсь понять, проблема в мини-АТС или в циске, проблема возникает спонтанно, помогает либо передергивание патчкорда либо выключениевключение контроллера е1 3 .
Шлюз в мини-атс подключен напрямую кабелем? Или есть промежуточные устройства (модемы HDSL, мультиплексоры и т.п.)?
Описанное поведение по симптомам очень похоже на переломанный патчкорд.
cisco через контроллер напрямую подключена к плате на мини-АТС патчкордом, с одной стороны(к циске rj-45) с другой к контактам на плате припаяны жилки в нужном порядке, вот и вся конструкция, вполне возможно переломан, т.к. на стойке был как то подозрительно закреплен…
Знаете все проще оказалось, мучился конечно около недели, все перепробовал, а конец пришел плате на АТС, пропадала синхронизация, умирал протокол dsse, и помогал только перезапуск либо АТС либо порта на циске. Большое спасибо dbenda за помощь в информации.
Пожалуйста 🙂 рад помочь.
Здравствуйте, я уже обращалась к Вам.
Что значат команды "isdn send-alerting" и "isdn sending-complete"?
Почему то в огромной книге "Полный справочник по Cisco" Б.Хилла (как и в десятке других) про это ни слова.
Где вообще можно найти информацию по подобным командам?
Даже на оф.сайте Циски дана очень скудная информация из 2-х предложений.
Спасибо.
Добрый вечер, Ольга!
Найти информацию по командам можно только в документации циски, в различных админ-гайдах и прочее. Только гуглить 🙁
По поводу команд попытаюсь Вам разъяснить. Итак, начнем с команды isdn sending-complete. Она нужна для того, чтобы сказать противоположной стороне в сообщении SETUP (в нем выставляется специфичный IE), что набор номера закончен и ей отданы все необходимые данные для маршрутизации звонка. Эта команда нужна лишь в некоторых странах, в частности в Гонконге и Тайване, т.е ее нужно использовать только при специфичных требованиях провайдера.
Другая команда isdn send-alerting необходима для того, чтобы выставлять в Е1 сообщение Alert перед отправкой сообщения Connect. Т.е когда шлюз обрабатывает входящий звонок по Е1 он будет в обязательном порядке выставлять Alert при посылке вызова вызываемому абоненту. Затрудняюсь сразу ответить, в каких ситуациях она нужна, в принципе шлюзы и так выставляют Alert без проблем. Возможно, что какие-то модели шлюзов без нее не посылают Alert на противоположную сторону.
Спасибо за ответ.
Попробую покопаться в информации по ISDN.
Здравствуйте есть Cisco 2921 она состыкована с АТС, синхронизация есть но звонки не проходят не исходящие не входящие, в трубке занятость
Сontroller на Cisco up, интерфейс Serial тоже, dial-peer прописаны, а звонки все-равно не проходят. Где может быть ошибка
Здравствуйте,
Надо дебажить звонок. Используйте команды debug voip dialpeer, debug isdn q931. Неплохо бы для начала проверить состояние ISDN соединения (show isdn status) и убедиться, что поднят Д-канал.
Здравствуйте, такая беда при звонке с Huawei на 2 направления где маршрутизаторы Cisco, исходящие звонки проходят только в 1 случае, конфиги у обеих Cisco аналогичные. Но в одном случае звонки проходят в другом нет. Включал дебаг isdn q931, там куда звонок не идет, так он вообще ничего не показал. На другой дебаг показывает нормально. С Cisco на Cisco звонки проходят в обе стороны. А вот с Huawei на Cisco в одном случае нет. Проблема в любом случае где то на Cisco
Добрый день!
Давайте разберемся для начала в вашей топологии. Правильно ли я понимаю, что есть Huawei, которые подключены по Е1 к шлюзам циско? И с Huawei можно позвонить на 2 разных направления через циско, набирая разные номера, при этом вы должны попадать через разные шлюзы, верно?
Если все это так, то надо убедиться, что на неработающей стороне поток Е1 активирован и Д-канал "поднят". Используйте для этого на шлюзе команды show isdn status и show controller e1.
Если поток Е1 в сторону Huawei поднят и выше приведенные команды показывают, что все ок, то я думаю, что проблема не в циско, а как раз на стороне Huawei, потому что Вы пишете, что "Включал дебаг isdn q931, там куда звонок не идет, так он вообще ничего не показал". Это значит, что по Д-каналу Е1 ничего не приходит.
Схема такая есть 10 офисов территориально распределенные в каждом схема типовая
Стационарные телефоны все подключены к АТС , которая в свою очередь подключена к маршрутизатору Cisco по E1, дальше идет VPN провайдера
Звонки осуществляются из офиса в офис.
Так вот в 9 офисах стоят маршрутизаторы Cisco, в одном маршрутизатор Huawei.
Звонки с Cisco на Cisco и входящие и исходящие работают во всех направлениях. Звонки с офисов там где Сisco проходят на Huawei без проблем. А при звонке с Huawei могу дозвониться только до 5 офисов.
При звонке в остальные в трубке занятость. Т.е. с входящими звонками на Huawei все в порядке.
Конфиги у всех Цисок похожи. И на Цисках куда звонок не проходит включаю дебаг isdn q931 и вообще ничего не отображается.
Там куда звонки проходят, дебаг isdn q931 показывает все в норме соединение установилось.
И вот ломаю голову. Вроде бы и на Huawei trunk-group и callprefix (аналоги dial-peer на Cisco) во все направления прописаны аналогично, за исключением конечно ip адреса назначения и префиксов, т.е. цифр на которые начинаются номера. Т.е. все по аналогии , но почему-то куда то звонки проходят , а куди и нет. Неясно где проблема у Huawei или на Cisco. Как проверить на Cisco, что проблема не в ней и тогда уже начинать
биться с Huawei.
Добрый день, Leonardo.
Правильно ли я понял, что во всех офисах стоят АТСки, которые подключены по Е1 к маршрутизаторам (шлюзам)? 9 АТСок подключено к цискам, 1 АТСка подключена к Huawei? Звонки вы делаете с АТСки на АТСку, верно?
Если так, то правильно ли я понимаю, что звонок между циской и Huawei осуществляется по IP? Если да, то какой протокол VOIP сигнализации (SIP или H323) используется между Huawei и циско?
Для того, чтобы подсказать Вам направление поиска, мне нужно полностью и правильно понимать топологию вашей телефонной сети. Поэтому задаю уточняющие вопросы.
Обалденное эссе. До момента прочтения считал, что платы E1 работают на своих частотах.
Да звонки между циской и Huawei осуществляется по IP. Протокол используется h323.
Отлично 🙂 Убедитесь, что звонки по н323 доходят до циски. Сделать это можно с помощью дебагов, например, debug cch323 h225, debug h225 q931, debug h225 asn1.
Можно на циске посмотреть, как происходит выбор диалпира и обработка звонков в шлюзе:
debug voip dialpeer inout
debug voice ccapi inout
Соответственно, если звонок от Huawei доходит – проблема в циске и ее настройках. Если не доходит – разбираемся с Huawei .
Сделал я дебаги по ним видно что звонок приходит,вот debug isdn q931 ничего не показывает почему неясно
Прекрасно, уже что-то 🙂
Теперь нужно смотреть, как циска обрабатывает звонок:
debug voip dialpeer inout – выбор диалпира.
debug voice ccapi inout – обработка звонка шлюзом.
Обратите внимание на called номер. Правильный ли он присылается от Huawei? Обратите внимание на конфигурацию кодеков. Также из дебагов H323 следует определить причину отбоя (cause) – она может подсказать из-за чего звонок не проходит.
Если не удастся самому определить проблему, я могу Вам помочь, но для этого нужны:
1. Конфиги диал-пиров со шлюза циско.
2. Разъяснения, какой номер вы набираете с Huawei и какие кодеки используются при звонке с Huawei.
3. Выводы дебагов (для начала нужен отдельный debug voip dialpeer inout и отдельный debug voice ccapi inout)
Конфиг диал-пира для звонка на Huawei
dial-peer voice 63 voip
destination-pattern 63T
translate-outgoing called 63
modem passthrough nse codec g711alaw
session target ipv4:192.168.172.10
dtmf-relay h245-alphanumeric
codec g711ulaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
ip qos dscp cs5 media
translation-rule 63
Rule 0 63 631
Входящий диал-пир
dial-peer voice 8377 pots
destination-pattern 64T
direct-inward-dial
port 0/0:15
Интерфейс Serial на Cisco
interface Serial0/0:15
no ip address
no logging event link-status
isdn switch-type primary-net5
isdn incoming-voice voice
isdn sending-complete
isdn outgoing display-ie
no cdp enable
controller E1 0/0
framing NO-CRC4
pri-group timeslots 1-31
description to PBX
При звонке с Huawei набирается номер на 64, 6426 к примеру кодек 711ulaw используется
Вывод debug voice ccapi inout слишком длинный не помещается он выдает
Ваш код HTML не может быть принят: Должно быть не более 4 096 символов
"Вывод debug voice ccapi inout слишком длинный не помещается" – разбейте его, пожалуйста, на несколько частей и перешлите несколькими постами.
Входящий диал-пир
dial-peer voice 8377 pots
destination-pattern 64T
direct-inward-dial
port 0/0:15
Это, скорее, входящий для звонков от офисной АТСки на Huawei через циску. Он же будет использован как исходящий при звонке с Huawei на АТСку.
Входящим же диал-пиром при звонке с Huawei на циску может быть первый показанный Вами диал-пир:
dial-peer voice 63 voip
destination-pattern 63T
translate-outgoing called 63
modem passthrough nse codec g711alaw
session target ipv4:192.168.172.10
dtmf-relay h245-alphanumeric
codec g711ulaw
но только при условии, что с Huawei звонят с номеров, начинающихся на 63. Действительно ли АОНы номеров на Huawei начинаются на 63?
Есть ли какие-либо еще диалпиры на циске?
Приведите, пожалуйста, вывод дебага debug voip dialpeer inout. Если не поместится, то так же разбейте его по частям.
debug voice ccapi inout
voip ccAPI function enter/exit debugging is on
#
Nov 22 09:19:01.951: //-1/xxxxxxxxxxxx/CCAPI/cc_api_supported_data: data_mode=0x10082
Nov 22 09:19:01.971: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer: TD Container Constructed <<<<<< container-0x82B6A980 >>>>>>
Nov 22 09:19:01.971: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x82B6A980, tagID=6, dataSize=16, instID=-1,modifier=2
Nov 22 09:19:01.971: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructDataObject: TD Data Object Constructed 0x83C6BAAC<>
Nov 22 09:19:01.971: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: TD Queuable Instance Constructed 0x82B9DF3C[0x0,t-6,o-0x83C6BAAC<>]
Nov 22 09:19:01.975: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Inserting Queuable TDObject into Container; [tagID-6, container-0x82B6A980, Queuable-TDObject-0x82B9DF3C]
Nov 22 09:19:01.975: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x82B6A980, tagID=5, dataSize=212, instID=-1,modifier=4
Nov 22 09:19:01.975: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructDataObject: TD Data Object Constructed 0x83A41C7C<>
Nov 22 09:19:01.975: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: TD Queuable Instance Constructed 0x83C5B3C0[0x0,t-5,o-0x83A41C7C<>]
Nov 22 09:19:01.979: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Inserting Queuable TDObject into Container; [tagID-5, container-0x82B6A980, Queuable-TDObject-0x83C5B3C0]
Nov 22 09:19:01.979: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x82B6A980, tagID=29, dataSize=16, instID=-1,modifier=4
Nov 22 09:19:01.979: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructDataObject: TD Data Object Constructed 0x83C6BB0C<>
Nov 22 09:19:01.979: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: TD Queuable Instance Constructed 0x83C5DF80[0x0,t-29,o-0x83C6BB0C<>]
Nov 22 09:19:01.979: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Inserting Queuable TDObject into Container; [tagID-29, container-0x82B6A980, Queuable-TDObject-0x83C5DF80]
Nov 22 09:19:01.983: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:
Nov 22 09:19:01.983: cc_api_call_setup_ind_common:
Nov 22 09:19:01.983: cisco-username=192.168.172.10
Nov 22 09:19:01.983: —– ccCallInfo IE subfields —–
Nov 22 09:19:01.983: cisco-ani=
Nov 22 09:19:01.983: cisco-anitype=0
Nov 22 09:19:01.983: cisco-aniplan=0
Nov 22 09:19:01.983: cisco-anipi=0
Nov 22 09:19:01.983: cisco-anisi=0
Nov 22 09:19:01.983: dest=64126
Nov 22 09:19:01.987: cisco-desttype=4
Nov 22 09:19:01.987: cisco-destplan=1
Nov 22 09:19:01.987: cisco-rdn=
Nov 22 09:19:01.987: cisco-rdntype=-1
Nov 22 09:19:01.987: cisco-rdnplan=-1
Nov 22 09:19:01.987: cisco-rdnpi=-1
Nov 22 09:19:01.987: cisco-rdnsi=-1
Nov 22 09:19:01.987: cisco-redirectreason=-1
Nov 22 09:19:01.987: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common: (vdbPtr=0x835E9978, callInfo={called=64126,called_oct3=0xC1,calling=,calling_oct3=0x0,calling_oct3a=0x0,calling_xlated=false,subscriber_type_str=Unknown,fdest=1,peer_tag=0, prog_ind=0,callingIE_present 0, src_route_label=, tgt_route_label= clid_transparent=0},callID=0x834FB900)
Nov 22 09:19:01.987: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common:
Nov 22 09:19:01.991: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common: type 0 , prot 1
Nov 22 09:19:01.991: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common: (vdbPtr=0x835E9978, callInfo={called=64126, calling=, fdest=1 peer_tag=0}, callID=0x834FB900)
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 1
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current call volume: 2
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry's incoming TRUE.
Nov 22 09:19:01.995: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is TRUE
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: TD ProfileTable Constructed [profileTable-0x82B69A7C]
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x82B69A7C] with objects in container[0x82B6A980]
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: profileTable[0x82B69A7C], numBuckets[11], numEntries[3]
Nov 22 09:19:01.999: Bucket { 0 } —->0x83C5B3C0[0x83C5DF80,t-5,o-0x83A41C7C<>]—->0x83C5DF80[0x0,t-29,o-0x83C6BB0C<>]
Nov 22 09:19:01.999:
Nov 22 09:19:01.987: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common:
Nov 22 09:19:01.991: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common: type 0 , prot 1
Nov 22 09:19:01.991: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common: (vdbPtr=0x835E9978, callInfo={called=64126, calling=, fdest=1 peer_tag=0}, callID=0x834FB900)
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 1
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current call volume: 2
Nov 22 09:19:01.991: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry's incoming TRUE.
Nov 22 09:19:01.995: //9833/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is TRUE
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: TD ProfileTable Constructed [profileTable-0x82B69A7C]
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x82B69A7C] with objects in container[0x82B6A980]
Nov 22 09:19:01.995: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: profileTable[0x82B69A7C], numBuckets[11], numEntries[3]
Nov 22 09:19:01.999: Bucket { 0 } —->0x83C5B3C0[0x83C5DF80,t-5,o-0x83A41C7C<>]—->0x83C5DF80[0x0,t-29,o-0x83C6BB0C<>]
Nov 22 09:19:01.999:
Nov 22 09:19:01.999: Bucket { 5 } —->0x82B9DF3C[0x0,t-6,o-0x83C6BAAC<>]
Nov 22 09:19:01.999:
Nov 22 09:19:01.999: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: Container[0x82B6A980]
Nov 22 09:19:02.003: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: TD Container Destructed; [container-0x82B6A980, pegObjCnt–98479]
Nov 22 09:19:02.003: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: remote IP is 192.168.172.10
Nov 22 09:19:02.003: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: hwidb is Tunnel0
Nov 22 09:19:02.003: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: create entry in list: 1
Nov 22 09:19:02.007: //-1/xxxxxxxxxxxx/CCAPI/cc_process_call_setup_ind: (event=0x8382E590)
Nov 22 09:19:02.011: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_registration_lookup: matching parameters – called# [64126], consultid []
Nov 22 09:19:02.011: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search: Searching for node with called# [64126], consultid []
Nov 22 09:19:02.011: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_registration_lookup: No matching node
Nov 22 09:19:02.011: //9833/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0x2669, context=0x82B56278)
Nov 22 09:19:02.011: //9833/xxxxxxxxxxxx/CCAPI/cc_process_call_setup_ind: >>>>CCAPI handed cid 9833 with tag 0 to app "Default"
Nov 22 09:19:02.011: //9833/xxxxxxxxxxxx/CCAPI/ccCallSetupAck: (callID=0x2669)
Nov 22 09:19:02.015: //9833/xxxxxxxxxxxx/CCAPI/cc_api_set_transfer_info: (transfer= 0, callID=0x2669)
Nov 22 09:19:02.015: //9833/xxxxxxxxxxxx/CCAPI/cc_api_set_transfer_info: call transfer reset)
Nov 22 09:19:17.064: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilSetDataInstance: Setting data for callID[9833], tagID[31], instID[-1], dataSize[4]
Nov 22 09:19:17.064: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructDataObject: TD Data Object Constructed 0x83A42CB0<>
Nov 22 09:19:17.068: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: TD Queuable Instance Constructed 0x83C61EA0[0x0,t-31,o-0x83A42CB0<>]
Nov 22 09:19:17.068: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: profileTable[0x82B69A7C], numBuckets[11], numEntries[4]
Nov 22 09:19:17.068: Bucket { 0 } —->0x83C5B3C0[0x83C5DF80,t-5,o-0x83A41C7C<>]—->0x83C5DF80[0x83C61EA0,t-29,o-0x83C6BB0C<>]—->0x83C61EA0[0x0,t-31,o-0x83A42CB0<>]
Nov 22 09:19:17.068:
Nov 22 09:19:17.068: Bucket { 5 } —->0x82B9DF3C[0x0,t-6,o-0x83C6BAAC<>]
Nov 22 09:19:17.068:
Nov 22 09:19:17.072: //9833/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnected: (vdbPtr=0x834FB8A8, callID=0x2669, cause=0x1C, rawmsg=0x0)
Nov 22 09:19:17.072: //9833/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2669)
Nov 22 09:19:17.072: //9833/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: no transferNumber (callID=0x2669)
Nov 22 09:19:17.072: //9833/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByValue: CallID[9833], tagID[31], instID[-1]
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: (callID=0x2669, cause=0x1C tag=0x0)
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: calling accounting start for callID=9833 leg_type=1
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: existing_cause = 0x1C, new_cause = 0x1C
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: using the existing_cause 0x1C
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2669)
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: no transferNumber (callID=0x2669)
Nov 22 09:19:17.076: //9833/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByValue: CallID[9833], tagID[31], instID[-1]
Nov 22 09:19:17.080: //-1/xxxxxxxxxxxx/CCAPI/cc_api_icpif: expect factor = 10
Nov 22 09:19:17.080: //9833/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByRef: No tdObject found in profileTable for tagID[48] of callID[9833]
Nov 22 09:19:17.080: //9833/xxxxxxxxxxxx/CCAPI/ccCallGetVoipFlag: ccCallGetVoipFlag: callID=0x2669, mask=1
Nov 22 09:19:17.084: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: the remote IP is 192.168.172.10
Nov 22 09:19:17.084: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: hwidb is Tunnel0
Nov 22 09:19:17.084: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: reduce callnum of entry: 0, voip: 0, mmoip: 0
Nov 22 09:19:17.084: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: remove an entry
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect_done: (vdbPtr=0x834FB8A8, callID=0x2669, disp=0, tag=0x0)
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_delete_call_entry: Decrement call volume counter 2
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_delete_call_entry: current call volume: 1
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_delete_call_entry: entry's incoming TRUE.
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_delete_call_entry: is_incoming is TRUE
Nov 22 09:19:17.088: //9833/xxxxxxxxxxxx/CCAPI/cc_delete_call_entry: Deleting profileTable[0x82B69A7C]
Nov 22 09:19:17.088: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructDataObject: TD Data Object Destructed; [0x83A41C7C<>, pegObjCnt–98479]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDObject: TD Queuable Object Destructed; [Queuable-TD Object-0x83C5B3C0,pegObjCnt–98480]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructDataObject: TD Data Object Destructed; [0x83C6BB0C<>, pegObjCnt–98481]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDObject: TD Queuable Object Destructed; [Queuable-TD Object-0x83C5DF80,pegObjCnt–98482]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructDataObject: TD Data Object Destructed; [0x83A42CB0<>, pegObjCnt–98483]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDObject: TD Queuable Object Destructed; [Queuable-TD Object-0x83C61EA0,pegObjCnt–98484]
Nov 22 09:19:17.092: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructDataObject: TD Data Object Destructed; [0x83C6BAAC<>, pegObjCnt–98485]
Nov 22 09:19:17.096: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDObject: TD Queuable Object Destructed; [Queuable-TD Object-0x82B9DF3C,pegObjCnt–98486]
Nov 22 09:19:17.096: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDHashProfileTab: ProfileTable Destructed; [profileTable-0x82B69A7C, pegObjCnt–98487]
В офисах везде нумерация 3-х значная 1-11, 1-22,т.е. при звонке с Huawei на 6426 , 64 преобразуется в 641 номер получается 64126 на Cisco он попадает в
dial-peer voice 8377 pots
destination-pattern 64T
direct-inward-dial
port 0/0:15
далее 64 отсекется и звонок придет на внутренний 1-26
Да Cisco много диал пиров порядка 80
debug voip dialpeer inout такой команды на этой циске нет циска 2651хм версия IOS Version 12.3(4)T11
Leonardo,
верно, звонок на 64126 должен попасть на данный диал-пир и уйти в Е1. Все это так.
Но! До этой стадии еще нужно нам добраться 🙂 Сначала циско шлюз для вашего звонка должен выбрать ВХОДЯЩИЙ voip dialpeer, проверить его параметры (кодеки, способ передачи DTMF) c парсметрами звонка от Huawei. Если все совпадет, то только тогда анализируются набранные цифры 64126 и отправляется звонок в ИСХОДЯЩИЙ диалпир, которым будет являться диалпир 8377 pots.
Сейчас я пытаюсь понять, какой же все-таки диалпир выбирается. Судя по тому дебагу, который Вы прислали ранее, я сомневаюсь, что выбирается диалпир 63, так как в информации о сессии нигде не показан аон от Huawei.
Чтобы не загружать Вас дебагами, предлагаю сделать вот что:
добавьте в dialpeer voice 63 voip следующую строчку
incoming called-number 64…
После этого проверьте звонок с Huawei и отпишитесь о результате 🙂 Посмотрим, что будет 🙂
Да, но дело в чем аон от Huawei не показывается и на дебагах тех цисок куда звонок доходит.
Вот конфиг циски офиса куда звонок от Huawei приходит нормально
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
isdn sending-complete
isdn outgoing display-ie
no cdp enable
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-31
dial-peer voice 63 voip
destination-pattern 63T
translate-outgoing called 63
session target ipv4:192.168.172.10
dtmf-relay h245-alphanumeric
codec g711ulaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
ip qos dscp cs5 media
dial-peer voice 44 pots
destination-pattern 68T
direct-inward-dial
port 0/0/0:15
incoming called-number 64… я добавлял ничего не изменилось
Доброе утро / день. 🙂
Похоже, что без дебагов нам таки не обойтись. Значит, будем дебажить 🙂
Все-таки, нужно разобраться, какой выбирается входящий диалпир. Я посмотрел описание команд для IOS 12.3T (http://www.cisco.com/en/US/docs/ios/12_3t/debug/command/reference/dbg_v1gt.html#wp1257352). Попробуйте на циско шлюзе выполнить команду debug voip dialpeer (без параметра inout).
Также давайте посмотрим на результат команд debug ссh323 h225 и debug h225 asn1 (вывод последней будет очень громоздким).
Предыдущий приведенный Вами дебаг показывает причину отбоя 1С (cause=0x1C). Официальная расшифровка такая:
Cause: 1C Invalid number format
Connection could be established because the destination address was presented in an unrecognizable format or because the destination address was incomplete.
Нужно посмотреть на причину отбоя в сообщениях h323 (для этого нужны указанные мной дебаги, для начала покажите debug ссh323 h225). И важно все же увидеть и понять, какие диалпиры шлюз выбирает в качестве входящего и исходящего.
debug cch323 h225
H225 State Machine tracing is enabled
Nov 22 09:14:52.114: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN
Nov 22 09:14:52.114: //-1/xxxxxxxxxxxx/H323/setup_ind: Entry
Nov 22 09:14:52.114: //9830/001758188002/H323/setup_ind: callingNumber[] calledNumber[64126]
Nov 22 09:14:52.114: //9830/001758188002/H323/setup_ind: — calling IE NOT present
Nov 22 09:14:52.114: //9830/001758188002/H323/setup_ind: ====== PI = 0
Nov 22 09:14:52.114: //9830/001758188002/H323/setup_ind: Receive: infoXCap 8
Nov 22 09:14:52.114: //9830/001758188002/H323/setup_ind: Receive: infoXCap ccb 8
Nov 22 09:14:52.118: //9830/001758188002/H323/setup_ind:
setup_ind: is_overlap = 1, info_complete = 0
Nov 22 09:14:52.118: //9830/001758188002/H323/cch323_h225_receiver: SETUPIND_CHOSEN: src address = 192.168.171.17; dest address = 192.168.172.10
Nov 22 09:14:52.118: //9830/001758188002/H323/run_h225_sm: Received event H225_EV_FS_SETUP_IND while at state H225_IDLE
Nov 22 09:14:52.118: //9830/001758188002/H323/idle_fsSetupInd_hdlr: Setup ccb 0x834FB8A8
Nov 22 09:14:52.122: //9830/001758188002/H323/act_fastStartSetupInd: codec match = 1
Nov 22 09:14:52.122: //9830/001758188002/H323/cch323_h225_set_new_state: Changing from H225_IDLE state to H225_REQ_FS_SETUP state
Nov 22 09:14:52.122: //9830/001758188002/H323/cch323_create_incoming_callinfo_block: peer is NULL – may affect modem pass through! ccb: 834FB8A8, ccNewCallInfo 83851D90
Nov 22 09:14:52.126: //9830/001758188002/H323/cch323_h225_handle_deferred_ind: UnBuffering deferred indications
Nov 22 09:14:52.130: //9830/001758188002/H323/run_h225_sm: Received event H225_EV_SETUP_ACK while at state H225_REQ_FS_SETUP
Nov 22 09:15:07.171: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
Nov 22 09:15:07.175: //9830/001758188002/H323/release_ind: Disconnect cause 28 location code 0
Nov 22 09:15:07.175: //9830/001758188002/H323/cch323_h225_receiver: RELEASEIND_CHOSEN: src address = 192.168.171.17; dest address = 192.168.172.10
Nov 22 09:15:07.175: //9830/001758188002/H323/run_h225_sm: Received event H225_EV_RELEASE_IND while at state H225_REQ_FS_SETUP
Nov 22 09:15:07.175: //9830/001758188002/H323/run_h225_sm: Received event H225_EV_RELEASE while at state H225_REQ_FS_SETUP
Nov 22 09:15:07.179: //9830/001758188002/H323/cch323_h225_send_release: Cause = 28; Location = 0
Nov 22 09:15:07.179: //9830/001758188002/H323/cch323_h225_send_release: h225TerminateRequest: src address = -1062687983; dest address = 192.168.172.10
Nov 22 09:15:07.179: //9830/001758188002/H323/cch323_h225_set_new_state: Changing from H225_REQ_FS_SETUP state to H225_IDLE state
Вот вывод команды debug voip dialpeer с маршрутизатора куда звонок с Huawei также не приходит
Nov 23 10:36:16.403: //-1/00205C1A8002/DPM/dpAssociateIncomingPeerCore:
Calling Number=, Called Number=69101, Voice-Interface=0x0,
Timeout=FALSE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
Nov 23 10:36:16.403: //-1/00205C1A8002/DPM/dpAssociateIncomingPeerCore:
Result=NO_MATCH(-1) After All Match Rules Attempt
Nov 23 10:36:16.403: //-1/00205C1A8002/DPM/dpAssociateIncomingPeerCore:
Calling Number=, Called Number=69101, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
Nov 23 10:36:16.403: //-1/00205C1A8002/DPM/dpAssociateIncomingPeerCore:
Result=NO_MATCH(-1) After All Match Rules Attempt
Nov 23 10:36:16.407: //-1/00205C1A8002/DPM/dpMatchPeersCore:
Calling Number=, Called Number=69101, Peer Info Type=DIALPEER_INFO_SPEECH
Nov 23 10:36:16.407: //-1/00205C1A8002/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=69101
Nov 23 10:36:16.407: //-1/00205C1A8002/DPM/dpMatchPeersCore:
Result=Partial Matches(1) after DP_MATCH_DEST
Nov 23 10:36:16.407: //-1/00205C1A8002/DPM/dpMatchPeersMoreArg:
Result=MORE_DIGITS_NEEDED(1)
Leonardo,
Прежде всего хочу пояснить задержку с ответами Вам – я провожу курс в настоящее время. Поэтому прошу меня извинить, что Вам не сразу отвечаю.
Что удалось увидеть в дебагах h323 – причина отбоя Cause = 28, что есть одно и тоже с причиной 0х1С (первое значение в десятичном формате, второе в шестнадцатиричном). Кауза 28 говорит о том, что система не может найти путь для маршрутизации звонка, а точнее – набираемый номер представлен в неправильном формате.
Проверьте, пожалуйста, нет ли в вашем шлюзе еще диалпиров, у которых destination-pattern начинается на 64.
Еще хотел бы Вам предложить перенести этот диалог в почту или скайп – будет оперативнее.
Напишите, пожалуйста, в комментарии адрес своей почты (естественно, что публиковать я его не буду).
Подскажите выход как раз тема голоса в cisco… есть сеть ATC-cisco-cisco-АТС голос ходит идеально, но как ток в эту цепочку в место одной из цисок я ставлю huawei – голос ходит но звонка на телефонах нет что пришел звонок видно что определился номер на аппарате или по мониторингу АТС – подымаю трубку и веду разговор – как решить проблему на стороне циске?
Добрый день, Михаил!
Пока не ясно, проблема ли это циски или huawei. Нужно такой звонок дебажить, т.е запускать трейсы звонка на АТСках, на циске, на huawei. Да и данных о вашей топологии маловато, поэтому задам Вам несколько вопросов. Вот они:
АТСки подключены к циско и huawei по Е1 PRI или другим способом? циско с huawei взаимодействует по h323 или sip? Правильно ли я понял, что при звонке не звонят телефоны, т.е не звучит сигнал вызова на них? Это наблюдается при звонках в обе стороны?
Ну то что Huawei виноват это понятно – когда стоит Cisco то все прекрасно работает – просто тех поддержка в Huawei плохая – отписались что все должно работать. Да АТС соединяются по Е1 звонок в сторону Huawei я еще не отрабатывал – отбой идет просто это где то мой косяк, а проблема у все России в нашей организации, Huawei и Cisco общаются по h323. когда звонишь со стороны Huawei звонок доходит – телефон определяет номер, а самого звонка нет беру трубку – веду разговор.
Становится более понятно. Давайте посмотрим тогда дебаги на циско. Попрошу Вас сделать следующие дебаги:
debug cch323 h225
debug h225 q931
debug isdn q931
Посмотрим, что там происходит при звонке.
Звонок c Huawei
Nov 30 04:45:57.182: //-1/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN
Nov 30 04:45:57.182: //-1/setup_ind: Entry
Nov 30 04:45:57.182: //13652/setup_ind: callingNumber[2600] calledNumber[81221118]
Nov 30 04:45:57.182: //13652/setup_ind: —- calling IE present
Nov 30 04:45:57.182: //13652/setup_ind: ====== PI = 0
Nov 30 04:45:57.182: //13652/setup_ind: Receive: infoXCap 8
Nov 30 04:45:57.182: //13652/setup_ind: Receive: infoXCap ccb 8
Nov 30 04:45:57.182: //13652/setup_ind:
setup_ind: is_overlap = 0, info_complete = 1
Звонок c Cisco
Nov 30 04:57:51.142: //-1/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN
Nov 30 04:57:51.142: //-1/setup_ind: Entry
Nov 30 04:57:51.142: //13844/setup_ind: callingNumber[2600] calledNumber[81221118]
Nov 30 04:57:51.142: //13844/setup_ind: —- calling IE present
Nov 30 04:57:51.142: //13844/setup_ind: ====== PI = 3
Nov 30 04:57:51.142: //13844/setup_ind: Receive: infoXCap 0
Nov 30 04:57:51.142: //13844/setup_ind: Receive: infoXCap ccb 0
Nov 30 04:57:51.142: //13844/setup_ind:
setup_ind: is_overlap = 0, info_complete = 0
Дебаги это хорошо конечно – но на данный момент они будут на столько объемные что я как вижу по предыдущим постам они суда не влезут, работать приходиться по живому cisco подменяю на живом направлении, к сожалению нет свободной атс чтоб собрать на столе схему. Есть вариант другого общения? Скажу честно в реале решение это проблемы ждет вся страна – сеть изночально у нас построена была на cisco и тут поzивлось 500 ротеров Huawei
Напишите, пожалуйста, свой адрес почты. Ваш коммент с адресом публиковать не буду.
Проблема с отсуствием звонка на обычном телефоне решается конфигурированием Cisco: необходимо в режиме конфигурирования voice-port прописать команду bearer-cap speech
Обращаюсь за помощью. Существует цнтральная циска 2921, к ней подключена учрежденческая АТС – через провайдера к циске подключен три Хуавея AR2220, к хуавеям подключены учрежденческие АТС. Проблема заключается в следующем: при телефонных звонках с АТС со стороны циски в сторону хуавеев на два хуавея звонок проходит, а на третий нет. Настройки для всех идентичны – разница лишь в наборе цифр.
Дебаг isdn q931 с циски при звонке на третий хуавей:
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Progress Ind i = 0x8283 – Origination address is non-ISDN
Calling Party Number i = 0x0183, '8037670'
Plan:ISDN, Type:Unknown
Called Party Number i = 0xC1, '3449'
Plan:ISDN, Type:Subscriber(local)
Dec 6 06:52:41.171: ISDN Se0/1/0:15 Q931: Received SETUP callref = 0x8018 call ID = 0x00C3 switch = primary-net5 interface = User
c2921-37-main#
Dec 6 06:52:41.175: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8 018
Channel ID i = 0xA98397
Exclusive, Channel 23
Dec 6 06:52:41.575: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x 8018
Cause i = 0x80FF – Interworking error; unspecified
Здравствуйте, Александр.
Спасибо за комментарии и подсказку о решении проблемы. Та проблема так и была решена с помощью способа, который Вы описали (добавлением команды bearer-cap speech). Нет времени просто написать об этом сообщение.
Теперь о Вашей проблеме. Только сегодня с Михаилом Гладких решили аналогичную проблему у него на сети. Я правильно понимаю, что циска звонит на Huawei по H323? или может быть по сип?
Давайте глянем на дебаги debug cch323 h225 (если у вас н323) или debug ccsip messages для SIP.
День добрый!
Ва правильно поняли – циска звонит на Huawei по H323.
Дебаг:
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/generic_send_setup: sending calling IE
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/generic_send_setup: ====== PI = 3
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/generic_send_setup: Send infoXCap=128, infoXRate=16, rateMult=0, xMode=128, info_layer1_prot=163
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/generic_send_setup: src address = 10.37.252.1; dest address = 10.37.251.4
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/cch323_h225_set_new_state: Changing from H225_IDLE state to H225_REQ_FS_SETUP state
Dec 7 06:13:34.821: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/release_ind: Disconnect cause 127 location code 0
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/cch323_h225_receiver: RELEASEIND_CHOSEN: src address = 10.37.252.1; dest address = 10.37.251.4
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/run_h225_sm: Received event H225_EV_RELEASE_IND while at state H225_REQ_FS_SETUP
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/run_h225_sm: Received event H225_EV_RELEASE while at state H225_REQ_FS_SETUP
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/cch323_h225_send_release: Cause = 127; Location = 0
c2921-37-main#
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/cch323_h225_send_release: h225TerminateRequest: src address = 170261505; dest address = 10.37.251.4
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/cch323_h225_set_new_state: Changing from H225_REQ_FS_SETUP state to H225_IDLE state
Dec 7 06:13:35.161: //4757/051CECCF9240/H323/run_h225_sm: Received event H225_EV_ALERT while at state H225_ACC_FS_PROGRESS
Dec 7 06:13:35.161: //4757/051CECCF9240/H323/cch323_h225_set_new_state: Changing from H225_ACC_FS_PROGRESS state to H225_ACC_FS_ALERT state
Доброе утро,
Dec 7 06:13:34.821: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
Dec 7 06:13:34.821: //4762/10AA174B8387/H323/release_ind: Disconnect cause 127 location code 0
звонок отбивается со стороны Huawei c каузой (причиной отбоя) 127. Наиболее вероятной причиной такого поведения является то, что Huawei отбивает звонок с неизвестного айпишника.
Ваша циска шлет пакеты Setup, маркированные айпишником 10.37.252.1:
Dec 7 06:13:34.421: //4762/10AA174B8387/H323/generic_send_setup: src address = 10.37.252.1; dest address = 10.37.251.4
Прописан ли этот айпи адрес в настройках транк-группы на Huawei?
Пример настроек Huawei (из траблшутинга аналогичной проблемы):
#
trunk-group h323 h323 symmetrical
…….. (часть настроек пропущена)
peer-address static 10.37.250.1 1720
рееr-address должен соответствовать вызывающему айпишнику со стороны циски. Иначе будет отбой с каузой 127.
Проверьте, пожалуйста, эту настройку.
Вы оказались совершенно правы.
Просто в конфигурации циски на одном из сабинтерфейсов настроены два ip адреса, один из которых secondary и я думал что циска будет отправлять звонки с него. Поэтому на Huawei в peer-address был выставлен как оказалось неправильный айпишник.
Проблема оказалась не сложная, только с ней раньше никогда не сталкивался.
Спасибо Вам большое за оказанную помощь. Очень помогли.
Пожалуйста 🙂
Я только вчера помог другому читателю блога (Михаилу Гладких) с подобной проблемой. Поэтому все еще свежо в памяти 🙂
На выходных напишу об этой проблеме отдельный пост, думаю, что он еще многим пригодится.
День добрый!
Подскажите, существуют ли какие-либо команды на голосовом шлюзе Huawei AR2220 для синхронизации потока Е1? Спасибо.
Добрый день, Александр!
К сожалению, не смогу ответить на Ваш вопрос с ходу – я не работаю со шлюзами Huawei, и глубоко их не знаю.
Нужно гуглить.
Значит будем гуглить дальше …
Здравствуйте!
Может быть кому пригодится – команда на голосовом шлюзе Huawei AR2220 для синхронизации потока Е1 выглядит следующим образом:
clock source 1 4/0/0 priority 1, где 4/0/0 – место установки модуля с интерфейсами Е1.
По крайней мере "слипы" копиться перестали …
Добрый день, Александр!
Спасибо большое за информацию, если Вы не против, я оформлю ее отдельным постом со ссылкой на Вас. Думаю, что многим людям, занимающимся Huawei, она будет весьма полезна.
Добрый день, Дмитрий!
Подскажите пожалуйста:
появился с2901/k9 – IOS: c2900-universalk9_npe-m, version 15.1(4)m4
поддеживает ли он VWIC-2MFT-E1? (в интернете пишут, что нет – подходят VWIC2 и VWIC3);
при программировании не нашел команды card type e1 … или она появиться после того как маршрутизатор увидит модуль с Е1.
Заранее спасибо.
Добрый день, Александр!
Официально циска пишет, что VWIC-2MFT-E1 не поддерживается на ISR2 (29xx, 39xx). Источник – вот тут (таблица 6):
http://www.cisco.com/en/US/prod/collateral/routers/ps10538/aag_c07_563807.pdf
Но…честно говоря, если форм-фактор (размеры, разъем) подходит, я бы попробовал вставить плату в роутер и запрограммировать, чем черт не шутит… 🙂 Про wic2t в свое время писали, что тоже не поддерживается на 28й серии, однако эти платы работают, в моей лабе они стоят и выполняют все, что от них требуется.
Что касается упомянутой команды – ее не будет, если Вы ставите модуль, у которого только один режим (т.е либо е1, либо т1). Ее можно и нужно вводить, если плата поддерживает и е1, и т1. Таким образом, с ее помощью задается и выбирается нужный режим контроллера.
Буду Вам признателен, если отпишете, чем закончится эксперимент с платой в 29м роутере. Очень интересно 🙂
Поэкспериментировал немного:
оказалось – мой 2901 не видит VWIC-2MFT-E1, хотя форм-фактор подходит (команда sh version)- официальный сайт не обманул;
при установке VWIC2-1MFT-G.703 все прекрасно видится той же командой.
Александр,
спасибо за результаты эксперимента. Теперь знаем точно, что в ISR2 старая плата не поддерживается.
Доброе утро, Дмитрий!
Очень волнует вопрос об установлении причины отбоя на голосовых шлюзах. Вопрос очень актуальный в данное время – некоторые disconnect cause неспицифированы (например 31, 47, 79, 91, 111 и др).
Не могли бы Вы рассказать или оставить ссылку, как определять Q.931 Cause Disconnected (причины отбоя).
Доброе утро, Александр!
При определении причины отбоя я обычно пользуюсь либо каким-либо стандартным isdn документом, либо вот этими ссылками с циско.ком:
http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/voice_troubleshooting/old/vts_appa.html
Зачастую, причину отбоя (что именно вызывает такое поведение шлюза) можно увидеть с помощью debug voip ccapi inout (кроме шлюзов MGCP).
Не знаю, ответил ли я на Ваш вопрос, если нет, то опишите тогда более детально задачу. 🙂
Здравствуйте Дмитрий, хотелось бы спросить у вас по поводу синхронизации потоков Е1 и образовании "слипов", прописываю на маршрутизаторе network-clock-select 1 e1 0/0, а он ругается Slot 0 is configured not to participate in System Clocking,
т.е.
0 cлот не участвует в синхронизации, как быть в таком случае, не подскажите.
Добрый день,
Попробуйте добавить в глобальной конфигурации команду
network-clock-participate wic 0
Ну а потом уже network-clock-select
Отпишитесь, пожалуйста, помогло или нет.
Да спасибо, все получилось
Супер, рад Вам помочь.
А не подскажите имеется модуль nm-2ce1t1-pri, в системе она отображается
controller E1 1/0
framing NO-CRC4
pri-group timeslots 1-31
!
…….
!
interface Serial1/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
и тут не знаю как быть дальше
начинаю прописывать
voice-port 1/0:15
не дает какой voice-port прописывать?
не подскажите что за причина может быть
Хм, странная ситуация… а в sh run тоже voice-port не отображается?
да и в sh run не видит ее,
cisco 28 серии, в маршрутизаторе уже имеется 2 портовая плата vwic2-mft-t1/e1 и она прекрасно работает
interface Serial0/2/1:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
interface Serial0/2/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
controller E1 0/2/0
framing NO-CRC4
pri-group timeslots 1-31
controller E1 0/2/1
framing NO-CRC4
pri-group timeslots 1-31
voice-port 0/2/0:15
voice-port 0/2/1:15
а вот появилась необходимость установить еще одну, и вот проблема не появляется voice-port и все, и главное в конфигурации она отображается и контроллер и интерфейс serial
Осмелюсь спросить, а DSP в плате NM (т.е в 1 слоте) установлены? Можете, пожалуйста, показать вывод команды sh diag? (если не поместится, разбейте ее на несколько постов).
Добрый день!
По предыдущим постам….осмелюсь предположить, что данный модуль "nm-2ce1t1-pri" не поддерживает передачу голоса, только передачу данных, поэтому и "voice-port не отображается"….
Пробуйте погуглить, я когда-то находил обсуждения данного модуля, там сказано, что "Data only"…
Вам поможет только другой модуль в этой ситуации, на этом Voice-port вы поднять не сможете к сожалению…
Дмитрий, подскажите, такая проблема…Сотрудники удаленного офиса жалуются, что связь иногда жалуется и прерывается, команда Sh controller e1 0/0/0 показывает, что ошибок, слипов и т.д. нет.
Где бы ещё копнуть,чтобы убедиться, что проблема именно в циске или копать в другом направлении? Свою конфигурацию я вам по почте когда-то отправлял…
Добрый день, Евгений!
По Вашей проблеме – связь пропадает при звонке с удаленного офиса в их городскую сеть? Какой там шлюз стоит? MGCP или H323/SIP?
Если шлюз MGCP, то связь может обрываться по причине недоступности колменеджера через WAN. При этом падает D-канал. Эту ситуацию можно отловить если за шлюзом понаблюдать (или лог писать и просмотреть) – сообщение об отваливании D-канала в консоль шлюза выдается.
Дмитрий,добрый день!
Шлюзы работают по H323, принимают на voice-port и "упаковываю" поток E1 от ведомственных АТС. Между собой циски "общаются" по арендованному у провайдера 1 мб/сек L2 каналу, войсовые кодеки g711.
Проблемы со связью возникают при звонках на внутренние номера между удаленными подразделениями и центральным офисом, такое чувство, что часть пакетов "теряется"… Ресурсов оборудования для обработки трафика более чем достаточно, стоят c2821, Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T3, модули VWIC2-1MFT-G703, по два PWDM2-32 кодека.
Для начала хотелось бы узнать причину потери пакетов, может одна из цисок их "отбрасывает" из-за превышения очереди на отправку, или они не доходят до получателя из-за проблем с каналом…
Добрый день, Евгений!
Ну раз проблема со звонками между внутренними абонентами, то Е1 тут однозначно не причем. Скорее всего, проблема связана с перегрузкой полосы, выделенной под войс.
Из вашей конфигурации следует, что в настройках QoS установлено следующее:
class VOICE
priority percent 18
Это значит, что из 1Мб полосы, под голос выделено всего 180 кб/с. Если совершаются звонки с кодеком G711, то в такую полосу поместится всего лишь 2 звонка (1 звонок занимает примерно 80кб/с). Если будет более 2х звонков, то данная полоса будет перегружена, а отсюда следуют и пропадания пакетов.
Решение следующее – либо увеличивайте полосу для голоса, либо переводите звонки в режим кодека G729 (этот кодек и рекомедуется вендором для звонков через WAN). G729 имеет полосу примерно 25кб/с, т.е в ваших 180 кб/с поместится без проблем 7 звонков (более 7ми снова вызовет перегрузку выделенной войсовой полосы).
Проверить, есть у вас перегруженный канал, можно с помощью команды show policy-map. Вот пример (из оф. учебника Cisco):
router>show policy-map interface fastethernet 0/0
FastEthernet0/0
Service-policy output: LLQ
Class-map: LLQ (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 1000 (kbps) Burst 25000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Если будет перегрузка, то увидите сброшенные (drop) пакеты.
Добрый день.
Cisco 3925 испольузется как голосовой шлюз, который принимает поток Е1 и отдает потом на АТС LG, также по Е1.
Настройки синхронизации такие:
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-31
description ===== E1 ISP =====
Т.е. от провайдера берется синхронизация.
controller E1 0/1/0
framing NO-CRC4
clock source internal
pri-group timeslots 1-31
description ==== to PBX ====
!
controller E1 0/1/1
framing NO-CRC4
clock source internal
pri-group timeslots 1-31
description ==== to PBX ====,
Cisco назначается в качестве источника сихнронизации, т.е. мастера для АТС.
#sh network-clocks
Network Clock Configuration
—————————
Priority Clock Source Clock State Clock Type
1 E1 0/0/0 GOOD E1
Но контроллере подключенным к провайдеру слипов нет, а вот те которые подключены к АТС, огромное количество.
sh controllers E1
E1 0/0/0 is up.
Applique type is Channelized E1 – balanced
Description: ===== E1 ISP =====
No alarms detected.
alarm-trigger is not set
Version info FPGA Rev: 08121917, FPGA Type: PRK1
Framing is NO-CRC4, Line Code is HDB3, Clock Source is Line.
International Bit: 1, National Bits: 11111
Data in current interval (276 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
E1 0/1/0 is up.
Applique type is Channelized E1 – balanced
Description: ==== to PBX ====
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20100222, FPGA: 13, spm_count = 0
Framing is NO-CRC4, Line Code is HDB3, Clock Source is Internal.
Data in current interval (249 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
39 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
39 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
13479 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
13479 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
E1 0/1/1 is up.
Applique type is Channelized E1 – balanced
Description: ==== to PBX ====
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20100222, FPGA: 13, spm_count = 0
Framing is NO-CRC4, Line Code is HDB3, Clock Source is Internal.
Data in current interval (250 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
39 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
39 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
13479 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
13479 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
…
…
Звонки ходят нормально, с факсами вроде проблем нет, но вот решили завести в АТС телефон для модемного дозвона и модем не подключеается, грешим как раз на слипы.
В последователых интерфейсах до АТС выставлен режим network:
interface Serial0/1/0:15
description ===== E1_ISDN_PBX_VOICE =====
no ip address
encapsulation hdlc
no logging event link-status
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no cdp enable
!
interface Serial0/1/1:15
description ===== E1_ISDN_PBX_VOICE =====
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no cdp enable
Читал, что слипы также могут возникать, если источники заземления для cisco и атс разные – проверили, заземления есть и источник земли один.
На АТС стоит переключатель jumper в положение slave, т.е. должно как раз брать синхронизацию с циски нормально…
Подскажите по такой проблеме.
Здравствуйте, Максим!
А какого типа (марки, модели) АТС у вас стоит? Запрограммировано ли на ней, что она будет синхронизироваться от циски?
Джампер в положении slave – это хорошо, конечно. Но сам режим slave еще НЕ ОЗНАЧАЕТ, что АТСка ДОЛЖНА принимать синхронизацию. Как правило, это еще и программируется отдельно (например, указывается порт или плата с потоком Е1, по которому будем синхронизироваться).
На АТС Меридиан (Nortel) все это программируется в настройках платы клок-контроллера, например.
Поэтому, для начала, пожалуйста, проверьте (или попросите связистов проверить), все ли настройки для получения синхры сделаны на самой АТСке. У циски вроде все настройки, на первый взгляд, сделаны правильно.
Спасибо большое, ваша информация как всегда пригодилась.
Был прописан voice-class 1, прописал принудительно на обеих машинах кодек G729r8, связь стала значительно лучше… Интересно, а с Хуавеем они по этому кодеку смогут договориться? (мысли вслух)
по поводу Qos и policy-map сразу возник новый вопрос…
Вот кусок конфигурации циски в центральном офисе (перенастраивал все праздники, реализовал таки свою задумку по router-on-a-stick, только вместо отдельного свича использовал NM 16-портовый модуль)
interface GigabitEthernet0/1
description ***Trunk_To_G1/0***
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/1.100
description ***To_Uchta***
bandwidth 1024
encapsulation dot1Q 100
ip address 172.16.11.1 255.255.255.240
!
interface GigabitEthernet0/1.200
description ***To_ChovU***
bandwidth 1024
encapsulation dot1Q 200
ip address 1.1.1.1 255.255.255.252
!
interface GigabitEthernet0/1.300
description ***To_Mikun***
bandwidth 1024
encapsulation dot1Q 300
ip address 172.16.12.1 255.255.255.240
!
interface FastEthernet1/0
description ***WAN_Uchta+Vorkuta***
switchport access vlan 100
!
interface FastEthernet1/1
description ***WAN_ChovU***
switchport access vlan 200
!
interface FastEthernet1/2
description ***WAN_Mikun***
switchport access vlan 300
!
interface GigabitEthernet1/0
description ***Trunk***
switchport mode trunk
Проблема в том, что не могу теперь "повесить" policy-map output на интерфейсы.
Физические интерфейсы свича,в которые приходят каналы, мне отвечают:
(config-if)#service-policy output LOCAL-WAN-EDGE
%Error: FastEthernet1/0 Service Policy Configuration Failed.
Only IN Direction Supported
Виртуальный G0/1.100 говорит,что:
(config-subif)#service-policy output LOCAL-WAN-EDGE
CBWFQ : Not supported on subinterfaces
Как быть? О_о
Добрый вечер, Евгений!
Попробуйте почитать вот эту статейку:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080114326.shtml
Как раз Ваш случай описан. Если будет нужна дополнительная помощь – пишите.
Да, и по поводу кодека для Хуавея – думаю, что G729 там тоже поддерживается. Стандартный кодек, ничего военного, все вендоры обычно с ним работают.
Спасибо за отклик.
АТС LG Nortel. Всячески смотрели конфигурацию АТС, на самих платах положение джамперов и прочего, все вроде бы верно. Однако, пока ничего не помогает. Таких параметров, чтобы выбирать источник синхронизации, кроме джапера в положении slave,
согласно документации не обнаружили.
Проверили состояние на АТС:
• Разъемы CN3 без джампера. Разомкнуто на обеих платах;
• Переключатели SW1 все в OFF на обеих платах;
• CRC контроль на 3925 выключен, а на АТС – выключен переключателем SW1 в OFF;
Модем номер набирает, но не идет передача данных, т.е. с той стороны нет соединения.
Проверили через этот sip-номер настроить звонки на сотовый – все нормально, а модем никак. Пока поступило предложение об изьятии одной из плат и проверка только на одной – возможно, сбои из-за внутренней синхронизации или поменять направление синхронизации.
Изымать плату очень не хочется, по соощбениям коллег это требует ребута АТС, часто возникают проблемы после обратное включения платы и прочее, в общем, неприятная процедура.
Добрый день, Максим!
Как только будет свободная минутка, попробую посмотреть документацию на LG-Nortel (это не Меридиан, увы) и глянуть, как там настраивается синронизация Е1. В данный момент веду курс в Турции, поэтому все свое рабочее и свободное время уделяю ему.
Напишите еще, пожалуйста, какая именно у вас модель из LG-Nortel, чтоб я знал, какой мануал искать.
Модель LG-Nortel LDK300.
Премного благодарен за помощь, но пока зашли в тупик. Сами инструкцию по АТС читали, да и чего только не читали…плату только осталось вытащить.
Добрый вечер, Максим!
Попробовал чуток покопать про вашу АТСку (насколько время позволяет). В мануалах с наскока ничего внятного не нашел про синхронизацию. Однако, наткнулся на интересное обсуждение подобной проблемы на одном из форумов:
http://mini-ats.info/index.php/conf/viewthread/36975/P0/
Из него я понял, что вроде как синхронизация никак не настраивается, но важно местоположение платы PRI и подключенные к ней кабели синхронизации. Как я понял из данного обсуждения, сама плата синхронизации находится на борту платы MPB.
А что показывает светодиод LED1 на плате MPB? (ON – внешняя синхронизация от ISDN платы; OFF – синхронизация от внутреннего источника синхронизации). Все ли правильно подключено между платой PRI и платой MPB?
Что также показывает LED1 на плате PRIB? (ON – потеря синхронизации, OFF – норма).
Попробуйте задать вопрос по синхре и на том форуме, он посвящен именно таким АТСкам. Может быть более опытные по этим АТСкам люди подскажут, как с такой проблемой побороться.
Спасибо за помощь, но пока проблема так и не решилась. Спросил на форуме, что вы подсказали, обьяснил ситуацию. Сказали, что кабели синхронизации подключены верно, зато навели на другую мысль, что может быть косяк в плате E1, она у нас сдвоенная. Вот нашел аналогичную ситуацию – связь работает, но слипы огромные. http://www.certification.ru/cgi-bin/forum.cgi?action=thread&id=41109&page=1 К сожалению, проверить на другой карте нет возможности пока. Что вы думаете по этому поводу?
Также, еще один вариант подсказали, цитирую: "Факсы он распознает и отрабатывает по T38, а сигнал от модема пропускает как голос без обработки?? Поэтому модем и не работает??".
Факсы через обычную линию, т.е. если вместо любого текущего телефона подключить обычный факсимильный аппарат и отправить факсы через 9, т.е. наш обычный выход на город – проверил и работает. Настройки данного диал-пира таковы:
dial-peer voice 9 voip
tone ringback alert-no-PI
description ==== to SIP ISP ====
translation-profile outgoing 63
destination-pattern .T
progress_ind setup enable 3
progress_ind alert enable 8
modem passthrough protocol codec g711alaw
session protocol sipv2
session target ipv4:[IP ISP:PORT]
voice-class codec 1000
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/2.183
voice-class sip bind media source-interface GigabitEthernet0/2.183
dtmf-relay rtp-nte sip-notify sip-kpml
fax rate 14400
clid strip name
no vad
Как я понял, основная строка тут – modem passthrough protocol codec g711alaw
Верно ли это, может что-то еще для модема нужно? Например протокол т.38?
Доброе утро, Максим!
Посмотрел ссылку, действительно, вполне может быть, что на циске битая карта (т.е порты Е1 0/1/0 и 0/1/1). А карта для портов 0/0/0 и 0/0/1 у вас такого же типа? Попробуйте поменять карты местами, хотя бы временно и посмотрите изменится ли картина.
По поводу вопроса о dial-peer voice 9 voip, могу сказать следующее. Я полагал, что факсы и модемные соединения у вас работают исключительно по Е1. Ранее Вы писали следующее:
"Cisco 3925 используется как голосовой шлюз, который принимает поток Е1 и отдает потом на АТС LG, также по Е1."
Из чего, вроде как, следовало, что абоненты LG звонят в город так: Е1 до циски, Е1 от циски в город. dial-peer voice 9 voip у вас настроен для звонков через VoIP сеть с сигнализацией SIP.
Так как же все таки звоните в город? Через Е1 или через SIP? Если по VoIP, то возможны два режима передачи пакетов сигналов модема – passthrough или relay. Нужно узнать, какой из способов настроен на второй стороне (и настроен ли вообще) и тогда, соответственно, настроить циску. Т.38 для передачи модемных сигналов не применяется – только для факсов.
"А карта для портов 0/0/0 и 0/0/1 у вас такого же типа? Попробуйте поменять карты местами, хотя бы временно и посмотрите изменится ли картина." В том-то и дело что там карта на 1 порт E1, поэтому поменять не выйдет. Сейчас думаем где взять для теста плату, сняли дебаг дозвона на модем – смотрим. Просто странно, что такое кол-во ошибок, а факсы и головые звонки ходят без проблем.
Временно вывели с аналогового порта 3925 на модем через voice port – так все работает. Хотелось бы универсального решения через voip, так же как работают факсы.
"Из чего, вроде как, следовало, что абоненты LG звонят в город так: Е1 до циски, Е1 от циски в город. dial-peer voice 9 voip у вас настроен для звонков через VoIP сеть с сигнализацией SIP.
Так как же все таки звоните в город? Через Е1 или через SIP?"
У нас факсы выведены как через 2 аналоговые линии cisco 3925 на факс-сервер, также настроена возможность отправки факсов через voip. Звонки и факсы идут через SIP-trunk провайдера.
Доброе утро, Максим!
Если я правильно понимаю, то если подключить модем к аналоговому порту (FXS) на самой циске, то все нормально работает? А не работает передача модемных сигналов, если модем находится на порту LG? Верно?
Если это так, то могу предположить, что VoIP часть циски настроена правильно, поскольку VoIP транк общий и для модемных звонков с аналогового порта циски, и для модемных звонков от удаленной АТС через Е1. В этом случае надо "добить" проблему с синхрой.
Здравствуйте. У нас есть старая мини-АТС и поток E1, сейчас планируем переходить на ip телефонию. Есть 2921 с двухпортовой картой E1, которую я пытаюсь поставить между ГАТС и мини-АТС.
Конфиг:
network-clock-participate wic 0
network-clock-select 1 E1 0/0/0
controller E1 0/0/0
description ==TO PSNT===
framing NO-CRC4
pri-group timeslots 1-31
!
controller E1 0/0/1
description ==TO PBX===
framing NO-CRC4
clock source internal
pri-group timeslots 1-31
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
isdn map address . plan unknown type unknown
no cdp enable
!
interface Serial0/0/1:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
isdn map address . plan unknown type unknown
no cdp enable
voice-port 0/0/0:15
timeouts interdigit 6
!
voice-port 0/0/1:15
timeouts interdigit 6
dial-peer voice 1000 pots
port 0/0/0:15
forward-digits all
При попытке выполнить звонок с мини-АТС в выводе появляется следующее
Я не понимаю почему called number вообще отсутствует? Подскажите пожалуйста, что может быть не так настроено?
rtr#
Aug 31 11:58:00.228: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8 callref = 0x0C00
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Calling Party Number i = 0x0080, '8463334401'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Aug 31 11:58:00.228: ISDN Se0/0/1:15 Q931: Received SETUP callref = 0x8C00 callID = 0x0001 switch = primary-net5 interface = Network
Aug 31 11:58:00.232: ISDN Se0/0/1:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8C00
Channel ID i = 0xA98381
Exclusive, Channel 1
Aug 31 11:58:00.232: ISDN Se0/0/1:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8C00
Cause i = 0x829C – Invalid number format (incomplete number)
Aug 31 11:58:00.472: ISDN Se0/0/1:15 Q931: RX <- RELEASE pd = 8 callref = 0x0C00
Aug 31 11:58:00.472: ISDN Se0/0/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8C00
Доброе утро,
Это проблема мини-АТС, на ней, видимо, что-то настроено неправильно. С ее стороны приходит SETUP, и она должна прислать Called Number. Циска же не может сама себе прислать это поле, верно?
Поэтому, нужно разбираться, прежде всего, с настройками встречной стороны и добиться нормального SETUP со всеми параметрами.
На будущее: обратите внимание также на то, что Вы не прописали в диал-пире 1000 параметр destination-pattern. Если Вы собираетесь использовать его для исходящего звонка в сторону мини-АТС, то звонок не будет смаршрутизирован.
Просто пересматривая все команды подряд, наткнулся на
isdn overlap-receiving
и статью
http://www.cisco.com/en/US/tech/tk801/tk133/technologies_tech_note09186a00800b48cb.shtml
После указания этой команды
isdn overlap-receiving T302 3000
все заработало.)))
Не могли бы Вы подсказать, что это вообще за режимы En bloc or Overlap?
мини-АТС у нас стоит почти как черный ящик ее кто-то давно настроил и с тех пор не трогали. Я все-таки исходил из предположения, что я на циске что-то не донастроил, так как если E1 воткнуть обратно в мини-АТС, то все звонки проходят нормально.
Существуют ли еще какие-то настройки из-за которых called number может не восприниматься/не распознаваться?
Overlap и En-Block – это способы передачи цифр в сообщении SETUP. Overlap – это передача цифра за цифрой, а En-block – это передача всего набранного номера пакетом. На вашей мини-АТС, видимо, настроен Overlap, а на циске всегда по дефолту стоит En-block.
Поэтому, Вам и помогла команда isdn overlap-receiving. Она переводит циску на прием по методу Overlap.
Однако, остается открытым вопрос, почему мини-АТСка не слала called-number. При Overlap он тоже должен присылаться, но содержать первую цифру или часть (не полностью) Called-номера.
А как сейчас дело с Called обстоит? Можете ли, пожалуйста, прислать дебаг входящего звонка при работающем потоке? Просто, ради интереса – уж очень необычный случай.
Спасибо. Судя по дебагу called namber был прислан через 300ms после основного setup.
rtr#
Sep 1 09:53:59.018: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8 callref = 0x1773
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Calling Party Number i = 0x80, '8463334401'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Sep 1 09:53:59.018: ISDN Se0/0/1:15 Q931: Received SETUP callref = 0x9773 callID = 0x00A9 switch = primary-net5 interface = Network
Sep 1 09:53:59.022: ISDN Se0/0/1:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x9773
Channel ID i = 0xA98381
Exclusive, Channel 1
Progress Ind i = 0x8188 – In-band info or appropriate now available
Sep 1 09:53:59.346: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x1773
Called Party Number i = 0x81, '93330005'
Plan:ISDN, Type:Unknown
Sep 1 09:53:59.346: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num 8463334401
Sep 1 09:53:59.346: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x00D1 callID = 0x804F switch = primary-net5 interface = User
Sep 1 09:53:59.346: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x00D1
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9839F
Exclusive, Channel 31
Calling Party Number i = 0x80, '8463334401'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x81, '93330005'
Plan:ISDN, Type:Unknown
High Layer Compat i = 0x9181
Sep 1 09:53:59.426: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x80D1
Channel ID i = 0xA9839F
Exclusive, Channel 31
Progress Ind i = 0x8181 – Call not end-to-end ISDN, may have in-band info
Sep 1 09:53:59.430: ISDN Se0/0/1:15 Q931: TX -> PROGRESS pd = 8 callref = 0x9773
Progress Ind i = 0x8181 – Call not end-to-end ISDN, may have in-band info
Sep 1 09:53:59.434: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8 callref = 0x80D1
Progress Ind i = 0x8188 – In-band info or appropriate now available
Sep 1 09:53:59.434: ISDN Se0/0/1:15 Q931: TX -> PROGRESS pd = 8 callref = 0x9773
Progress Ind i = 0x8188 – In-band info or appropriate now available
Sep 1 09:53:59.674: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x80D1
За основную статью так же Спасибо. Разобрался со slip'ами.
Осталась вроде одна проблема при звонке с атс. Схема такая:
тел. – мини-АТС =E1= циска =E1= PSNT – мой.мобильник
Если я звоню с тел. на свой мобильник и сбрасываю на мобильнике, то на телефоне продолжают идти гудки как будто идет дозвон. С чем это может быть связано?
Не совсем так, Called пришел только после того, как циска его запросила сообщением SETUP ACK. Только после этого пришли все цифры в сообщении INFORMATION, причем все цифры пришли в одном сообщении, что нетипично. Видимо, у этой мини-АТС какая-то своя реализация Overlap… Бывает же такое, однако 🙂
По проблеме отбоя – нужно для начала смотреть дебаг на стыке Е1-PSTN и увидеть, приходит ли отбой из города. А какая сигнализация (Н323 или SIP) у вас используется между цисками?
В моей схеме только одна циска, а подключения в обе стороны E1. Было pstn-атс, стало psnt-cisco-атс.
Ни debug voice ccapi all, ни debug isdn q931 в момент отбоя ничего не выводят.
Становится яснее 🙂 Но все равно, если вы звоните в город по е1, Вы должны видеть дебаг, подобный тому, который Вы видите при входящем звонке.
Можете, пожалуйста, показать полный дебаг исходящего звонка, начиная от момента звонка и до момента отбоя, когда Вы сбрасываете звонок на мобильном?
Дебаг, конечно, засорен другим дебагом (debug voip ccapi inout), но ничего, разберемся :). По дебагу видно, что город вам ничего не шлет в момент отбоя на вашем мобильном. Циска, соответственно, ничего не шлет в сторону мини-АТС, так как город ей не сказал об отбое. Поэтому, вы и слышите длинные гудки (КПВ).
Для иллюстрации я выберу нужные сообщения:
Sep 1 10:35:45.997: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8 callref = 0x2473 – это сетап от мини-АТС
Sep 1 10:35:46.001: ISDN Se0/0/1:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xA473 – это подтверждение от циски и запрос Called номера
Sep 1 10:35:46.273: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x2473 – получение цифр циской
Обратите внимание на callref, он определяет, какие сообщения к какому звонку относятся.
Sep 1 10:35:46.281: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x00DD – сетап от циски в город, установление звонка по второму е1
Sep 1 10:35:46.313: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x80DD – подтверждение занятия городом
Sep 1 10:35:47.277: ISDN Se0/0/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x00DD – уведомление от циски в сторону города, что набор окончен
Sep 1 10:35:50.997: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x80DD – обработка вызова городом
Sep 1 10:35:54.353: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x80DD – посылка вызова от города к циске
Sep 1 10:35:54.357: ISDN Se0/0/1:15 Q931: TX -> ALERTING pd = 8 callref = 0xA473 – посылка вызова от циски к мини-АТС
В этот момент вызывающий слышит КПВ. Далее ничего не происходит, хотя при отбое город должен прислать вам DISCONNECT. Поэтому, звонящий продолжает слышать гудки.
Далее, видимо, вызывающий кладет трубу:
Sep 1 10:36:28.221: ISDN Se0/0/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x2473 – отбой от мини-АТС к циске
Sep 1 10:36:28.221: ISDN Se0/0/1:15 Q931: TX -> RELEASE pd = 8 callref = 0xA473 – освобождение от циски к мини-АТС
Sep 1 10:36:28.225: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x00DD – отбой от циски к городу
Sep 1 10:36:28.249: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x80DD – освобождение от города к циске.
Я бы порекомендовал у провайдера спросить, почему они не шлют вам DISCONNECT. А до включения циски все работало корректно?
Сейчас уже не получится проверить времени уже нет, а с провайдером у нас вообще все сложно))) На неделе постараюсь еще сам посмотреть, проверить. Спасибо.
Добрый день!
Помогите советом, что может быть не так.
есть арендованный канал E1 у Ростелеком, данный поток включается в cisco 2911.Задача сделать из cisco мультиплексор, принять часть потока , а остальные тайм слоты оттранслировать в АТС. Это все работает только почему то не стабильно, постоянно падает протокол interface Serial0/2/0:13 если отключаю порт в cisco controller E1 0/2/1, то все работает стабильно, все настройки атс совпадают с настройками cisco
controller E1 0/2/0
framing NO-CRC4
channel-group 13 timeslots 12-15
tdm-group 1 timeslots 1-11,16
description RTK
controller E1 0/2/1
framing NO-CRC4
tdm-group 1 timeslots 1-11,16
description ATS
connect tlf E1 0/2/0 1 E1 0/2/1 1
interface Serial0/2/0:13
no ip address
encapsulation ppp
bridge-group 1
bridge-group 1 spanning-disabled
sh interface Serial0/2/0:13
Serial0/2/0:12 is up, line protocol is down
Добрый день,
Правильно ли я понимаю, что проблема существует именно для интерфейса передачи данных? Как часто "падает" протокол? Периодически? Или он постоянно в down?
Ну и банальный вопрос – синхронизация на портах Е1 настроена (в соответствии с моей статьей)? Слипов нет? По идее, у вас порт 0/2/1 должен принимать синхру (clock source line), а порт 0/2/0 – отдавать (clock source internal). Также не забудьте про network-clock-select. Для вашего случая она выглядит так:
netwrok-clock-select 1 e1 0/2/1
Доброй день!
совершенно верно проблема только для интерфейса передачи данных, а падает он когда ему это захочется, может проработать неделю а может и через час.
У меня порт controller E1 0/2/1(clock source internal) смотрит на АТС, в свою очередь АТС берет синхронизацию от cisco. а второй порт controller E1 0/2/0 (clock source line) смотрит на сеть провайдера и синхронизацию берет от туда , в данной конфигурации слипов нету совсем
Если 0/2/0 смотрит в сеть провайдера, то тогда да, синхру нужно брать от него, а отдавать на АТС.
Странно то, что при выключении порта на АТСку все, как я понял, работает нормально. А не пробовали эту же конфигурацию, но на другом IOS? Может баг какой?
Добрый день!
нет еще не пробовали, но мысли такая была, я тогда попробую и отпишусь. Спасибо Вам за помощь.
Добрый день! Прошу совета.
Есть М200 и Cisco AS5350, подключены между собой по PRI. Звонок с М200 приходит на Циску, далее циска уже посылает вызов на вышестоящего оператора по SIP.
Поток подключили, ошибок по синхронизации нет, слипов нет. Звонок проходит, но при разговоре сильные помехи.
В чем может быть причина? Пробовали перекидывать поток на другую плату Е1, меняли порт на М200. Привожу настройки:
controller E1 3/0
framing NO-CRC4
pri-group timeslots 1-31
sh int ser 3/0:15
Serial3/0:15 is up, line protocol is up (spoofing)
Hardware is DSX1
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Last input 00:00:17, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 48 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
13570 packets input, 56099 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
71 input errors, 51 CRC, 0 frame, 0 overrun, 0 ignored, 5 abort
17560 packets output, 71676 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
5 carrier transitions
interface Serial0/0
no ip address
no ip mroute-cache
clock rate 2000000
!
interface Serial0/1
no ip address
no ip mroute-cache
clock rate 2000000
voice-port 3/0:D
disc_pi_off
echo-cancel coverage 32
cptone RU
bearer-cap Speech
dial-peer voice 40 pots
description from xxxx
translation-profile incoming Sisamara
incoming called-number 010.T
direct-inward-dial
dial-peer voice 23000 voip
tone ringback alert-no-PI
description Out Leg 4 xxx – DEF calls via Mera MVTS
translation-profile outgoing International
destination-pattern [78]9T
voice-class codec 711
voice-class h323 100
session target ipv4:xxxx
session transport udp
dtmf-relay h245-alphanumeric
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs5 media
ip qos dscp ef signaling
no vad
voice translation-rule 8500
rule 1 /^810/ /810/ type any international plan any isdn
rule 2 /^846(.*)/ /78461/ type any international plan any isdn
rule 3 /^8(.*)/ /71/ type any international plan any isdn
voice translation-rule 810500
rule 1 /^810/ /810/ type any international plan any isdn
rule 2 /^846(.*)/ /78461/ type any international plan any isdn
rule 3 /^8(.*)/ /71/ type any international plan any isdn
rule 4 /^0107(.*)/ /71/ type any international plan any isdn
voice translation-profile xxxx
translate calling 8500
translate called 810500
М200 источник синхры, код hdb3, без проверки crc4
Пример звонка:
Total call-legs: 2
2436 : 19241 108913550ms.1 +9390 pid:40 Answer 78462777702 active
dur 00:06:17 tx:18759/3001440 rx:19031/3044960
Tele 3/0:D (19241) [3/0.18] tx:380630/263000/0ms g711alaw noise:-45 acom:89 i/0:-23/-28 dBm
2436 : 19242 108913550ms.2 +9380 pid:23000 Originate 79376538527 active
dur 00:06:17 tx:19031/3044960 rx:18989/3038240
IP 193.43.208.3:30150 SRTP: off rtt:83ms pl:137000/5965ms lost:275/61/273 delay:125/55/150ms g711alaw
Кодеки одинаковые, конфликтов вроде нет.
Добрый день,
Для уточнения ситуации я задам Вам несколько уточняющих вопросов. Это новое подключение или ранее работавшее? Какого рода помехи Вы слышите? Это дополнительные звуки или искажения речи?
Из присланной конфигурации видно, что в диалпире 23000 не используется SIP, по крайней мере нет команды session protocol sipv2. Но это не меняет сути дела, так как это всего лишь сигнализация.
Попробуйте посниферить голосовые пакеты вайршарком и послушать их (вайршарк имеет такую возможность). Слышите ли Вы искажения в RTP? Это необходимо для локализации проблемы, чтобы понять, какое устройство дает помеху. Засинхронизированы ли на шлюзе DSP (команда network-clock-participate)?
Дмитрий, добрый день!
Снова обращаюсь к Вам за помощью:
Существует такая схема подключения двух УАТС: УАТС—-Е1—-Cisco2921—–Ethernet(H323)—–Cisco2651—-Е1—-УАТС.
Появилась следующая проблема – при звонках со стороны Cisco2921 в сторону Cisco2651 абонент после длинной паузы слышит в трубке отбой.
При звонке был снят такой дебаг:
Oct 16 11:34:25.025: ISDN Se0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x01BE
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9839F
Exclusive, Channel 31
Called Party Number i = 0x81, '2923'
Plan:ISDN, Type:Unknown
Oct 16 11:34:25.057: ISDN Se0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x81BE
Channel ID i = 0xA9839F
Exclusive, Channel 31
Oct 16 11:34:25.057: ISDN Se0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x81BE
Progress Ind i = 0x8282 – Destination address is non-ISDN
Progress Ind i = 0x8288 – In-band info or appropriate now available
c2651-37-OnoK#
Oct 16 15:34:25 Ivanovo: %C5421-1-NO_RING_DESCRIPTORS: No more ring descriptors available on slot 0 dsp 8.
c2651-37-OnoK#
Oct 16 11:34:34.465: ISDN Se0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x81BE
Oct 16 11:34:34.469: ISDN Se0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x01BE
c2651-37-OnoK#
Oct 16 15:34:34 Ivanovo: %C5421-1-NO_RING_DESCRIPTORS: No more ring descriptors available on slot 0 dsp 8.
c2651-37-OnoK#
Oct 16 15:34:39 Ivanovo: %C5421-1-NO_RING_DESCRIPTORS: No more ring descriptors available on slot 0 dsp 8.
c2651-37-OnoK#
Oct 16 11:34:40.383: ISDN Se0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x81BE
Cause i = 0x8190 – Normal call clearing
Oct 16 11:34:40.387: ISDN Se0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x01BE
Oct 16 11:34:40.395: ISDN Se0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x81BE
c2651-37-OnoK#
Oct 16 15:34:48 Ivanovo: %DSM-3-DSP_TIMEOUT: DSP timeout on channel 0/0:15 (2703), event 0x59: DSP ID=0x83: DSP error stats
Oct 16 11:34:48.396: chnl info(0, 8, 2)
c2651-37-OnoK#
Oct 16 15:34:48 Ivanovo: %C5421-1-NO_RING_DESCRIPTORS: No more ring descriptors available on slot 0 dsp 8.
Помогите разобраться в чем может быть дело.
Доброе утро, Александр!
Тут, похоже, баг 🙁 Взгляните сами:
https://supportforums.cisco.com/docs/DOC-3194
IOS на 2651 придется, видимо, сменить.
Здравствуйте, Дмитрий!
Вчера помогла презагрузка маршрутизатора. Проблема эта может дальше повторяться?
Если это баг, то да, он может повториться и в дальнейшем.
Добрый день!
У меня тоже была такая проблема на циске 5350 ss7 over e1, поставил tdm clock priority 1 external, счетчик обнулил, уже как 3 дня СЛИПОВ не наблюдаю.
Вопрос – в данном случае ss7 over e1 щелчки, потрескивания, помехи тоже актуальны ?
Добрый день, Антон!
Конечно, актуальны. Принципы же передачи речи не меняются. В SS7 ведь тоже TDM, только принцип пересылки и формат сигнальных сообщений другой. А транспорт тот же – таймслоты, е1, итд.
Здравствуйте. Подскажите пожалуйста в чем может быть беда.
АТС подключена к циске (2921, vwic2-1mft-g703) потоком е1. Номерной план в поток 16хх. К циске подключен сипфон, регистрация сипфона на циске прошла успешно. Звонки идут с сипфона в сторону АТС нормально, но во время разговора бывает кратковременное пропадание голоса одного из абонентов. если звонить со стороны АТС на сипфон – звонок не проходит вообще. Вот конфиг
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
card type e1 0 0
!
no aaa new-model
network-clock-participate wic 0
network-clock-select 1 E1 0/0/0
!
no ipv6 cef
ip source-route
ip cef
!
multilink bundle-name authenticated
!
isdn switch-type primary-net5
!
crypto pki token default removal timeout 0
!
voice-card 0
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
redirect ip2ip
signaling forward unconditional
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
registrar server expires max 3600 min 3600
!
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729br8
!
!
voice register global
mode cme
source-address 192.168.10.10 port 5060
max-dn 50
max-pool 10
!
voice register dn 1
number 1601
!
voice register pool 1
id mac 3408.0429.F2B2
number 1 dn 1
voice-class codec 1
username cisco password cisco
!
license udi pid CISCO2921/K9 sn FCZ1234740E7
hw-module pvdm 0/0
!
hw-module sm 1
!
!
!
!
redundancy
!
!
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-17
!
!
!
!
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
ip address 192.168.10.10 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet0/2
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
isdn send-alerting
no cdp enable
!
interface GigabitEthernet1/0
no ip address
shutdown
!
interface GigabitEthernet1/1
description Internal switch interface connected to EtherSwitch Service Module
no ip address
!
interface Vlan1
no ip address
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
control-plane
!
voice-port 0/0/0:15
cptone RU
bearer-cap Speech
!
mgcp profile default
!
dial-peer voice 10 voip
destination-pattern 1601
session protocol sipv2
session target ipv4:192.168.10.2
session transport udp
voice-class codec 1
dtmf-relay rtp-nte
no vad
!
dial-peer voice 3 pots
service session
destination-pattern .T
direct-inward-dial
port 0/0/0:15
forward-digits all
!
gatekeeper
shutdown
!
line con 0
line aux 0
line 2
no activation-character
no exec
transport preferred none
transport input all
transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
stopbits 1
line 67
no activation-character
no exec
transport preferred none
transport input all
transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
stopbits 1
flowcontrol software
line vty 0 4
login
transport input all
!
scheduler allocate 20000 1000
end
Добрый день, Илья!
Конфига – это, конечно же, хорошо, но для точного выяснения проблемы потребуется сделать дебаги. Нужно сделать для неуспешных звонков два дебага – debug isdn q931 и debug ccsip messages.
По самой конфиге – мне не понятен, зачем настроен dial-peer 10. Если для отправки звонка на сип-телефон, то этот диал-пир не нужен.
Дебаги можете прислать через форму для связи, и, конечно же, напишите в ней адрес Вашей почты,
debug isdn q931 и debug ccsip messages при звонке на сипфон с номером 1601 не выдал вообще ничего. Как будто звонка вообще не было.
А Вы консольным кабелем подключаетесь к роутеру? или телнетом/ssh? Если телнетом/ssh, то нужно еще давать команду terminal monitor, иначе сообщения дебага не видны.
напрямую консольным в роутер, terminal monitor прописан, при звонке с сипфона в сторону атс дебаг идет
Если так, что это означает, что ваша АТСка не маршрутизирует вызов в сторону роутера по Е1. Если бы она это делала, то Вы бы видели дебаги.
С Е1 все в порядке, так как Вы можете совершать исходящие звонки, а это значит, что и физика и канальный уровень в порядке. В противном случае исходящие от вас были бы невозможны.
Спасибо огромное, действительно были проблемы с маршрутизацией звонков на АТС. В данный момент звонки проходят в обе стороны. Есть небольшое это в трубке со стороны АТС (абонент слышит сам себя) – это как то лечится?
Разве что попробовать поэкспериментировать с эхо-компенсацией. Погуглите на тему echo cancellation, думаю, что поиск даст какие-либо варианты примерных конфигов. Каких-то определенных рекомендаций тут дать нельзя, случаи сугубо индивидуальные.
Добрый день. Подскажите, пожалуйста, почему не срабатывают правила трансляции при входящем звонке с анонимного номера по h.323 (dial-peer 201)? С номеров, которые содержат цифры – правила срабатывают без проблем – 9-ка добавляется.
Вот конфигурация
voice translation-rule 2
rule 13 /^(33[0-8])$/ /91/
rule 14 /^(320)$/ /91/
rule 15 /^(3[1-2][1-9])$/ /91/
voice translation-profile 9users
translate called 2
dial-peer voice 201 voip
translation-profile incoming 9users
translation-profile outgoing 4digits
destination-pattern .T
session target ipv4:149.126.169.15
codec g711alaw
fax-relay ecm disable
fax rate 9600
fax protocol none
no vad
Добрый день, Алексей!
Извините за задержку с ответом на Ваш вопрос. Не успеваю в данный момент жизни вести блог 🙁
По сути: для анонимного звонка (т.е без номера) указанное правило не отработает никак. Сами посудите – Вы же написали его для конкретных номеров. Поэтому, когда приходит анонимный вызов без номера, он просто не попадает в условия voice translation-rule 2.
Если все же необходима подстановка 9ки для анонимных номеров (хотя, я, если честно, не понимаю, для чего), то можно попробовать написать формулы так:
/.*/ /9&/
это правило означает – добавить 9ку к любому номеру.
А как быть с синхронизацией если в плату e1 cisco 5xxx включены потоки от разных операторских атсок?
В конкретный момент времени синхронизация всегда выполняется только от одного потока Е1, даже если к шлюзу их подключено несколько. Можно прописать запасные источники синхры в порядке приоритета:
Router(config)#network-clock-select 1 e1 0/0/0
Router(config)#network-clock-select 2 e1 0/0/1
Router(config)#network-clock-select 3 e1 0/1/0
Добрый день!
а не подскажете – читаю везде, что voice-port на as5350 надо рестартовать командой shut.
У меня ios 12.4 – там в командах настройки voice-port нет такой.
Какая тут хитрость?
Добрый день,
К сожалению, тут ничего не подскажу. 🙁 Обычно, если есть блок voice-port, то есть и команда shutdown. Не могу сказать, почему Вы ее не наблюдаете 🙁
Здравствуйте
Вы можете подсказать хотя бы примерную причину почему отбивает звонок
выдержка из debug ccsip messages
CISCO-5350-NZR-1#
17:28:07: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:231231@94.232.90.141:5060 SIP/2.0
Via: SIP/2.0/UDP 94.232.91.14:5060;branch=z9hG4bKC8D1DA8
From: ;tag=3BF7F7C-6C0
To: ;tag=as60fddb26
Date: Fri, 31 Jul 2015 09:29:56 GMT
Call-ID: 8A5985EE-369D11E5-8488D21F-48F3ED1A@94.232.91.14
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1438335001
CSeq: 102 BYE
Reason: Q.850;cause=16
Content-Length: 0
CISCO-5350-NZR-1#
17:28:07: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 94.232.91.14:5060;branch=z9hG4bKC8D1DA8;received=94.232.91.14
From: ;tag=3BF7F7C-6C0
To: ;tag=as60fddb26
Call-ID: 8A5985EE-369D11E5-8488D21F-48F3ED1A@94.232.91.14
CSeq: 102 BYE
Server: FPBX-2.8.1(1.8.20.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
Заранее спасибо
Здравствуйте,
Из приведенного куска дебага могу сказать, что вызов отбивает циска c причиной отбоя 16 (Reason: Q.850;cause=16). 16 означает нормальное разьединение, обычно 16 выставляется в случаях, когда один из абонентов закончил разговор и повесил трубку.
Если у вас все же какая-то нестандарная ситуация или проблема, то сказать почему она возникает по данному куску нельзя. Необходимо знать вашу топологию, какие устройства в ней участвуют, кто куда звонит, какие цифры набирает, ну и дебаг надо смотреть весь, от начала звонка и до момента отбоя. Тогда сложится правильная картина.
Добрый день
Подскажите, пожалуйста, в чем может быть проблема. Сеть устроена следующим образом
PSTN<=>Cisco<=>Asterisk звонки нормально принимаются и отправляются но нужно было настроить IVR на Asterisk и вот тут то и начинаются проблемы, когда звонишь с мобильного вызов отбивается (хотя по логу показывает что вызов установился) со стационарного звуковой файл не воспроизводится и по истечению времени со сценарием
t отправляется на соответствующий ext.
Загуглился до головокружение, надеюсь что нибудь подскажите, заранее благодарен.
Здравствуйте,
А обычные звонки (т.е не на IVR, a на телефон Астериска) работают? нет с ними проблемы? Если не воспроизводится звуковой файл, то причина, скорее всего, кроется в передаче голосового трафика RTP. NAT, файрволы, аксесс-листы в сети могут быть причиной того, что голос не проходит.
Возможно, что и сам Астериск не воспроизводит ничего. Я бы начал с того, что проверил IVR при внутреннем звонке с телефона Астериск. Если звуковой файл проигрывается, то далее стал бы копать в сторону маршрутизации голосового трафика.
Добрый день,прочитал все комментарии в этой теме ) веьсма информативно, спасибо за Ваш труд, если возможно не могли бы Вы и мне подсказать, как настроить голос между cisco 29xx, схема такая АТС-cisco-cisco-АТС (c АТС поток Е1), не понимаю как завернуть входящий звонок на поток Е1 но думаю,что для этого нужно использовать voice port, а для проброса потока-вызова по iP с cisco на cisco session target ipv4:хх.хх.ххх.хх, скажите правильно ли в целом я понимаю, если не сложно распишите алгоритм, входящего вызова на поток с cisco на поток e1 и между cisco,заранее огромное спасибо!
Добрый день, Алексей. Спасибо за Ваш отзыв. Расписывать полный алгоритм звонка – это слишком долгое занятие, если честно. 🙁 Нужно писать отдельный пост, а это требует времени. Если говорить в общих чертах, то звонок из потока Е1 приходит на voice-port. Выбирается входящий (inbound) POTS диалпир. Далее в зависимости от набранных цифр шлюз выбирает исходящий VOIP диалпир, который указывает на адрес удаленного шлюза (session target ipv4:хх.хх.ххх.хх). Вызов уходит в IP сеть. Далее удаленный шлюз принимает вызов из сети, выбирает входящий VOIP диалпир, выбирает исходящий POTS диалпир, отправляет вызов на voice port удаленного потока Е1.
Материалов в сети достаточно много на эту тему. Например, вот:
http://www.cisco.com/c/en/us/td/docs/ios/voice/monitor/configuration/guide/12_4/vt_12_4_book/vt_callflow_ov.pdf
Хорошего дня!
Здравствуйте.
Пытаюсь разобраться с синхронизацией Е1. Человек я не опытны в этом деле так что прошу помощи.
Не могу понять как правильно выстави режимы. У меня схема сложная(для меня).
На словах не смогу описать. Если есть желание помочь могу выслать схему с указанием какие режимы установлены на контроллерах.
Если проблема для Вас все еще актуальна, то напишите мне через форму связи свой Email. Сейчас я не особо часто занимаюсь блогом, так что извините за задержку с ответом и модерацией.
Добрый день, Дмитрий, вы еще на связи? Наверное вы сможете мне помочь с проблемой синхронизации на Cisco. Можно ваш е-майл, отправлю туда полное описания моей проблемы. Спасибо.
Добрый день. У нас похожая история: Схема: PSTN -> AS5350 -> UAC. После 15 минут нормального вызова (иногда быстрее), циска шлет BYE CSeq: 102 BYE
Reason: Q.850;cause=16. Причем не разрывает соединение по TDM части (EDSS1 ISDN PRI), так же не рвется RTP трафик в сторону абонента UAC (SIP), т.е. абонент на VoIP шлюзе продолжает слышать абонента на PSTN (не смотря на то что шлюз получил BYE), при этом абонент PSTN слышит "аля аварийная занятость от циски". В статистике на циске нет вызовов длинее 900 сек. Думаю что тут срабатывает какой то таймер, но какой?
Спасибо за ответ, признаться не думал что ответите.
Обычные звонки проходят без проблем. На Astere(точнее сборке ELastix) все проверил расширение файла, права, директория здесь вроде никаких проблем. Оба хоста и Aster и Cisco находятся на белых IP, на 5350 есть ACL но Aster помешен в исключения, Признаться сам грешил на RTP, но debug voip ccapi inout не очень понял.
Еще сомневаюсь в настройках синхронного интерфейса на ТФОП, он был настроен еще до меня и все работало через H323
interface Serial3/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice modem 64
isdn guard-timer 20000
isdn calling-number xxxxxx
isdn send-alerting
isdn negotiate-bchan
isdn bchan-number-order ascending
isdn sending-complete
no cdp enable
controller E1 3/0
framing NO-CRC4
pri-group timeslots 1-31
voice-port 3/0:D
cptone RU
bearer-cap Speech
Ну и еще выложу рабочий диал-пир
dial-peer voice 8205 voip
description ASTERISK
destination-pattern xx….
session protocol sipv2
session target ipv4:xx.xx.xx.xx
session transport udp
dtmf-relay rtp-nte
codec g711alaw
This comment has been removed by the author.
This comment has been removed by the author.
Здравствуйте!
А у меня следующая ситуация:
C2620XM#sh controllers E1
sh controllers E1
E1 0/0 is up.
Applique type is Channelized E1 – balanced
Description: Link E1 to Koch
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20020812, FPGA: 11
Framing is CRC4, Line Code is HDB3, Clock Source is Internal.
Data in current interval (698 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 21 15 minute intervals):
1 Line Code Violations, 202 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins,
4 Errored Secs, 1 Bursty Err Secs, 21 Severely Err Secs, 0 Unavail Secs
Что это за ошибки 21 Severely Err Secs?
Добрый день, Severely Err Secs обычно указывают на ошибки в кадрах:
For E1-CRC signals, a second with one of the following errors:
832 or more Path Code Violation errors.
One or more Out of Frame defects.
Таким образом, это количество односекундных интервалов, в которых ваш контроллер Е1 обнаружил вышеупомянутые ошибки. Для начала, я бы проверил, одинаково ли настроено линейное кодирование на обеих сторонах (может быть AMI или HDB3, с вашей стороны стоит HDB3 – видно из sh controllers), и одинаковы ли структуры кадров (c CRC4 или без CRC4, с вашей стороны CRC4 включено). Также надо проверять, нет ли ошибок в оборудовании линейного тракта (xDSL модем, релейка, оптика) между сторонами.
Вот тут можно немного почитать о проблемах с Е1:
https://www.cisco.com/c/en/us/support/docs/wan/t1-e1-t3-e3/9319-E1-error.html