- Начало
- /
- Статия
Отстраняване на неизправности при повиквания на Webex Calling в Control Hub
Изгледът за отстраняване на неизправности в Webex Calling позволява на администраторите да отстраняват проблеми с връзката и качеството, свързани с мултимедията, за разговори в Webex Calling. Можете да търсите информация, свързана с обаждането, да видите дали е било успешно, отказано или неуспешно, да видите медийната му статистика, да определите къде е възникнал проблемът и да го разрешите.
Общ преглед
Отстраняването на неизправности за Webex Calling ви позволява да отстранявате проблеми, свързани с качеството на медиите и свързаността на повикванията, за конкретни повиквания чрез Webex Calling. Може да искате да отстраните неизправности при обаждания по различни причини, като например оплаквания от клиенти за това, че имат лошо качество на обажданията. В този случай можете да отидете директно в изгледа за отстраняване на неизправности, да потърсите тези конкретни повиквания и след това да видите подробностите за прехода, за да определите къде може да е проблемът. Можете също така да използвате функцията за отстраняване на неизправности, за да наблюдавате проактивно качеството на обажданията за организацията и да изпреварвате конкретни проблеми, преди потребителите да ги забележат.
За да получите достъп до изгледа за отстраняване на неизправности, трябва да имате пълна роля на администратор, администратор само за четене или администратор за поддръжка в Control Hub.
Отстраняването на неизправности в Webex Calling ви позволява да:
-
Търсене на успешни, неуспешни и отказани повиквания.
-
Преглед на изживяването от край до край на участниците в разговора.
-
Преглед на хоп детайл от обаждането.
-
Преглед, ако медиите престъпват през облака Webex Calling, или директно между потребителите (с помощта на Заведение за интерактивна свързаност (ICE)).
-
Преглед на анализи, ако няма медиен файл в обаждането или когато настройката за оптимизация на пътя е била неуспешна.
-
Преглед на обажданията за последните 21 дни.
-
Преглед на неуспешни и отхвърлени повиквания, свързани със сигнализацията.
-
Анализирайте показателите за качество на обажданията, които са подействали върху опита на потребителя. Например, администратор може да наблюдава високо трептене при клиенти през Wi-Fi мрежи, но загубата на пакети и латентността може да са приемливи.
-
Открийте дали проблемът е с повикващия или callee.
Обажданията, използващи Webex Calling , се появяват след края на разговора.
Изгледът за отстраняване на неизправности помага да се идентифицира проблемната област, като предоставя всички съответни показатели и не е задължително да ви даде основната причина за лошо обаждане. Погледнете тези указатели, за да идентифицирате различни фактори и да определите опциите за разделителна способност:
-
Опитът от край до край на потребителя.
-
Изгледът Хоп Детайли.
-
Изпращане или получаване на показатели от потребителя или медийната релейна точка.
-
Независимо дали обаждането е възникнало до или от външна мрежа, или между регистрираните крайни точки на Webex Calling .
Изглед за търсене
Можете да търсите, използвайки следните критерии, за да получите списък с повиквания, при които е използвана медийна сесия с поне една крайна точка, регистрирана в Webex Calling:
-
Имейл адреси
-
Телефонни номера
-
MAC адреси
-
ИД на разговори
-
Идентификатори на корелация
Поддържа се частично търсене за имейл адреси, телефонни номера и идентификатори на повиквания. За телефонни номера можете да въведете първите три до осем цифри и след това да натиснете Enter, за да видите съответстващите записи. Ако въведете повече от осем цифри, търсенето ще се опита да намери точно съвпадение. Обърнете внимание, че ако копирате и поставите телефонен номер от друго място, трябва да включите +1 за да работи търсенето.

Когато търсите имейл адреса на потребител, неговите срещи и обаждания са разделени в съответните им раздели:
-
Срещи – Съдържа всички срещи, в които потребителят е участвал.
-
Webex Calling – Съдържа всички повиквания от Webex Calling.
-
Обаждане в Webex – Съдържа обаждания от „Обаждане в Webex“.
Когато търсите по идентификатор на корелация или телефонен номер, се показва само съответният раздел (в този случай „Webex обаждания“), показващ само съответните резултати.
Когато търсите обаждане, съответните сегменти от обаждането се показват в раздела Webex Calling. Налични са следните данни:
Име на колоната | Определение |
---|---|
Статус |
Дали опитът за обаждане е бил успешен или не. Когато опитът за повикване е със статус Отказ или Неуспех, можете да задържите курсора на мишката върху статуса, за да видите съответния код. Възможните стойности са:
|
Общо качество |
Обажданията на Webex Calling се степенират за качество. За срещите в Webex или сесиите с обаждане в Webex обаче това оценяване не се прилага. Практическата работа с обажданията се окачествена като:
|
Лично качество |
Качеството на отделния сегмент на обаждането на потребителя. |
Времево клеймо |
Начален час на обаждането. |
Номер на повикващия |
Номерът на повикващия от Webex, присвоен на повикващия. |
Име на повикващия |
Име на обаждащата се. |
Номер на повиквания |
Webex Calling номер, присвоен на повиквания. |
Име на повиквания |
Име на повикания. |
Продължителност |
Времето, през което е продължило обаждането. |
Местоположение |
Местоположение на обаждащия се от Webex Calling. |
ИД на корелация |
Идентификатор на корелация за свързване на множество повиквания segments/call краката на едно и също повикване. |
Ключови показатели за ефективност (KPI) на търсения потребител

Следните KPI са налични за раздела Webex Calling, когато търсите потребител:
-
Общо повиквания – Общ брой повиквания.
-
Общ брой сегменти на обажданията – Общ брой сегменти на обажданията.
-
Неуспешни сегменти на повикванията – Брой неуспешни сегменти на повикванията.
-
Отхвърлени сегменти на повикванията – Брой отказани сегменти на повикванията.
-
Сегменти на обажданията с лошо качество – Брой сегменти на обажданията с лошо качество.
Какво е сегмент за обаждане?
Сегментът на повикването представлява отделна част от повикване на Webex Calling. По същество всеки директен преход или връзка между двама участници представлява един сегмент от повикването.
Например, ако Алис се обади на автоматичен оператор, който отклони повикването към Боб, повикването от Алис към автоматичен оператор се счита за един сегмент от повикването, докато повикването от автоматичен оператор към Боб се счита за друг сегмент от същия поток на повиквания. Следователно едно сложно повикване може да се състои от множество сегменти за повикване.
Обикновено сегментът на обаждането се състои от два сегмента на обаждането (CDR): начален крак и краен крак. Въпреки това, в сценарии, включващи PSTN повиквания, от перспективата на Webex Calling може да се генерира само един канал за повикване (крайният канал за потребителя на Webex).
Всеки сегмент от обаждането може да има различен резултат (например успех, неуспех, отказ). Следователно, представянето на комуникационните събития като сегменти на повикванията в изгледа за отстраняване на неизправности в Control Hub е от решаващо значение. Това позволява на клиентите да наблюдават пълно разбиване на отделни сегменти, което дава възможност за прецизно идентифициране на проблеми в рамките на сложен поток от обаждания.
Обобщена информация за повикванията

Разделът с обобщение на обажданията на страницата с подробности за обажданията визуално представлява цялостно, цялостно представяне на цялата поредица от обаждания. Този изглед на високо ниво позволява на клиентите да визуализират целия поток на повикване, дори когато то обхваща множество логически „повиквания“ (както е дефинирано от общи идентификатори на корелация) или сложни сценарии за прехвърляне. Резюмето на повикванията интелигентно обединява всички междинни преходи и свързани „повиквания“, за да осигури цялостен и съгласуван поглед.
Обобщението на обажданията ви позволява бързо да разберете потока на обаждането от началото до края във визуален изглед на времевата линия. Всеки участник отляво представлява типа потребител (PSTN, група за търсене, опашка за повиквания и др.), докато редовете пред него представляват взаимодействието при повикване за този участник. Взаимодействията между двама участници са сегменти на разговора. Като задържите курсора на мишката върху участник, можете да видите подробна информация, като например име, тип потребител, времева маркировка за продължителност и други. Можете да кликнете върху конкретни участници, за да видите подробностите за сегмента на обаждането в изгледа „hop“ под картата с обобщение на обаждането на същата страница. Обърнете внимание, че някои от участниците с потребителски типове PSTN и Local Gateway не са кликаеми.
Обобщението на обажданията също така подчертава действията по време на обаждането, като набиране, паркиране, прехвърляне и др. И състоянието на свързаност, като например неуспех, отказ. Можете да задържите курсора на мишката върху конкретни знаци, за да получите повече подробности, което ще ви помогне да идентифицирате и отстраните проблеми точно в точката, където са възникнали.
Например, екранната снимка по-горе представлява повикване, при което външен потребител на PSTN се е свързал с автоматичен оператор, който е насочил повикването към опашка за повиквания. След това обаждането беше пренасочено към двама агенти, от които вторият агент взе обаждането и разговаря с потребителя на PSTN. Наслагванията за качество на медийното съдържание представляват качеството на медийното съдържание в крайните точки. Легендите предоставят допълнителни подробности, които да ви помогнат да разберете обобщението на обаждането.
За по-подробно обяснение на раздела с обобщение на обажданията, можете да гледате това видео
Следните сценарии не се поддържат от диаграмата за обобщение на повикванията:
- Потоци от конферентни разговори, като например Конференция, Включване, Мост на повиквания и Сливане на повиквания.
- Функции на надзорник на опашката от повиквания, като например безшумно наблюдение, насочване, намеса, поемане и др.
- Информация за съобщения, възпроизведени до крайните точки.
- Информация за повиквания, които са поставени на изчакване и възобновени по време на активно повикване.
- Ситуациите с неуспешно и отхвърлено повикване може да се окажат с различни причини от всяка страна на сегментите на повикването поради вътрешни състояния на повикванията.
Изглед с подробности за хопа
Следните данни са налични в изгледа с подробности за хопа:
Термин | Определение |
---|---|
Крайна точка |
Показва едно от следните:
|
Хардуер |
Показва едно от следните:
|
Местоположение |
Местоположение за повиквания от Webex, конфигурирано за потребителя. Държавата, в която е предоставена услугата Webex Calling, също е показана в скоби. |
Локален IP адрес |
Локалният IP адрес на клиента за мрежовия интерфейс, който той използва за предаване на мултимедия. IP адресите са частично маскирани, за да се запази личната идентичност на потребителите. |
Публичен IP адрес |
Това е публичния IP адрес на клиента, както се вижда от облака. За предприятията това е адресът на защитната стена, предоставяща NAT. IP адресите са частично маскирани, за да се запази личната идентичност на потребителите. |
MAC адреси |
MAC адресът на крайната точка на клиента. |
Географски координати |
Гео справка на Публичен IP адрес. Този адрес не е точен, ако е свързан през PNC. Ако потребителят използва Приложението Webex и се свързва с предприятието чрез VPN услуга, местоположението не е точно. |
ISP |
Доставчик на интернет услуги, който осигурява мрежова свързаност към Облака за извикване на Webex. |
Мрежа |
Типът мрежова връзка, която клиентът е използвал за обмен на носител. Възможните стойности са:
|
Аудио кодек |
(Изпращане или получаване) Форматът на медийно кодиране и декодиране, който се използва за носителя, които се предават от клиент. |
Видео кодек |
(Изпращане или получаване) Форматът на медийно кодиране и декодиране, който се използва за носителя, които се предават от клиент. Важи само за видеоразговор. |
Идентификационен номер на SIP сесия |
Оригинален (или начален) и краен идентификатор на сесия. |
Съединителна линия |
Достъпно само когато локален шлюз е включен в прехода. Име на входящата и изходящата магистрала. |
Група за маршрутизиране |
Достъпно само когато локален шлюз е включен в прехода. Име на групата маршрути. |
Име на доставчик на PSTN |
Достъпно само когато PSTN е включен в прехода. Име на доставчика. |
Някои показатели са маскирани в екранните снимки на статията, за да се запази самоличността на потребителя.
От подробностите за хмела можете:
-
Вижте дали преходът е бил маршрутизиран през PSTN или локален шлюз.
-
Вижте типа потребител, който е осъществил или получил обаждането. Някои примери включват
HuntGroup
,VoiceMailGroup
иRoutePoint
. Докладът „Подробна история на обажданията “ предоставя списък с всички възможни типове потребители. -
Вижте анализи за обаждането в тези сценарии:
-
Нямаше медийна информация за нито един от преходите, свързани с обаждането.
-
Настройката на оптимизацията на пътя беше неуспешна.
-
Един от скоковете се провали или отказа повикването. Неуспешните хопове са маркирани с червено, а отказаните хопове са маркирани с жълто. Посочва се и причина, поради която скокът е бил неуспешен или е бил отказан.
-
-
Задръжте курсора на устройството, за да видите практическата работа с обажданията от край до край.
-
Задръжте курсора на курсора на хмела между крайната точка и Webex Calling облака, за да видите подробностите за хмела.
Цялостното преживяване при обаждане се основава на данните за качеството на медийното съдържание, които се събират от всяка регистрирана крайна точка на Webex Calling (приложение Webex или устройство, като например 8865 или Desk Pro) в края на разговора. Разговорът се оценява като добър, ако крайната точка има следните прагове:
-
Загуба на пакети по-малка от 5%.
-
Латентност или време за отиване и обратно предаване (RTT) по-малко от 400 ms.
-
Трептене по-малко от 150 ms.
Качеството на хмела произлиза от данни, които се събират от медийната релейна точка в облака Webex Calling . За PSTN повиквания чрез CCPP или локален шлюз, събирането на данни е от облака Webex Calling , а не от крайната точка pstn. Преходът се оценява като добър, ако точката за медийно реле има следните прагове:
-
Загуба на пакети по-малко от 2.5%.
-
Латентност или RTT по-малко от 200 ms.
-
Jitter по-малко от 75 ms.
Можете също да запазите данните в детайлите на хопа, като изберете Действия и след това изберете една от следните опции:
- Запазване на записи за обаждания за отстраняване на неизправности (CSV)
- Записване на отчет за повикванията (JSON)
- Записване на подробностите за участниците (CSV)
Панел с подробности за повикването
Следните данни са налични в десния панел „Детайли за повикването“ на изгледа с подробности за прехода:
Термин | Определение |
---|---|
ИД на корелация | Корелация ID за свързване на няколко кол крака на една и съща кол сесия. |
Дата на повикването | Датата, когато е възникнало обаждането. |
Час на повикването | Часът на началото и края на разговора, показан в часовата зона, която сте избрали в изгледа за търсене. |
Тип на сесията |
Типът на сесията, която се поддържа. Например: Повикване в Webex |
Участници | Броят на участниците, които се присъединиха към обаждането. |
Име на повикващия | Име на обаждащата се. |
Имейл на повикващия | Имейл адрес на обаждащата се. |
Номер на повикващия | Телефонен номер, който повикващият е използвал по време на разговора. |
Аудио | Типът на използваното аудио. |
Видео | Показва Да, ако видеото е активирано от участник. Ако видеото изобщо не е било активирано, се показва Не. |
Оптимизиране на пътя |
Указва, ако оптимизацията на пътя на обажданията се отнася за обаждането. Приетите стойности са:
|
Тип повикване |
Тип извикване може да бъде едно от следните:
|
Разговорът е приключен от |
Потребител, който е прекратил обаждането. |
Набрани цифри |
Цифрите на клавиатурата, набрани от потребителя, преди предварителните преводи. |
Свързана причина |
Показва причина, поради която е създаден хмелът. Например, стойност |
Достъп до изгледа за отстраняване на неизправности в Webex Calling
Поддържа се частично търсене за имейл идентификатори, телефонни номера и идентификатори на обаждания. За телефонни номера можете да въведете първите три до осем цифри и след това да натиснете Enter, за да видите съответстващите записи. Ако въведете повече от осем цифри, търсенето ще се опита да намери точно съвпадение. Обърнете внимание, че ако копирате и поставите телефонен номер от друго място, трябва да включите +1 за да работи търсенето.
За да анализирате webex повикване, извършете следното:
1 |
Влезте в Control Hub и отидете на Monitoring > Отстраняване на неизправности. |
2 |
Потърсете имейл адреса, телефонния номер, MAC адреса, идентификаторите на обажданията или идентификатора на корелацията, който искате да видите. Можете да групирате свързани повиквания заедно в изгледа за търсене, като използвате идентификатора на корелацията. |
3 |
Приложете филтър по ваш избор. Наличните филтри са:
Филтрите не са налични, ако търсите телефонни номера или идентификатори на корелация. |
4 |
Щракнете върху конкретно повикване, за да прегледате изгледа с подробности за прехода. |
Изтегляне на резултати от търсенето или отстраняване на неизправности със записи на обаждания като CSV файл
Можете да изтеглите резултатите от търсенето или записите за отстраняване на неизправности в обажданията като CSV файл. Тези записи предоставят подробности на ниво етап на обаждане, за да помогнат за отстраняване на неизправности.
Можете да експортирате до 100 записа за повиквания за отстраняване на неизправности в един CSV файл.
Когато кликнете върху „изтегляне“, резултатите от търсенето ще бъдат изтеглени за раздела, в който се намирате. Така че, ако искате да изтеглите записи от Webex Calling, уверете се, че сте в раздела Webex Calling.
1 |
Влезте в Control Hub и отидете на Monitoring > Отстраняване на неизправности. |
2 |
След като имате списък с обаждания, които искате да видите, изберете Изтегляне на записи за обаждания за отстраняване на неизправности (CSV). илиМожете също да изтеглите записите за отстраняване на неизправности от страницата с подробности за обажданията. Тук можете да изтеглите записите на обажданията за отстраняване на неизправности, отчета за обаждането във формат JSON и данните за участника като CSV файл. |
Отстраняване на проблеми с качеството на медиите
Изгледът хоп-бай-хоп ви помага да намерите къде е възникнал проблемът. Сега, след като сте открили къде е проблемът, и с показателите (тревоги, загуба на пакети, латентност) можете да опитате следното, за да отстраните проблема.
Типични възможности за медийни проблеми са:
-
Network/ISP/location специфични проблеми— Поради защитна стена, мрежова конфигурация или честотна лента, има модел на лошо преживяване в определено местоположение или мрежова подмрежа. Използвайте изгледа за отстраняване на неизправности на повикване (идентифицирайте местоположението, свързано с лошата сесия) с изгледа за анализ, за да прегледате съвкупните модели за местоположението.
-
Проблеми, специфични за потребителя— Потребител или устройство е свързано към лоша мрежа (например Wi-Fi или работа от вкъщи), което означава, че работата му е засегната от свързаните мрежови възможности. Вижте статията Използване на CScan за тестване на качеството на мрежата за обаждания на Webex, за да идентифицирате проблема с мрежата.
-
Проблеми, специфични за типа обаждане— Лошото потребителско изживяване се дължи на качеството от другата страна. Това е типично в PSTN сценарии, където потребителят говори с друг потребител в мобилна мрежа и сесията има висока загуба на пакети в PSTN мрежата.
-
Проблем с липса на медия— Възможно е да няма предаване на медия в някои хопове. Банерът „Информация“ показва причината в горната част на страницата с подробности за преместването, а отговорната страна – в информационното поле на страницата с подробности за преместването. Някои от възможните причини за липса на медиен сигнал по време на разговори, както и отговорните лица, са изброени тук:
-
Webex не получава медийни файлове от подателя.
-
Webex не получава медийни файлове от приемника.
-
Webex не получава медийни файлове от нито една от двете посоки.
-
Webex не изпраща медийно съдържание към получателя. Инженерингът на Webex решава този проблем.
-
Webex не получава медийни файлове от Cloud PSTN. Инженерингът на Webex решава този проблем.
-
Webex не получава медийни файлове от облачната услуга. Инженерингът на Webex решава този проблем.
-
Webex не получава медийни файлове от локалния шлюз. Администраторът на клиента трябва да проучи проблема.
-
-
Неуспех при оптимизиране на медийния път— Малко извиквания не могат успешно да настроят оптимизацията на медийния път. Банерът „Информация“ показва причината за неуспешните ICE повиквания и решението в горната част на страницата с подробности за Hop.
Някои от възможните причини са:
-
ICE неуспешен поради достъп до stun сървъра - вижте информацията за справочната информация за порта за извикване на Webex.
-
ICE неуспешен поради проверка за свързаност - проверете свързаността между мрежите.
-
ICE неуспешен, тъй като времето за двупосочно пътуване по подразбиране беше similar/better отколкото всеки оптимизиран път.
-
Ограничения
Показателите за качество на медиите и генерирането и завършването на потоци от страна на мрежата не са налични за следните устройства:
-
Аналогови телефони
-
Устройства на трети страни
-
IPv6 крайни точки
Поддържани потоци от обаждания
Отчетите за качеството на медиите се събират от крайните точки на обаждащата се и callee и точките за реле на носителя. Това позволява сегментиране на медийното изживяване да се стесни и да установи дали проблемът е възникнал при:
-
Повикващия или callee
-
Медиен път към или от облака Webex Calling .
Обадете се краката се появяват, ако е имало медийна сесия, която е установена с поне една Webex Calling регистрирана крайна точка на повикването. Например, за изходящо обаждане от ловна група до осем агента, ако само един агент отговори, тогава няма медиен опит за отстраняване на неизправности за останалите седем агенти.
Има пет типа медийни изживявания или пътища за Webex Calling отстраняване на неизправности, които са:
-
Оптимизирано за мрежата – Разговори в организацията, където ICE е успешен и медийният поток се предава директно между потребителите. Вижте Webex Оптимизация за фономедии с установяване на интерактивна свързаност (ICE) за подробна информация.
-
Неоптимизирано в мрежата – Разговори в организацията, при които установяването на интерактивна свързаност (ICE) не е било възможно или не е било осъществено. В този случай носителят тече през Webex извикване облак.
-
В мрежата, хоствано в облака – Разговори в организация, при които медийното съдържание се предоставя от медиен сървър, хостван в облака (например, слушане на гласова поща, набиране на автоматичен секретар).
-
Извънмрежово повикване към или от регистрираната крайна точка на Webex Calling -
-
чрез доставчик на свързана с облака PSTN мрежа- Входящи и изходящи повиквания на организация, когато другата страна е в PSTN мрежата. Носителят се препредава чрез облак свързан PSTN доставчик (CCPP), над висококачествена взаимна връзка.
-
чрез локален шлюз- Входящи и изходящи повиквания на организация, където медийният поток на другата страна е през предприятието. Зад местния шлюз медийната сесия може да бъде от предприятие хостван потребител (например, регистриран да се обади контрол в предприятието) или от PSTN, където PSTN се предоставя от предприятието.
-
Ако има 1 или 2 Webex Calling регистрирани потребители, които участват в повикване от точка до точка в мрежата, тогава изгледът за отстраняване на неизправности представя показатели за една или и за двете страни. Ако повикването е изключено нетно (Потребител 1 получава обаждане от pstn потребител), тогава изгледът за отстраняване на неизправности представя само клиентските показатели на User1, заедно с показателите, взети от точката на реле на носителя.
Повечето от сценариите за обаждания в изгледа за отстраняване на неизправности показват два крака за повикване (обаждащ се и callee); някои от сценариите за обаждания (като например call park или извличане) обаче показват само един нога за повикване. В такива случаи другият кол крак се показва отделно в изгледа за отстраняване на неизправности. Това не възпрепятства отстраняването на неизправности при повикването и откриването къде е възникнал проблемът. Той обаче изисква администраторът ръчно да корелирам двата кол крака, като използва общ обект като припокриващо се време. Бъдещите подобрения в изгледа за отстраняване на неизправности ще премахнат необходимостта от използване на ръчни справки.
Показателите за хмела варират по време на сесия в зависимост от времето за вземане на проби и променливостта в мрежата. Стойностите, които се отчитат от медийната релейна точка и клиентите (опит от край до край), може да не се подравнят. Те обаче трябва да са в тясно подравняване, за да позволят сегментиране по пътя.
Препоръчахме да използвате изгледа за отстраняване на индивидуални повиквания с обобщената информация, която е получена от Google Анализ.
Нека анализираме качеството на обажданията за различните типове обаждания с помощта на изгледа за отстраняване на неизправности.
Повиквания в рамките на организацията, където ICE е успешна и медийното реле в облака се премахва от пътя. Медийният поток е директно между устройствата на потребителя.
Извод:
1 |
Обаждането е окачествено толкова добро, колкото и обаждащата се, и callee имат добър опит от край до край. |
2 |
Администраторът може да наблюдава, че мултимедията тече директно между двамата потребители и не пътува през Webex повикване облак. Оптимизираните потоци от обаждания могат да имат лош опит, ако предприятието или локалната мрежа е източникът на проблема, тъй като медиите между двамата потребители ще престъпят локалната мрежа. Латентността или RTT винаги е по-ниска на оптимизирано повикване, но загубата на пакети и нервността все още могат да бъдат фактор в зависимост от мрежата между двамата потребители. |
Извод:
Администраторът може да наблюдава следното:
1 |
Опитът на обаждащите се от край до край е качествен като беден. |
2 |
Има проблем с мрежовия хоп на повикващия, който засяга както изпращането, така и потока на получаване. |
3 |
Мрежовият хоп на callee няма проблем. |
4 |
Опитът на callee от край до край е окачествен като беден поради проблема от повикващия. |
Извод:
Обаждането се оценява толкова добре, колкото преживяването от край до край на повикващия е в рамките на приетите прагове. Администраторът може да наблюдава, че следното:
1 |
Мрежовият хоп за повикващия се оценява като беден, тъй като някои от показателите са над приемливия праг. |
2 |
Потокът за изпращане от гласовата поща се окачествен като добър за показателите, събрани от точката на реле на носителя. |
3 |
Медийният сървър, използван за събиране или депозиране на гласовата поща, понастоящем не отчита показатели. Въпреки това тези сървъри се хостват и управляват като част от Webex Calling Cloud така че качеството на този сегмент на връзката е вътрешно и винаги високо качество, ниска латентност. |
4 |
Администраторът може да наблюдава опита на обаждащата се от край до край е качествен като добър, въпреки че хмелът е окачествен като беден. Това се дължи на хопа на callee има добра мрежа, която компенсира влошаването на производителността на мрежата на обаждащата се. |
В примера клиентската медия идва от PSTN доставчик през облака.
Обаждането е окачествено като лошо, тъй като опитът на callee от край до край не е в рамките на приетите прагове. Администраторът може да наблюдава следното:
1 |
Проблемът е с PSTN хопа на обаждащия се специално с изпращащия поток. |
2 |
Мрежовият хоп на callee няма проблем. |
3 |
Опитът на callee от край до край е окачествен като беден поради проблема от повикващия. |
4 |
Опитът от край до край и показателите за потока на получаване на обаждащия се, който е в PSTN мрежата, в момента не са достъпни, тъй като тези показатели не се предават на Webex Calling Cloud. |
Извиква и излиза от организация, в която медиите на обаждащата се идват от предприятие. Медийната сесия може да бъде от предприятие хостван потребител (например, регистриран на UCM) или от PSTN, където PSTN се предоставя чрез предприятието.
Извод
Обаждането се оценява като лошо, тъй като опитът от край до край на повикващия не е в рамките на приетите прагове. Администраторът може да наблюдава следното:
1 |
Има проблем с хопа на повикващия към Webex Calling Cloud както при потока за изпращане, така и за получаване. |
2 |
Опитът от край до край на повикващия се оценява като беден или поради проблема, наблюдаван в хмела, или проблемите в края на потребителя (устройства, мрежа и т.н.) |
3 |
Входящият трафик към Webex Calling Cloud от края на callee е оказиониран като добър. |
4 |
Опитът от край до край и показателите за потока на получаване на callee, който се нарича от локалния шлюз, в момента не са достъпни, тъй като тези показатели не се предават на Webex Calling Cloud. |
Отстраняване на неуспешни и отказани повиквания
Колоната Състояние на повикването показва дали повикването е било успешно, отказано или неуспешно. Когато дадено повикване има статус Отказ или Неуспех, можете да задържите курсора на мишката върху статуса, за да видите съответния код.
Когато разглеждате списъка с обаждания на потребител, е наличен ключов показател за ефективност Неуспешно обаждане, за да се определи бързо дали потребителят има сериозни проблеми. Можете да задържите курсора на мишката върху състоянието Отказ или Неуспех, за да видите конкретния код, свързан с всяко състояние.
В изгледа с подробности за прехода се показва банер, който ви показва повече информация за това защо повикването има статус Отказ или Неуспех. Можете също да видите дали състоянието на повикването се е случило по време на първоначалния или завършващия преход.
Пример за неуспешни сценарии за повикване
Код за грешка: Няма маршрут към местоназначението
Опит за повикване е направен от устройство на работното място, но е неуспешен поради липса на наличен маршрут до дестинацията.
Код за грешка: Грешка в протокола
Опит за повикване е направен от устройство на работното място, но е неуспешен поради грешка, свързана с протокола.
Код за грешка: Вътрешна грешка
Осъществено е повикване от локален шлюз, но неуспешно поради вътрешни грешки в устройството на работното място в дестинацията. Разговорът е бил установен в продължение на 14 минути, преди да възникне вътрешна грешка.
Пример за сценарии за отказ на повикване
Код за отказ: Повикването е отхвърлено

Опит за повикване е неуспешен, защото опитът не е успял да достигне до местоназначението или интерфейсът към местоназначението не е функционирал правилно. Примери за отхвърлени сценарии са следните:
-
Опитът за обаждане е отхвърлен поради отхвърляне на анонимно обаждане.
-
Опитът за повикване е отхвърлен поради разрешения за входящи повиквания.
-
Опитът за повикване е отхвърлен поради разрешения за изходящи повиквания.
-
Опитът за повикване е отхвърлен поради разрешения за изходящи повиквания.
-
Опитът за повикване е отхвърлен поради конфигурирано прехващане на повикване.
-
Опитът за повикване е отхвърлен поради неуспешно паркиране на повикване или извличане на повикване.
-
Опитът за повикване е отхвърлен поради отказ на функцията „Натисни и говори“.
-
Опитът за повикване е отхвърлен поради селективно приемане на повикване.
-
Опитът за повикване е отхвърлен поради селективно отхвърляне на повикване.
-
Опитът за обаждане е отхвърлен поради грешки като неизвестен номер, недостатъчни разрешения и др.
Код за грешка: Неприсвоен номер

Обаждащият се е опитал да се обади, но е бил отхвърлен, защото дестинацията е била към незададен номер.
Причини за резултата от обаждането
Следната таблица изброява кодовете за отказ и за неуспех, налични за неуспешни повиквания.
Причина за резултата от повикването | Определение |
---|---|
Успех |
Обаждането беше успешно. Възможните кодове са:
|
Отказ |
Обаждането беше отказано. Възможните кодове са:
|
Неуспех |
Неуспешно повикване. Възможните кодове са:
|