отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
1305
Просмотры
10
Полезный материал
8
Ответы
RDE000000
Beginner

Петля при входящем вызове через sip gw (isdn qsig E1)

Добрый день!

 

Имеется проблема с входящей связью. Схема: Call Manager (SIP) <-> (SIP) ISR 2911 (E1)<-> (E1)Siemens HiPath 4000. При входящем звонке занимаются все канальные интервалы:

show voice call summary
PORT CODEC VAD VTSP STATE VPM STATE
============== ========= === ==================== ======================
0/0/0:15.1 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.2 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.3 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.4 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.5 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.6 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.7 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.8 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.9 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.10 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.11 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.12 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.13 g711ulaw n S_ALERTING S_TSP_INCALL
0/0/0:15.14 g711ulaw n S_SETUP_REQ_PROC S_TSP_OUTCALL_ALERT
0/0/0:15.15 g711ulaw n S_ALERTING S_TSP_INCALL

 

 

В итоге, соединение происходит на последнем канале. 

В дебаге q921 следующие ошибки:

**ERROR**: isdn_init_fac_data: No Opval 0

**ERROR**: isdn_init_fac_data: No Invoke 0

Дебаг q931 во вложении. Администраторы HiPath говорят, что от 2911 прилетает повторный Setup. Помогите разобраться. При исходящей связи все нормально - занимается один канальный интервал.

 

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

В нашем случае Called number - 37881

 

Destination pattern [1-69]....$ на пире 6 имеет более точный паттерн чем .T на 12м, поэтому звонок уходит туда.

 

Вы можете сделать отдельный диал-пир для номера 37881 в сторону CUCM, звонок должен уйти туда.

Просмотреть решение в исходном сообщении

8 ОТВЕТ 8
Valeriy Kuznetsov
Cisco Employee

Добрый день,

Дебага q931 недостаточно, чтобы определить почему звонок уходит обратно в PBX. Нужно смотреть какие диалпиры использовались для call routing decision.

 

Можете повторить тест и собрать следующие дебаги:

debug isdn q931

debug voip ccapi inout

debug ccsip messages

 

 

Большое спасибо за ответ, собрал запрошенный необходимый дебаг. Только ccsip messages получился одозрительно неинформативным

 

Дебаги voip ccapi inout и 931 тоже странные, там нет некоторых промежуточных строчек.

 

Можете собрать заново?

Предлагаю использовать следующую процедуру для сбора логов из буффера роутера:
https://community.cisco.com/t5/collaboration-voice-and-video/how-to-properly-and-safely-collect-debugs-on-an-ios-router/ta-p/3114693

 

Нам нужны все три дебага в одном файле. Сделайте clear logg перед включением дебагов.

Сделал все в соответствии с рекомендациями, дебаг во вложении. Заранее большое спасибо за ваше потраченное время!

Входящий звонок матчится диал-пиром #3.

Исходящий выходит через #6 и уходит обратно в ISDN транк, затем PBX видимо маршрутизирует назад и так по кругу.

Проверьте настройки диал-пира #6.

 

///

 

Calling Number=89313266743,(Calling Name=)(TON=International, NPI=ISDN, Screening=Network, Presentation=Allowed),
Called Number=37881(TON=Unknown, NPI=ISDN),
Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
Incoming Dial-peer=3, Progress Indication=NULL(0), Calling IE Present=TRUE,

 

 

Destination Pattern=[1-69]....$, Called Number=37881, Digit Strip=TRUE

Calling Number=89313266743(TON=International, NPI=ISDN, Screening=Network, Presentation=Allowed),
Called Number=37881(TON=Unknown, NPI=ISDN),

Guid=AF00CEF9-9EE2-11E8-80D1-3C08F65CCD10, Outgoing Dial-peer=6

Диал пир №3:

dial-peer voice 3 pots

translation-profile outgoing 3

destination-pattern 08..........$

progress _ind alert enable 8

port 0/0/0:15

forward-digits all

 

Диал пир №6:

dial-peer voice 6 pots

destination-pattern [1-69]....$

progress _ind alert enable 8

port 0/0/0:15

forward-digits all

 

 

Решительно не понимаю, почему после диал пира №3 матчится №6, который указывает на voice порт 0/0/0:15. Должен же быть тот, который смотрит в сторону CUCM, разве нет? Например вот этот:

 

dial-peer voice 12 voip

preference 1

destination-pattern .T

session protocol sipv2

session target ipv4:*.*.*.*

session transport tcp

voice-class codec 1

voice-class sip options-keepalive up-interval 12 down-interval 65 retry 2

dtmf-relay rtp-nte

no vad

 

 

 

В нашем случае Called number - 37881

 

Destination pattern [1-69]....$ на пире 6 имеет более точный паттерн чем .T на 12м, поэтому звонок уходит туда.

 

Вы можете сделать отдельный диал-пир для номера 37881 в сторону CUCM, звонок должен уйти туда.

Просмотреть решение в исходном сообщении