Совместная работа : Cisco Unified Contact Center Express

Устранение проблем системы исходящих звонков на основе IVR

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает Систему исходящих звонков на основе IVR и включает типовую конфигурацию шлюза SIP, регистрационные исследования и от шлюза SIP и от Cisco Unified Contact Center Express (UCCX) механизм и ограничения Системы исходящих звонков на основе IVR.

В UCCX 8.5 был представлен новый тип исходящего номеронабирателя: Интерактивный голосовой ответ (IVR) - Базирующийся Исходящий Номеронабиратель. В отличие от более старого Предварительного просмотра Исходящий Номеронабиратель, никакой агент не используется для создания исходящего вызова. UCCX соединяется непосредственно со шлюзом Протокола SIP на предприятии клиента для вызова номера исходящих контактов. Когда шлюз обнаруживает оперативный голос или автоответчик, вызов перенаправлен к спусковому механизму UCCX, связанному с группой контроля исходящего вызова. После того, как завершенный на исходящем порту интеграции компьютерной телефонии (CTI), приложение, привязанное к спусковому механизму, выполняется как обычное.

Внесенный Райаном Лэфунтэйном, Абирамом Крамадати, и Дэйвом Бикнеллом, специалистами службы технической поддержки Cisco.

Информация о функциональной возможности

В версиях UCCX ранее, чем 8.5, только Предварительный просмотр существовал Исходящий Номеронабиратель. Этот номеронабиратель использовал контроль за вызовом третьей стороны через Интерфейс программирования приложений телефонии Java (JTAPI) / CTI, чтобы дать телефону агента команду выполнять вызов. Вызов был выполнен после того, как агент принял исходящее резервирование. Взаимодействие между клиентом и сервером для исходящего резервирования было выполнено через CTI.

Для определенных, некоторый вариантов использования (таких как таймеры и приложения IVR самообслуживания), Предварительный просмотр Исходящий Номеронабиратель не был подходящим вариантом. В то время как вызов был размещен, для звонка к количеству в DialingList агент был связан. Это означало, что агент был занят для каждого исходящего вызова, даже если количество Общей коммутируемой сети телефонии (PSTN) было недопустимо, занято или привело к автоответчику. Этот высокий уровень использования агента был главным недостатком Предварительного просмотра Исходящий Номеронабиратель для этих вариантов использования.

Основанный на IVR поток исходящего вызова

Для тех же вариантов использования (таймеры и приложения IVR самообслуживания) в Системе исходящих звонков на основе IVR, агент никогда не мог бы вовлекаться в поток вызовов. Это - поток вызовов для Системы исходящих звонков на основе IVR:

  1. Исходящий номеронабиратель IVR определяет количество контактов для вызова номера (как определено в алгоритме) и SIP использования для размещения исходящих вызовов через голосовой шлюз.
  2. Голосовой шлюз обнаруживает неоперативный контакт со своими возможностями анализа установления исходящего соединения (CPA) и передает статус неоперативного контакта к номеронабирателю. Номеронабиратель обновляет сведения о статусе контакта в базе данных конфигурации.
  3. Голосовой шлюз обнаруживает оперативный контакт со своими возможностями CPA и передает статус оперативного контакта к номеронабирателю. Номеронабиратель обновляет сведения о статусе контакта в базе данных конфигурации и также передает SIP, обращаются сообщение к шлюзу SIP, который, в свою очередь, передает вызов настроенной точке маршрута CTI на Cisco Unified Communications Manager (CUCM).
  4. CUCM передает вызов порту IVR на Cisco сервер UCCX.
  5. Подсистема IVR привязывает вызов к приложению IVR, привязанному к кампании. Механизм запускает выполнение приложения, и сеанс IVR имеет место между приложением IVR для кампании в UCCX и контактом клиента.

Основанные на IVR типы номеронабирателя

Существует два типа Систем исходящих звонков на основе IVR, прогнозирующих и прогрессивных. Так как UCCX только передает вызов порту IVR для выполнения сценария, когда оперативный голос (или конфигурируемый автоответчик) обнаружен, разумно предположить, что не каждый исходящий контакт требует порта. Для балансирования шанса, что порт CTI необходим против вероятности, что Ring No Answer (RNA), занятый и ситуации с недопустимым номером, существует, прогнозирующие и прогрессивные номеронабиратели модифицируют количество исходящих вызовов, которые сделаны за один раз против количества настроенных исходящих портов CTI.

Прогнозирующая Система исходящих звонков на основе IVR имеет эти функции:

  • Количество линий для каждого порта может быть настроено, основано на скорости вызова отказа.
  • Никакое ручное вмешательство не необходимо.
  • Цель состоит в том, чтобы набрать достаточно линий, чтобы заставить порты IVR напряженно трудиться, но не превысить скорость вызова отказа настраиваемого максимального значения.

Прогрессивная Система исходящих звонков на основе IVR имеет эти функции:

  • Можно задать фиксированный номер линий, которые всегда набираются для каждого доступного исходящего порта IVR.
  • Количество линий может быть обновлено позднее.
  • Если существует три линии для каждого порта, и специализированное количество портов для исходящего равняется трем, то девять вызовов (3x3) набраны.
  • Несостоявшийся вызов происходит, когда клиент подходит к телефону, но никакой порт не доступен для побуждения клиента.
  • Можно определить настройки по умолчанию.

Компоненты номеронабирателя с UCCX

Вся функциональность и внутренние подсистемы абстрагированы для составления этой новой Системы исходящих звонков на основе IVR. Компоненты системы в новом номеронабирателе, как таблица Механизма и DialingList, совпадают с в Предварительном просмотре Исходящим Номеронабирателем с расширениями (как больше callStatus и значения callResult) добавленный.

Информация о характеристике шлюза

Для поддержки обнаружения оперативного голоса, автоответчика и тональных посылок специальных сведений (SIT), шлюз должен поддерживать функцию CPA. Используйте Cisco Feature Navigator для определения шлюза версии Cisco IOS®, которые поддерживают номеронабирателя SIP и CPA; используйте 'Поиск Функцией' поиск 'Поддержки удобства обслуживания номеронабирателя SIP и Анализа Хода вызова'.

Как работает CPA?

В CPA существует три первичных функции:

  • Обнаружение автоответчика (AMD)
  • Факс/обнаружение модема
  • Обнаружение тона завершения автоответчика

Существуют сложные алгоритмы, внедренные для создания этих различий, но, от функциональной точки зрения:

  • Оперативный партийный ответ, как ожидают, будет коротким приветом, затем период тишины.
    Пример: "Hello" + тишина
    Пример: "Hello, местонахождение Джонсона" + тишина
  • Автоответчик, как ожидают, будет более длинным приветом, тогда никакая тишина.
    Пример: "Вы достигли местонахождения Мельника, оставьте сообщение после звукового сигнала"
  • Тон завершения автоответчика обнаруживает, как, ожидают, будет обнаружением автоответчика, затем тишина, затем завершающийся тон.
  • Факс обнаруживает, распознавание факсимильного тонального сигнала.

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

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

Это - пример включенного вычисления:

  1. UCCX передает SIP, приглашают в шлюз (T1)
  2. Шлюз передает настройку вызова ISDN поставщику услуг и на поставщика услуг сотовой связи (T2)
  3. Сотовый телефон звонит и не запускает свой таймер ответа (T3)
  4. Таймер RNA ячейки истекает и вперед к голосовой почте (T4)

Если вы предполагаете, что таймер RNA для ячейки составляет 15 секунд, фактическое количество времени, которое потребовалось бы для вызова к ячейке для передачи голосовой почте, (T1 + T2 + T3 + 15). T1 + T2 + T3 мог быть значительно выше, чем количество времени, которое это занимает для представления вызова наземной линии или другому устройству неячейки.

Таким образом, когда вы не определяете предел кольца Ответа для кампании, период времени должен быть достаточно длинным для достижения системы голосовой почты для сотовых телефонов; это было бы необходимым поведением, например, поскольку кампания намеревалась оставить сообщение.

Примечание: CPA является функциональностью шлюза; в отличие от Cisco Unified Contact Center Enterprise (UCCE), CPA не может быть включен или выключен на UCCX. В то время как CPA может быть выключен на шлюзе, Cisco не рекомендует это. Для получения дополнительной информации обратитесь к Ходу вызова Обзор Analyis.

Выбор кодов IOS-шлюза выходит за рамки этого документа. Код шлюза должен поддержать CPA и номеронабирателя SIP для использования Системы исходящих звонков на основе IVR. Cisco Feature Navigator может помочь вам находить IOS Release, которые встречают требования к характеристикам. Всегда гарантируйте, что IOS Release совместим со всеми составляющими, которые взаимодействуют с этим шлюзом.

Устранение неполадок

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

Для устранения проблем Исходящего IVR определите, ли шлюз, CUCM или UCCX виновным. Устранение проблем проще, как только вы изолируете проблему к отдельному компоненту. Полезно собрать эту информацию от компонентов системы

Для шлюза, выполненного эти команды:

  1. show tech
  2. debug ccsip messages
  3. debug voip ccapi inout
  4. debug isdn q931 (или подобная отладка для получения сигнализации стороны Tфоп)
  5. debug voip hpi все (для устранения проблем CPA)
  6. debug voip vtsp все (для устранения проблем CPA)

Для UCCX, файлов журнала анализа и конфигурации:

  1. Файлы журнала MIVR с Отладкой SS_OB и XDebug1 - XDebug3 включены
  2. Файлы журнала JTAPI (для устранения проблем ОТНЕСЕННОЙ ошибки вызова)
  3. Конфигурация шлюза SIP от AppAdmin UCCX

Для CUCM рассмотрите конфигурации:

  1. Подробный CallManager
  2. Подробный CTIManager
  3. Конфигурация магистрали SIP, которая указывает к шлюзу, используемому для Исходящего IVR

Анализ данных

Шлюз SIP должен содержать необходимую конфигурацию не только, чтобы направить запросы вызова от UCCX до PSTN, но также и обработать передачу тех вызовов к спусковому механизму UCCX, определяемому для исходящего. Эта конфигурация шлюза SIP должна иметь:

  1. Входящие одноранговые телефонные соединения для соответствия с входящими запросами SIP от UCCX.
  2. Адресуемые точки исходящего вызова (или VoIP или обычная телефонная сеть [POTS]) для маршрутизации вызовов к PSTN.
  3. Адресуемые точки исходящего вызова (VoIP) для маршрутизации перенаправленного (ОТНЕСЕННОГО) вызова к кластеру CUCM, который интегрирован с UCCX.

Сервер CUCM должен быть настроен, чтобы получить входящие запросы вызова SIP от шлюза SIP (ОТНЕСЕННЫЕ вызовы) и направить запросы соответственно к спусковому механизму UCCX и портам CTI группы управления вызовами UCCX.

Типовая конфигурация шлюза SIP

Это - пример конфигурации шлюза SIP с нотациями. Подключением PSTN в данном примере является Интерфейс первичного уровня ISDN (PRI).

Примечание: Другие типы подключения PSTN мультиплексирования с разделением по времени (TDM) поддерживаются, но не поддерживается Cisco Unified Border Element (CUBE). Посмотрите идентификаторы ошибок Cisco CSCui62525 и CSCuf44826 для получения дополнительной информации о поддержке CUBE. Множественные соединения к PSTN TDM поддерживаются для маршрутизации других классов вызовов (локальный, междугородный, международный) к другим транкам или поставщикам.

RyanIVRRouter#show run
Building configuration...

Контроллер T1, настроенный для PRI ISDN

!
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24
!

Последовательный интерфейс, настроенный для PRI ISDN

!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!

Голосовой порт для маршрутизации исходящих вызовов к PSTN

!
voice-port 0/0/0:23
!

Входящее одноранговое соединение VoIP

Этот соответствия одноранговых телефонных соединений, поступающие, вызов SIP запрашивает от UCCX. Если входящее одноранговое соединение VoIP не настроено, с одноранговым телефонным соединением по умолчанию (точка вызова 0) совпадают. Это - оптимальный метод, чтобы определить и совпасть с входящим одноранговым соединением VoIP. Эта точка вызова уведомляет шлюз кодека, протокола и двухтональный многочастотный (DTMF) реле, которое будет использоваться на входящем участке SIP от UCCX.

Это соответствия одноранговых телефонных соединений весь входящий SIP INVITEs с Сервисом распознавания дискретного числа (DNIS), который запускается с 717 и который является 10 цифрами долго. В данном примере все контакты, набранные UCCX, находятся в 717 кодах зоны и имеют номера телефона 10 цифр долго.

!
dial-peer voice 100 voip
description -- Outbound Calls From UCCX --
session protocol sipv2
incoming called-number 717.......
dtmf-relay rtp-nte
codec g711ulaw
!

Узел обычной телефонной сети

Эта точка вызова направляет вызовы к PSTN по PRI, настроенному ранее. Это - адресуемый одноранговый узел для запросов вызова, прибывающих из UCCX и исходящей адресуемой точки вызова для узла коммутации VoIP 100 выше. Эта точка вызова также служит входящим одноранговым телефонным соединением для вызовов, прибывающих из PSTN для целей тестирования. В исходящем потоке вызовов номеронабирателя UCCX с этой точкой вызова не совпадают как входящее одноранговое телефонное соединение.

!
dial-peer voice 10 pots
description -- POTS Dial Peer To/From PSTN Simulator --
destination-pattern 717.......
incoming called-number .
direct-inward-dial
port 0/0/0:23
forward-digits all
!

Внешний одноранговый узел набор IP - телефонии

Эта точка вызова служит исходящей адресуемой точкой вызова, необходимой шлюзу SIP для маршрутизации вызовов к кластеру CUCM, предназначенному для спускового механизма UCCX. Эта точка вызова используется шлюзом для маршрутизации ОБРАЩЕНИЯ передаваемого UCCX, когда обнаружен оперативный голос (или автоответчик, если конфигурация существует). Эта точка вызова определяет протокол, Передачу сигналов DTMF в сообщениях протоколов VoIP, кодек и IP-адрес узла CUCM, где шлюз SIP должен направить перенаправленный вызов. В целях резервирования и распределения нагрузки, могли бы существовать несколька одноранговых узлов этого типа. Они могли быть разделены к запросам маршрутизатора ко множественным узлам CUCM в кластере или обеспечены для маршрутизации перенаправлений для определенных, некоторый спусковых механизмов к другим узлам CUCM.

В данном примере спусковые механизмы UCCX для Основанных на IVR Исходящих Кампаний являются 2001 и 2002.

!
dial-peer voice 102 voip
description -- Redirect Calls to UCCX 90 --
destination-pattern 200[1-2]
session protocol sipv2
session target ipv4:14.10.166.15
incoming called-number 200[1-2]
dtmf-relay rtp-nte
codec g711ulaw
!

Произведите выборку основанного на IVR анализа следа исходящего вызова

Это - подробный анализ журнала обмена сообщениями в качестве примера между шлюзом SIP, UCCX и PSTN.

Начальный INVITE от UCCX дает шлюзу команду звонить к количеству PSTN. INVITE содержит CallId, который может использоваться для отслеживания всех сообщений, привязанных к этому вызову и Протоколу описания сеанса (SDP) (параметры сред).

Что еще более важно INVITE включает параметры, которые шлюз должен использовать для завершения CPA. Эти параметры настроены в Страницах AppAdmin UCCX, но не используются UCCX. Скорее они передаются в INVITE шлюзу и используются шлюзом для настройки цифровых процессоров сигналов (DSP) для CPA для этого вызова. В результате эти параметры передаются шлюзу на для каждого вызова основание и могут быть изменены в любое время от AppAdmin.

UCCX передает эти атрибуты конфигурации CPA к шлюзу для каждого вызова:

Имя параметра Значение параметра Предполагаемое значение
Минимальный период тишины (100 - 1000) * Миллисекунды 375
Аналитический период (1000 - 10000) * Миллисекунды 2500
Анализ максимального времени (1000 - 10000) * Миллисекунды 3000
Минимальное время допустимого лицензионного кода речи (50 - 500) * Миллисекунды 112
Тональный анализ максимального срока (1000 - 60000) * Миллисекунды 15000

Настраиваемые значения представлены в AppAdmin на странице конфигурации шлюза SIP.

Received: 
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary

--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--

Поскольку вызов обрабатывает через точки вызова шлюза, UCCX передается '100 Попыток' сообщение.

Sent: 
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Когда исходящий вызов совпадает с исходящей адресуемой точкой вызова, он передается PSTN с помощью настроенного протокола TDM. В этом случае PRI используется:

Aug  3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x008D 
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2180, '9195551212'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '7175551212'
Plan:ISDN, Type:National

Ходами вызова и сигнализацией обмениваются между PSTN и шлюзом. Шлюз уведомлен, что телефон PSTN оглашается сообщением ПРЕДУПРЕЖДЕНИЯ.

Aug  3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x808D 
Channel ID i = 0xA98397
Exclusive, Channel 23

Aug 3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808D
   Progress Ind i = 0x8188 - In-band info or appropriate now available

Шлюз передает 183 Выполнения Сеанса обратно UCCX, чтобы уведомить UCCX, что звонит телефон PSTN. Это включает SDP для согласования среды тонов фонового сигнала вызова.

Sent: 
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

Вызов связан на участке TDM, поскольку телефон PSTN ответил на вызов. Шлюз передает подтверждение в CONNECT_ACK.

Aug  3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x808D

Aug 3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008D

Шлюз уведомляет UCCX, что вызов связан с 200 ОК. ACK UCCX это, как требуется RFC SIP. 200 ОК также содержат SDP для согласования среды, но это не используется UCCX.

Sent: 
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Received:
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...

Шлюз обнаруживает ход вызова с CPA и уведомляет UCCX хода вызова через серию Обновленных сообщений. ACK UCCS это, как требуется RFC SIP.

В данном примере обновления SIP 'Обнаружено' событие, и статусом является 'CpaS'.

  • CpaS указывает, что начался CPA.
  • Когда автоответчик обнаружен, статусом является 'Asm'.
  • Когда тон автоответчика квалифицирован, статусом является 'AsmT'.

Эта таблица приводит x-cisco-cpa коды статуса, используемые в обновленных сообщениях SIP:

Name Определение

FT

Факс/Тон модема.

Asm

Машина ответа.

AsmT

Машина ответа оконечный тон.

LS

Оперативная речь.

SitIC

НАХОДИТЕСЬ тональный IC - Точка пересечения - Свободный номер или AIS или так дальше.

SitNC

НАХОДИТЕСЬ тональный NC - Никакой Канал, Аварийная ситуация или Блокирование Транка

SitVC

НАХОДИТЕСЬ тональный VC - Свободный Код

SitRO

НАХОДИТЕСЬ тональный RO - Объявление Повторного заказа

SitMT

Misc НАХОДЯТСЯ тон

CpaS

Запустите CPA

LV

Низкий объем или вызов тишины в эфире

Sent: 
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26

event=detected
status=CpaS

Received:
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...

UCCX передает уведомление шлюзу для перенаправления вызова к спусковому механизму, назначенному на эту исходящую кампанию. ACK шлюза это.

Received: 
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...

Sent:
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...

Шлюз должен направить этот вызов новому назначению как любая нормальная обработка вызова через точки вызова на шлюзе.

Aug  3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=FALSE, Mode=0,
Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)

Вызов направлен шлюзом, основанным на конфигурации в исходящей адресуемой точке вызова, с которой совпадают для назначения, содержавшего в ОБРАЩЕНИИ.

Sent: 
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Типовой анализ журнала MIVR

Эти фрагменты от журнала MIVR предоставляют обзор вызова с точки зрения UCCX. Позвольте этим уровням отладки перехватить корректную информацию:

  • SS_OB - Отладка, XD1, XD2, XD3
  • SS_RM - отладка, XDebug1
  • CFG_MGR - Отладка, XDebug1 (если проблема с вызовом номера записей списка),
135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, ,
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239

135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2

Примечание: С тех пор могли бы быть множественные кампании в то же время, важно обратить внимание на campaignID и recordID.

B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0

135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber:
callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9
longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset:
DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212

//Based on the Campaign config, the phone number is modified accordingly. In a failed call
scenario, you might want to verify what the number is after the formatting is done. Look
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.
135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor: 
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212
.

Вот отформатированные и бесформатные phoneNumbers:

135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() - 
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )

Сигнализация SIP запускается:

SIP-9919785551212 INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0

SIP-9919785551212 SIP/2.0 100 Trying

SIP-9919785551212 SIP/2.0 183 Session Progress

SIP-9919785551212 SIP/2.0 200 OK

Проверьте обработку этих сообщений на шлюзе с обменом сообщениями шлюза, объясненным ранее.

135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68, 
State=CONTACTING, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5 sending

SIP-9919785551212 ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0

135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed

135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway

135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=OK135534725: Aug 20 21:34:58.810 EDT
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER,
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR
Dialer processes

135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData&colon;
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

Шлюз передает Обновленное сообщение SIP вместе с сообщением CPA. Программное обеспечение CPA работает на шлюзе и анализирует Протокол RTP от вызываемой стороны. Это помогает дифференцироваться между голосом и автоответчиком в конце вызываемой стороны. Можно определить Обновленное сообщение SIP CPA его Типом содержимого 'application/x-cisco-cpa'.

SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 102 UPDATE
SIP-9919785551212 Content-Length: 26
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512899
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212 
SIP-9919785551212 event=detected
SIP-9919785551212 status=CpaS
SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 103 UPDATE
SIP-9919785551212 Content-Length: 163
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512902
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212 
SIP-9919785551212 event=detected
SIP-9919785551212 status=LV
SIP-9919785551212 pickupT=320
SIP-9919785551212 maxActGlitchT=0
SIP-9919785551212 numActGlitch=0
SIP-9919785551212 valSpeechT=20
SIP-9919785551212 maxPSSGlitchT=0
SIP-9919785551212 numPSSGlitch=0
SIP-9919785551212 silenceP=0
SIP-9919785551212 termToneDetT=0
SIP-9919785551212 noiseTH=1000
SIP-9919785551212 actTh=32000
//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low 
Volume as Voice,' this call is handled accordingly
135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus
post OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239,
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239

Типичные неполадки

Никакой CPA не передается от шлюза до UCCX

После того, как вызов связан с Вызывающим абонент PSTN, никакие сообщения не передает обратно UCCX шлюз, чтобы указать, что CPA был завершен и что вызов закончился (оперативный голос, занятый, автоответчик, и т.д). Удостоверьтесь версия IOS на CPA поддержек шлюза. Исследуйте шлюз, чтобы проверить, что CPA работает должным образом.

Вызов Не Перенаправлен к UCCX После Оперативного Обнаруженного Голоса

Проверьте, что шлюз имеет точку вызова, которая совпадает с набранным номером (DN) спускового механизма UCCX, назначенным на кампанию. Проверьте, что вызов от шлюза может направить к той точке маршрута CTI / спусковой механизм в CUCM.

Повторные попытки Не Набраны

Подобный обратным вызовам в Предварительном просмотре Исходящий Номеронабиратель, если вызовы, которые получают RNA или занятый, не повторены, проверяет, что эти записи правильно отмечены как Повторная попытка в таблице DialingList. Проверьте от журналов MIVR, что попытка вызова делается при указанном обратном вызове, или повторите время.

DTMF не работает, когда связано со сценарием IVR

Проверьте, что о DTMF выполняют согласование должным образом между CUCM и шлюзом и что с именованными точками вызова совпадают (точка вызова 0 не содержит конфигурацию Передачи сигналов DTMF в сообщениях протоколов VoIP). UCCX только поддерживает внеполосный DTMF через JTAPI, таким образом, некоторые типы шлюза и диаграммы вызовов могли бы потребовать, чтобы Media Termination Point (MTP) был вызван для завершения взаимодействия DTMF. Исследуйте шлюз для подтверждения шлюза, и CUCM должным образом обрабатывают запросы DTMF и согласование.

Дополнительные сведения


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.