» Cisco Unified Communications

Есть у нас гуру по скриптам UCCX?
На коллцентре появилась необходимость заносить телефоны в блок лист
И хотелось бы это делать через веб+база так как заносить будут сами операторы.
С помощью UCCX скрипта и его http компонентов можно это реализовать или только с помощью запросов к скулю? Если да, то дайте пример скрипта))
Если только с помощью базы, то есть ли у кого коннектор к скулю для Uccx.

avtrosty

Можно, я делал у заказчика. Сейчас постараюсь найти скрипты. На стороне сервера была обертка на PHP, которая стучалась в ораклячью базу. Ну там пофиг, можно наворотить что угодно.


Добавлено:
В общем быстро не найду, не оставил себе копий.
Я переделывал стандартный пример из доки, см скрипт getQuoteClient.aef.

Там идея в том, что конструируешь XML запрос из заранее залитого шаблона функцией CreateXMLDocument, потом через CreateURLDocument и т.п. делаешь запрос к серверу, получаешь XML в ответку, откуда опять же в соответствии с шаблоном XML вытаскиваешь нужные данные и проговариваешь клиенту.

Все это дело описано в гайде "Getting Started with Scripts".
Ебли в первый раз много, чтобы понять как оно работает.
Но работает.

avtrosty
UCCX поддерживает Oracle и еще какие-то базы, навскидку не помню. Еще я одному клиенту делал получение данных из XML (Create XML Document и Get XML Document Data). Если найду скрипт - кину ссылку в личку.

Спс большое за наводку

Дико извиняюсь за оффтопик.
vindium загляни в Личный Ящик.

Господа, может кто сталкивался - после обновления UCM 8.6 до 10.5 и UCCX 8.5 до 10.5 не могу создавать новых агентов - не хотят с RMCM пользователем ассоциироваться. При обновлении UCCX у меня криво накатился CUIC, поэтому развернул рядом второй UCCX со старыми CTI и RMCM пользователями. Создаю нового агента как положено - нифига не пускает, старые при этом прекрасно работают как на старом, так и на новом UCCX. В трейсах вижу

Код:
120643: Aug 08 16:46:18.387 MSK %MIVR-ICD_CTI-7-UNK:ClientConnMgr: Processing msg on socket:Socket[addr=10.1.9.66,port=62888,localport=12028] Msg is {length=71 type=SET_AGENT_STATE_REQ,invokeId=47,agentState=LOGIN,eventReasonCode=1,forcedFlag=False,agentID=k.bessmertniy2,agentDN=1900,agentPwd=***** }
120644: Aug 08 16:46:18.388 MSK %MIVR-ICD_CTI-7-UNK:This connection is using encrypted passwords for agent login message
120645: Aug 08 16:46:18.401 MSK %MIVR-SS_RM-7-UNK:Processing msg: CTISetAgentStateReqMsg (Rsrc:k.bessmertniy2 InvokeID:47 State:LOGIN Forced:False)
120646: Aug 08 16:46:18.401 MSK %MIVR-SS_RM-7-UNK:Agent k.bessmertniy2 is outbound capable.)
120647: Aug 08 16:46:18.401 MSK %MIVR-SS_RM-7-UNK:Rsrc: k.bessmertniy2 Contacts:
120648: Aug 08 16:46:18.401 MSK %MIVR-SS_RM-7-UNK:Rsrc: k.bessmertniy2 PrevState: UNKNOWN PrevStateSet:false
120649: Aug 08 16:46:18.401 MSK %MIVR-SS_RM-7-UNK:Rsrcs in ARL of ESD RU-MSK-DIRECT_SALES:
120650: Aug 08 16:46:18.697 MSK %MIVR-SS_RM-7-UNK:Trying to authenticate agent k.bessmertniy2
120651: Aug 08 16:46:18.880 MSK %MIVR-SS_RM-7-UNK:Processing msg: class com.cisco.wf.subsystems.rmcm.msgs.UserAuthJobResponse Rsrc:k.bessmertniy2
120652: Aug 08 16:46:18.927 MSK %MIVR-SS_RM-7-UNK:Rsrc: k.bessmertniy2 New State:LOGOFF Old State:LOGOFF Reason code:1
120653: Aug 08 16:46:18.927 MSK %MIVR-SS_RM-7-UNK: The mapping SEP902B34750ED4-k.bessmertniy2 has been added
120654: Aug 08 16:46:18.927 MSK %MIVR-SS_RM-7-UNK:Terminal SEP902B34750ED4 IPv6 Address is NULL
120655: Aug 08 16:46:18.927 MSK %MIVR-SS_RM-3-LOGIN_FAILED:Login of resource failed: Module Name=RM component,The description of a message sent from/to the RM=CTISetAgentStateReqMsg (Rsrc:k.bessmertniy2 InvokeID:47 State:LOGIN Forced:False),A specific description for a trace=problems in JTAPI or CM
120656: Aug 08 16:46:18.927 MSK %MIVR-SS_RM-7-UNK:Posting msg CONTROL_FAILURE_CONF Socket:Socket[addr=10.1.9.66,port=62888,localport=12028] invokeID:47 failureCode:CF_GENERIC_UNSPECIFIED errorCode:88001 text:Unable to login agent due to problems in JTAPI or CM in CTI Server's message queue
120657: Aug 08 16:46:18.927 MSK %MIVR-ICD_CTI-7-UNK:OutboundMsgProcessor: got message: { CONTROL_FAILURE_CONF }
120658: Aug 08 16:46:18.928 MSK %MIVR-ICD_CTI-7-UNK:OutboundMessageprocessor : sending msg : { length=-1 type=CONTROL_FAILURE_CONF,invokeId=47,failureCode=CF_GENERIC_UNSPECIFIED,errorCode=88001, text=Unable to login agent due to problems in JTAPI or CM to socket: Socket[addr=10.1.9.66,port=62888,localport=12028] }
120659: Aug 08 16:46:18.928 MSK %MIVR-ICD_CTI-7-UNK:MsgHandler : Sent : { CONTROL_FAILURE_CONF to Socket[addr=10.1.9.66,port=62888,localport=12028] }

Всем привет.

Столкнулся с такой проблемой, перевел все на CUCM 10.5 и CUP 10.5,
В Джабере если использовать для звонка компьютер, то устройство CSF норм отрабатывает, а вот если выставляют использовать Телефон, то не цепляется к нему.
При этом на Телефон права пользователя накинуты везде, и При выборе "Использовать мой телефон для вызова" Устройства видны (их два 7945 и IP Communicator), но при выборе их он к ним не цепляется,
Хотя на CUCM 8.6 все работало.
Чет я не могу найти где Desk Phone настраивается

Глобально смотришь тут - Enterprise Phone Configuration / Desktop Client Settings

И клиент джабры какая версия 9.7.х 10.5 и т.д. - ?

И на сколько помнится данная фича работает на ура с SCCP телепонами.

И данная фича включается в настройках профиля джабры клиента - Device / Phone / при этом все должно привязано между собой телепон + джабра клиент + END User. ( Automatically Start in Phone ControlRequired Field и Automatically Control Tethered Desk )

глюкало, эта жабра, млять...
через ВПН так и не заработал голос %\

xktygfhnbb
Странно, у меня все пашет через эниконнект, и голос и видео.
И не у одного клиента даже.

Рутинг не виноват?

ilyarubinchik
все ригиццо, номер набираешь, вызов проходит,а в ответ тишина - ни кто ни кого не слышит...
по вайфле - все летает , а через ВПН, в том числе и цыцкин. через асу - хрен

xktygfhnbb
Рутинг крути, а если еще и аса по дороге - вообще ахтунг, страсть их не люблю.

На асе кстати можно создать аксес лист для мониторинга и посмотреть, RTP трафик вообще идет или нет.

Да-да Джабра тут не причем ы.ы.ы.

P.S. ASA - она все - смотри ACLы, роутинг и т.д.

ilyarubinchik
млять, какой нах роутинг ??? жабра регицца, звонок проходит...


root0
индусы. Сэр

xktygfhnbb
Я конечно вашей топологии не знаю, но то что регится и звонит еще не значит что будет проходить RTP.

В общем дело ваше.

ilyarubinchik - говорит дельные вещи, по опыту скажу что джабра тут не причем, нужно крутить асу - включи дебаг посмотри как проходит пакет - в обе ли он стороны проходит и т.д.

P.S. Если джабра регится и звонок проходит но нет обратки то по факту связь только идет в одну сторону - тут 100% ASA.

Ребята, помогите пожалуйста решить проблему с отсутсвием голоса во время исходящего звонка, имеется CUCM 10.5 и роутер в режиме CUBE, изначально, когда телефоны регистрировались на CUCME проблем не было, после развертывания CUCM, проблема появилась, привожу журнал и конфиг CUBE:

[more=CUBE]
voice service voip
ip address trusted list
ipv4 77.51.247.44
address-hiding
mode border-element
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
rel1xx disable
early-offer forced
midcall-signaling passthru

voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw

voice translation-rule 1
rule 1 /^4951234567$/ /1010/

voice translation-rule 2
rule 1 /.*/ /4951234567/

voice translation-profile PSTN-IN
translate called 1

voice translation-profile PSTN-OUT
translate calling 2

application
global
service alternate default

interface Loopback10
description { SIP }
ip address 10.40.127.1 255.255.255.255

interface Loopback12
description { CME }
ip address 10.40.127.3 255.255.255.255

dial-peer voice 495 voip
description { Incoming from PSTN }
translation-profile incoming PSTN-IN
session protocol sipv2
session target sip-server
incoming called-number .
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

dial-peer voice 8495 voip
description { Outgoing to PSTN }
translation-profile outgoing PSTN-OUT
destination-pattern 8..........$
session protocol sipv2
session target sip-server
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

dial-peer voice 100 voip
description { Outbound to primary CUCM }
huntstop
preference 1
destination-pattern [1235]...$
session protocol sipv2
session target ipv4:10.40.48.100
session transport udp
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
codec g711alaw
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

dial-peer voice 101 voip
description { Outbound to secondary CUCM }
huntstop
preference 2
destination-pattern [1235]...$
session protocol sipv2
session target ipv4:10.40.48.101
voice-class sip bind control source-interface Loopback10
voice-class sip bind media source-interface Loopback10
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad

gateway
timer receive-rtp 1200

call-manager-fallback
max-conferences 8 gain -6
transfer-system full-consult
ip source-address 10.40.127.3 port 2000
max-ephones 42
max-dn 84 dual-line
time-zone 32
time-format 24
date-format dd-mm-yy
[/more]

[more=Журнал с CUBE, во время звонка во вне...]
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK1D411E51
From: "1010" <sip:4951234567@XXXXXX.14.rt.ru>;tag=311FCA40-2445
To: <sip:84957274977@XXXXXX.14.rt.ru>;tag=eBufSxFSGZgCIvwkq5ghNwVlQlltczVq
Call-ID: 21482A2A-260C11E4-A3F199A7-B967C389@1.2.3.4
Timestamp: 1408365849
CSeq: 103 BYE
Contact: <sip:84957274977@77.51.247.44:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,MESSAGE,PUBLISH,SUBSCRIBE,OPTIONS,INFO
User-Agent: Svetets CallManager 4.1.0-12-g36d3d24
Content-Length: 0


066067: Aug 18 16:44:09.471 MSD: //23930/4A02F2800000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x43C7E060
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 4951234567
Called Number : 84957274977
Source IP Address (Sig ): 1.2.3.4
Destn SIP Req Addr:Port : 77.51.247.44:5060
Destn SIP Resp Addr:Port : 77.51.247.44:5060
Destination Name : XXXXXX.14.rt.ru

066068: Aug 18 16:44:09.471 MSD: //23930/4A02F2800000/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g711alaw
Negotiated Codec Bytes : 160
Nego. Codec payload : 8 (tx), 8 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 1.2.3.4
Source IP Port (Media): 24958
Destn IP Address (Media): 77.51.247.44
Destn IP Port (Media): 11750
Orig Destn IP Address:Port (Media): [ - ]:0

066069: Aug 18 16:44:09.471 MSD: //23930/4A02F2800000/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 102
Disconnect Cause (SIP) : 200

066070: Aug 18 16:44:09.959 MSD: //23929/4A02F2800000/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:1010@10.40.48.100:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK1D401FCB
From: <sip:84957274977@10.40.40.22>;tag=311FD5CC-85E
To: "1010" <sip:1010@10.40.48.100>;tag=4447~cca3772c-1e4d-4904-86af-bb6957e73775-28140806
Date: Mon, 18 Aug 2014 12:43:46 GMT
Call-ID: 4a02f280-3f11f502-1139-6430280a@10.40.48.100
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Max-Forwards: 70
Timestamp: 1408365849
CSeq: 101 BYE
Reason: Q.850;cause=86
P-RTP-Stat: PS=0,OS=0,PR=0,OR=0,PL=0,JI=0,LA=0,DU=19
Content-Length: 0


066071: Aug 18 16:44:10.959 MSD: //23929/4A02F2800000/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:1010@10.40.48.100:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK1D401FCB
From: <sip:84957274977@10.40.40.22>;tag=311FD5CC-85E
To: "1010" <sip:1010@10.40.48.100>;tag=4447~cca3772c-1e4d-4904-86af-bb6957e73775-28140806
Date: Mon, 18 Aug 2014 12:43:46 GMT
Call-ID: 4a02f280-3f11f502-1139-6430280a@10.40.48.100
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Max-Forwards: 70
Timestamp: 1408365850
CSeq: 101 BYE
Reason: Q.850;cause=86
P-RTP-Stat: PS=0,OS=0,PR=0,OR=0,PL=0,JI=0,LA=0,DU=19
Content-Length: 0


066072: Aug 18 16:44:12.959 MSD: //23929/4A02F2800000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x43CA1DF0
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 1010
Called Number : 84957274977
Source IP Address (Sig ): 1.2.3.4
Destn SIP Req Addr:Port : 10.40.48.100:5060
Destn SIP Resp Addr:Port : 10.40.48.100:5060
Destination Name : 10.40.48.100

066073: Aug 18 16:44:12.959 MSD: //23929/4A02F2800000/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : No Codec
Negotiated Codec Bytes : 0
Nego. Codec payload : 255 (tx), 255 (rx)
Negotiated Dtmf-relay : 0
Dtmf-relay Payload : 0 (tx), 0 (rx)
Source IP Address (Media): 1.2.3.4
Source IP Port (Media): 24956
Destn IP Address (Media): -
Destn IP Port (Media): 0
Orig Destn IP Address:Port (Media): [ - ]:0

066074: Aug 18 16:44:12.959 MSD: //23929/4A02F2800000/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 86
Disconnect Cause (SIP) : 500

066075: Aug 18 16:44:43.247 MSD: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:10.40.40.22:5060 SIP/2.0
Via: SIP/2.0/UDP 10.40.48.100:5060;branch=z9hG4bK117724492df
From: <sip:10.40.48.100>;tag=1637895715
To: <sip:10.40.40.22>
Date: Mon, 18 Aug 2014 12:44:43 GMT
Call-ID: 6bfc7500-3f11f53b-113a-6430280a@10.40.48.100
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:10.40.48.100:5060>
Max-Forwards: 0
Content-Length: 0
[/more]

to ginger

Source IP Address (Media): 1.2.3.4
Это в настройках такой ip у тебя прописан? или ты при выкладывании сюда поменяла его на несуществующий?

avtrosty

Цитата:

Source IP Address (Media): 1.2.3.4  
Это в настройках такой ip у тебя прописан? или ты при выкладывании сюда поменяла его на несуществующий?

1.2.3.4 это внешний адрес на интерфейсе Gi0/1, я его скрыла в 1.2.3.4

Добрый день

Вопрос - может кто сталкивался

В CUCM 10.5 мы используем shared line межу remote device и CISCO 7970G

Настроили CBARGE на эту линию (между двумя CISCO 7970G работает)

Но если звонок снят на Remote Device невозможно инициировать CBARGE с телефона.

CBARGE должен работать если shared line с Remote device? (Ни где в инструкциях не указанно)

Спасибо

to ginger
Для начала поставь на

dial-peer voice 100 voip
voice-class sip bind control source-interface Loopback10
voice-class sip bind media source-interface Loopback10

И перезапусти диалпир
Потому что

066072: Aug 18 16:44:12.959 MSD: //23929/4A02F2800000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x43CA1DF0
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 1010
Called Number : 84957274977
Source IP Address (Sig ): 1.2.3.4
Destn SIP Req Addr:Port : 10.40.48.100:5060
Destn SIP Resp Addr:Port : 10.40.48.100:5060
Destination Name : 10.40.48.100


У тебя пытается звонок между внешним ip и внутренним, а они у тебя не видят друг друга

Так же насколько я помню
voice service voip
ip address trusted list
ipv4 77.51.247.44

не работает если эта фича не включена командой,
voice service voip
ip address trusted authenticate

если ошибаюсь не бейте меня.

Но если ты ее будешь использовать, то добавь в этот лист внутренние ip CUCM
10.40.48.100
10.40.48.101



Если после этого не заработает, то возможно надо смотреть транк на CUCM 10.5
У меня была один раз такая ошибка, насколько я помню вылечил ее транскодингом.

avtrosty
Уже пробовала играться с настройками dial-peer, не помогло, так же указала IPv4-ареса CUCM в ip address trusted list, результат тот же, вызов идет, при снятии трубки - тишина.
Но вот что интересно, если звонить из города, то проблем нет, голос есть...

В некоторых документах по описанию создания Trunk'а между CUCM <-> CUBE и CUBE <-> SIP-PSTN, сказано, что необходимо создать несколько перехватывающих dial-peer на CUBE, то бишь, один для входящих от SIP-PSTN, а другой от CUCM?

В вашем случае, как это реализовано?

Что касается транскодинга, действительно, SIP-PSTN жестко использует g711alaw, телефоны, которые завязаны на CUCM имеют по умолчанию кодек g711ulaw, но когда я создала Trunk на CUCM, то указала, что кодек используется g711alaw, со стороны CUBE так же на dial-peer повесила кодек g711alaw.

[more=Настройки транка...]
http://i66.fastpic.ru/big/2014/0819/69/3a99fda7a87624154b83bb00ec6cfa69.png
http://i68.fastpic.ru/big/2014/0819/1f/c174a924e4b526b07e3b14c136baf11f.png
http://i68.fastpic.ru/big/2014/0819/2e/9bd349bc7f06707d6aeda183e5bf702e.png
http://i68.fastpic.ru/big/2014/0819/0c/ce6688af426ef24611325ac84ab45d0c.png
[/more]

Добрый день!

Вопрос снят, решение, более явно указать маску incoming called-number для dial-peer voice 495 voip

Господа, добрый день!

Столкнулся с с следующей проблемой, прошу совета:

Тестовый стенд:
CUCM 10.5.1.10000-7
Cisco Unity Connection version: 10.5.1.10000-7
2х7911 SCCP

Настроил интеграцию по данному мануалу:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/integration/guide/cucm_sccp/cucintcucmskinny/cucintcucmskinny070.html

Голосовая почта работает, WMI работает, все ОК.
CUC "Check thelephony configuration" выдает "No problems detected".

Начал настраивать Call Handlers для реализации простейшего IVR и на этом этапе столкнулся с следующим:

1. При попытке записать или прослушать Greetings с телефона указав номер - прозвон на него проходит с задержкой ~10 секунд и после первого звонка аппарата сразу идет отбой. CUC выдает error code 5, телефон не отвечает.
В RTMT - Normal call clearing. Explanation: The call is being cleared because one of the users involved in the call has requested that the call be cleared. Как понимаю - CUC сам дает отбой.

2. Записал сообщение с компа, включил Caller input, во время приветствия при наборе номера - проигрывается "Подождите пока я переадресую... и фоновая музыка" и так же с задержкой в ~10 секунд вызов приходит на набранный номер. Связь устанавливается нормально.

Есть идеи как победить данную задержку ?
Или посоветуйте, какие трассировки снимать, что бы найти затык ?

Спасибо.

Подскажите пожалуйста, кто как разруливает следующую ситуацию на UCCX:

Есть оператор КЦ, он звонит на разные номера, но делает это в интересах нескольких клиентов. Как разнести эти звонки в разную статистику, чтобы потом можно было правильно посчитать для какого клиента сколько было сделано звонков.

whaleshark
Статистику CCX считает? В CDR можно это отразить через техпрефиксы/постфиксы.

Да, считаем по внутреннему номеру оператора, все нормально когда оператор работает по одному клиенту, но стала проблема, что есть пара клиентов с небольшим количеством вызовов, сажать для каждого по оператору невыгодно.

Ну так сделайте префиксы. В пользу одного клиента пусть набирает aaa* перед номером, в пользу другого bbb*

Я про это думал с самого начала, но хотелось узнать, возможно есть другие варианты реализации.

whaleshark
Вы пишите что агент звонит, речь идет об outbound queue? Опишите задачу подробнее.