отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

проблема отправки факсов CUCM 9.1 + региональные шлюзы

Добрый день!

имеется разветвленная структура с CUCM 9.1 и несколькими шлюзами 29-ой серии. Гдето заведены Е1 разных провайдеров, на другие SIP других провайдеров. С какогото момента времени начались проблемой с исходящими факсами. Причём проблема отмечается для каждого из шлюзов кроме одного с Е1. Проблем с входящими факсами нет нигде.

Факс-устройства подключены через ATA-187(190). Прошивки везде одинаковые, последние.

Шлюзы, подключение, наличие проблемы:

первый 2921 - E1 - нет проблем!!

второй 2921 - Е1 - есть

третий 2911 - SIP - есть

четвертый 2951 - SIP и E1 - есть

пятый 2951 - SIP - есть

конфигурация на шлюзах аналогичная вплоть до description))

debug voip ccapi inout на шлюзах мне практически ничего не дал. сессия VoIP устанавливается нормально, но дальше иногда сразу иногда попозже вызов просто завершается с подобными нормальными кодами: 

(Previous Disconnect Cause=0, Disconnect Cause=16)

Call Disconnect Event Sent

в логах ATA при нормальной отправке вижу и выделяю для себя:

<sip:984992628493@192.168.13.14>call_id(1): call state=CONNECTING
...

Cisco Systems, Inc.

<sip:984992628493@192.168.13.14><sip:4212@192.168.13.14><sip:984992628493@192.168.13.14>12:21:30:948   [sip]  23:16:56.948         pjcu.c  [pjcu_on_call_state():1355] PJCU_TASK_ID(0) call_id(1): call state=CONFIRMED
12:21:30:949   [sip]  23:16:56.949  dlg0x100cd4ac  Module mod-pjsua-kpml already registered as dialog usage, updating the data (nil)
12:21:30:952   [sip]  23:16:56.951 pjcu_pjsip_api  [pcu_rptCallMediaExch][2056] eid(0) cid(1005): RTP stream ! 

12:21:30:953   [sip]  23:16:56.953 pjcu_pjsip_api  [pcu_rptCallMediaExch][2171] eid(0) cid(1005): Find the telephone event: 0 !

12:21:30:955   [sip]  23:16:56.954 pjcu_pjsip_api  [pcu_rptCallMediaExch():2275]: eid(0) cid(1005): Report call media exchange.
...

Cisco Systems, Inc.

<sip:984992628493@192.168.13.14><sip:4212@192.168.13.14><sip:984992628493@192.168.13.14>12:21:30:956 x [pcu] [pcu_MsgDispatch():1025] eid(0) cid(1005): Rx evid(15) from PJCU.
...
... 12:21:30:957 i [ipps] ----- PCU: CC_MED_EX, pid=0, eid=0, cid=1005 ----- 12:21:30:957 i [ipps] MPCU update processing port (0) 12:21:30:958 % [ipps] sipcsm, ev=CNPR_MEDIA_EX, state(CNST_CONNECTED), eid=0, cid=1005) 12:21:30:958 f [XCCU] Ambiguous mode 12:21:30:959 % [ipps] mlcu, cid=1005, cnst(CNST_CONNECTED->CNST_CONNECTED), sub(CNSST_WAIT_MEDIA_EX->CNSST_NONE) 12:21:30:962 x [ipps] [connStatePoll][698]cid=1005, cnData->isPickupCall=0 12:21:30:964 o [ipps] MPCU restore processing port (0) 12:21:30:965 x [ipps] Post event to ipps OK 12:21:37:031 x [ipps] Post event to ipps OK 12:21:37:031 w [XCCU] xccu_proc_fax_event(0), Process 2100-Net, [Voice->Voice], Flag:Calling Ans 12:21:37:031 i [ipps] ----- MCU: MC_FAX_DET for port:0, line:0 ----- 12:21:37:032 i [ipps] MPCU update processing port (0) 12:21:37:032 % [ipps] sipesm, ev=EPMEDIA_FAX_DETECT, state(LNST_TALKING), eid=0, cid=1005) 12:21:37:032 % [ipps] sipcsm, ev=CNMEDIA_FAX_DETECT, state(CNST_CONNECTED), eid=0, cid=1005) 12:21:37:032 w [ipps] fax:Xmt detected 12:21:37:033 o [ipps] MPCU restore processing port (0) 12:21:40:033 [sip] 23:17:06.033 pjsua_call.c Call 1: received updated media offer 12:21:40:035 [sip] 23:17:06.034 pjcu.c [pjcu_decide_media_type():1317] PJCU_TASK_ID(0): T38 image comming 12:21:40:039 [sip] 23:17:06.039 pjsua_call.c Media updates, stream #0: (inactive) 12:21:40:043 [sip] 23:17:06.042 pjcu.c PJCU_TASK_ID(0) Media for call_id(1) is inactive 12:21:40:044 [sip] 23:17:06.043 pjcu.c [pjcu_decide_media_type():1317] PJCU_TASK_ID(0): T38 image comming 12:21:40:045 [sip] 23:17:06.045 pjcu_pjsip_api [pcu_rptFaxMediaExch():1907]: eid(0) cid(1005): Report fax media exchange.

а в логах ATA при сбойной отправке вижу и выделяю:

Cisco Systems, Inc.

PJCU_TASK_ID(0) call_id(2): call state=CONFIRMED
11:56:10:511   [sip]  22:31:41.511  dlg0x1003fc94  Module mod-pjsua-kpml already registered as dialog usage, updating the data (nil)
11:56:10:512   [sip]  22:31:41.512 pjcu_pjsip_api  [pcu_rptCallMediaExch][2056] eid(0) cid(67): RTP stream ! 

11:56:10:514   [sip]  22:31:41.514 pjcu_pjsip_api  [pcu_rptCallMediaExch][2171] eid(0) cid(67): Find the telephone event: 0 !

11:56:10:515   [sip]  22:31:41.515 pjcu_pjsip_api  [pcu_rptCallMediaExch():2275]: eid(0) cid(67): Report call media exchange.
...
...
... 11:56:18:015 i [ipps] ----- PCU: CC_MED_EX, pid=0, eid=0, cid=67 ----- 11:56:18:016 i [ipps] MPCU update processing port (0) 11:56:18:016 % [ipps] sipcsm, ev=CNPR_MEDIA_EX, state(CNST_CONNECTED), eid=0, cid=67) 11:56:18:016 f [XCCU] Ambiguous mode 11:56:18:026 w [XCCU] xccup_enable_voice(0), T38 configurations => ptime =10, lptime=40, vif=(72,72), noDel=200, miDel=10, maDel=400, adPout=0 rate=72, hsRate=40, lsRed=5, hsRed=0, tcdM=2, ver=0 dbg=0, mLsDpkt=1, txNetTout=150, efTmrS=2600, efTmrE=2300, clrTmr=0 selLup=1, selEflag=0, selTfop=0, selNsfOvd=0, t30Ecm=1, t30MrComp=0 11:56:18:028 o [ipps] MPCU restore processing port (0) 11:56:18:029 x [ipps] Post event to ipps OK 11:56:18:082 w [XCCU] xccu_proc_fax_event(0), Process OA-T38, [Voice->FaxRelay], Flag:Calling Ans 11:56:18:082 w [XCCU] xccu_proc_fax_event(0), Ignore MediaOn, [FaxRelay->FaxRelay], Flag:Calling Ans 11:56:18:082 f [XCCU] xccup_set_dtmf_detection(), Ignore command in Fax/Modem mode 11:56:18:097 [sip] 22:31:49.096 pjcu.c [pjcu_on_call_state():1355] PJCU_TASK_ID(0) call_id(2): call state=DISCONNCTD 11:56:18:098 [sip] 22:31:49.098 pjcu_pjsip_api [pcu_rptCallBye():2374]: eid(0) cid(67): Report call release. 11:56:18:099 x [pcu] [pcu_MsgDispatch():1025] eid(0) cid(67): Rx evid(5) from PJCU.

т.е. передача не успев начаться обрывается, без следов. 

главный вопрос тут для меня чем отличается работающее нормально одно из направлений шлюз 2921 + E1. если я маршрутизирую через него то всё хорошо. Помогите разобраться, коллеги

  • Видео голосовая связь системы унифицированных коммуникаций и контакт центры (Video Voice UC and Contact Center)
Теги (1)
1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

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

SIP и H323 в синхронизации не

SIP и H323 в синхронизации не участвуют. Это вопрос только Е1. Если потоков несколько, то задайте приоритет у них:

network-clock-participate wic 0

network-clock-select 1 E1 0/0/0

network-clock-select 2 E1 0/0/1

Ну и clear controller e1 0/0/0

Надо бы уточнить у провайдера, он точно синхронизацию в линию отдает? У меня был случай, когда провайдер на словах говорил "да, да, отдаю", но когда прижали фактами вдруг начал "ой, извините, что-то пропустили в настройках..."

11 ОТВЕТ.
New Member

Различия могут быть в том,

Различия могут быть в том, что провайдеры (точнее, настройки их оборудования) разные у разных шлюзов.

По Е1, для начала посмотреть show controller e1. Проверить, что slip seconds отсутствуют. Возможно, есть проблемы синхронизации потоков с провайдеров.

По SIP - смотреть настройки кодеков в сторону провайдера и fax-relay.

New Member

Сергей, 

Сергей, 

для E1 я проверял этот вариант у одного из провайдеров действительно есть такой момент, но у другого всё чисто. На выходе получается что у двух из трёх шлюзов с Е1 нет проблем с синхронизацией и ошибками slip. Через один из них факсы уходят, через другой нет)

По SIP'у я конечно проверяю сейчас заново, но там устойчивая конфигурация более 2-х лет, причём не на одном шлюзе.

на диалпире в сторону провайдера:

codec g711ulaw

fax rate voice

dtmf-relay rtp-nte

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw

no vad

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

New Member

А провайдер точно ожидает

А провайдер точно ожидает вызов в ulaw? В России принят кодек alaw в качестве стандартного.

New Member

Да, провайдер ожидает именно

Да, провайдер ожидает именно ulaw. Мы договаривались об этом в момент подключения:)

Проблему на SIP-потоках вроде решили. Проблема оказалась в префиксе набора номера (который просит добавлять провайдер). точнее не в самом номере, а в символе # которым заканчивается номер префикса. В IOS'ах начиная примерно с 15.2.5 этот символ подставляется некорректно (на предыдущих версиях работало и с решёткой). Причём при обычном voice вызове всё хорошо, а если идёт INVITE для(от) факса, то беда. Увидели Wireshark'oм снимая трейс прямо со шлюза для исходящего вызова факса, который подключен через ATA187.

Убрали вместе с провайдером в префиксе #. Помогло.

Теперь нужно понять почему не уходят факсы на шлюзах с Е1. Там где есть slip seconds - пытаемся с провайдером решить проблему синхронизации. пока не удаётся...

New Member

Обычно хватает

Обычно хватает

network-clock-participate wic 0

network-clock-select 1 E1 0/0/0

Опять же принято, что синхронизацию в линию выдает провайдер. Наличие слипов однозначно говорит о проблемах именно в синхронизации. 

New Member

Мы проверили это сразу. Но не

Мы проверили это сразу. Но не помогает. 

это выглядит как будто появляется ещё один источник синхронизации, он становится главным и обратно. 

сначала делаешь:

MSK-VGW1#sh network
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 GOOD E1
10 Backplane GOOD PLL

Current Primary Clock Source
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 GOOD E1

потом в течение минуты делаешь снова и получаешь:

MSK-VGW1#sh network
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 HOLDOVER E1
10 Backplane GOOD PLL

Current Primary Clock Source
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 HOLDOVER E1

потом ещё:

MSK-VGW1#sh network
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 GOOD E1
10 Backplane GOOD PLL

Current Primary Clock Source
---------------------------
Priority Clock Source Clock State Clock Type

10 Backplane GOOD PLL

потом:

MSK-VGW1#sh network
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 HOLDOVER E1
10 Backplane GOOD PLL

Current Primary Clock Source
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 HOLDOVER E1

ну и обратно:

MSK-VGW1#sh network
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 GOOD E1
10 Backplane GOOD PLL

Current Primary Clock Source
---------------------------
Priority Clock Source Clock State Clock Type

1 E1 0/1/0 GOOD E1

я думаю что это както связано с тем что шлюз собирает на себе 3 потока от разных провайдеров:

SIP

H323

E1

сами по себе они работают нормально, есть пара нюансов но в целом всё работает. а вот с синхронизацией потока Е1 беда

New Member

SIP и H323 в синхронизации не

SIP и H323 в синхронизации не участвуют. Это вопрос только Е1. Если потоков несколько, то задайте приоритет у них:

network-clock-participate wic 0

network-clock-select 1 E1 0/0/0

network-clock-select 2 E1 0/0/1

Ну и clear controller e1 0/0/0

Надо бы уточнить у провайдера, он точно синхронизацию в линию отдает? У меня был случай, когда провайдер на словах говорил "да, да, отдаю", но когда прижали фактами вдруг начал "ой, извините, что-то пропустили в настройках..."

New Member

Е1 здесь один.

Е1 здесь один.

говорит что с его стороны всё нормально, только железка слабовата(старенькая), dsp маловато, из-за этого мы неполным потоком пользуемся))

я ему показал что у меня:

card type e1 0 1

network-clock-participate wic 1

network-clock-select 5 E1 0/1/0

isdn switch-type primary-net5

 

controller E1 0/1/0

pri-group timeslots 1-19    

framing CRC4
clock source line
pri-group timeslots 1-19 speed 64

interface Serial0/1/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-net5

isdn incoming-voice voice

no cdp enable

а он мне показал что у него:

tdm clock E1 0/0 both export line

voice-card 0

isdn switch-type primary-net5

 

controller E1 0/0

pri-group timeslots 1-31

 

interface Serial0/0:15

no ip address

encapsulation hdlc

no logging event link-status

isdn switch-type primary-net5

 isdn protocol-emulate network

isdn incoming-voice voice

isdn send-alerting

New Member

Мне кажется, провайдеру надо

Мне кажется, провайдеру надо сделать

tdm clock E1 0/0 both import internal

http://www.cisco.com/cisco/web/support/RU/10/107/107701_clocking.pdf

102
Просмотры
0
Полезный материал
11
Ответы