Вы здесь

Правильный диалплан (dialplan) в крупной организации или Globalized Call Routing

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

Mulisite Dial Plan

В крупной организации, имеющей множество филиалов по стране и тем более по миру, возникают некоторые специфические вопросы касающиеся overlapping directory numbers, PSTN access, PSTN backup, использование Tail-end Hop-off и т.д.

Входящие звонки

Чаще всего в России входящие звонки приходят на некоторый фиксированный номер или номера, например 4955876983. Обычно затем номер DNIS транслируется на внутренний номер autoattendant или на секретаря и маршрутизируется.
Зарубежом иногда используется DID.

Пример использования DID

DID или Direct inward dialing - услуга, оказываемая некоторыми телефонными провайдерами, которая позволяет осуществить соединение на внутренние абоненты без использования IVR, автоответчика или секретаря.
Посмотрим как это выглядит на следующем примере:
voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_did_ciscomaster.ru.jpg
Здесь приём звонков в главном офисе происходит через Auto-Attendant, т.е. входящий звонок приходит на некоторый фиксированный номер 4955874512. Обычно затем номер DNIS транслируется на внутренний номер autoattendant или на секретаря и маршрутизируется на конктретный аппарат.

Входящие звонки в Remote Site организованы с использованием DID. Здесь внешний номер PSTN +49 404 13267, но пользователь может набрать сразу к примеру номер +49 404 13267 1002 и сразу попасть на внутренний номер 1002 минуя необходимость использования Auto-Attendant.

Numbering Plan и его компоненты

Правила образования конкретного номера в какой-либо стране называются Numbering Plan.

В состав любого номера могут входить следующие компоненты:
Country code - код страны. Для России Country code = 7
Посмотреть другие коды можно здесь: http://countrycode.org/

Area code - это код области или междугородний код внутри страны.

Subscriber Number - или local number это городской телефон в чистом виде, без Country code и Area code.

Все эти компоненты задаются общими правилами под названием Numbering Plan.

Numbering Plan в каждой стране может быть разным.
Например в Штатах он фикисированный, т.е. длина Area code и Subscriber Number всегда одинаковое.

В России фиксирована только общая длина, т.е. длина Area code + Subscriber Number всегда одинаковое.
В россии это 10 знаков, например:
Москва 495 5831211
Калуга 4842 577071
Т.е. несмотря на то что в разных городах длина Area code и Subscriber Number могут различаться, общая длина остаётся величиной постоянной.

С точки зрения CUCM Различия длины Subscriber Number сильно затрудняют использование Local Route Groupм. Настройка Call Manager CUCM с нуля: Связь с внешним миром H.323 и FXO(Часть 3)), поскольку городские номера разных городов могут не подходит под один и тот же шаблон.
Хорошо еще что Area code + Subscriber Number постоянно, и очень не сложно реализовывать Tail-End Hop-Off (TEHO).

Префиксы

Как мы только что рассмотрели, Numbering plan включает себя несколько уровней номеров:
- Internal - внутрення нумерация
- Local - Городская нумерация.
- National - Межгород
- International - Международная связь

Все эти номера отличаются друг от друга длиной. Системе нужно чётко понимать к какому номерному плану набираемый номер принадлежит.
Для это рекомендуется использовать префиксы:
- Trunk prefix - выход в город. Даёт доступ к городской нумерации Local. Обычно в России это "9"-ка.
- National Access Code - выход в межгород. Обычно в России это "8"-ка.
- International Access Code - выход в межгород - зависит от оператора, 8 - XX

10 – Rostelecom
26 – Arctel
27 – Synterra
28 – Comstar
56 – GoldenTelecom
57 – Transtelecom
58 – MTT
59 – Orange Business Services

Оптимизация Call Routing, а также Toll-bypass и Tail-End Hop-Off (TEHO)

Эти термины применимы к новым возможностям VoIP, одним из важнейших преимуществ которой является способность расширять границы звонков, классифицируемых как on-net, т.е. другими словами звонки между филиалами, находящимися в разных городах, можно сделать практически бесплатными.

Toll-bypass и Tail-End Hop-Off это стратегии построения маршрутизации звонков.
Toll-bypass: Дословно переводится как "обходить потери". Использует WAN-link для обеспечения звонков между удаленными офисами, тем самым позволяя экономить на звонках через PSTN.

Tail-End Hop-Off (TEHO): Можно перевести дословно как "поднятый конец хвоста". Здесь аналогичный метод идет дальше: звонок в другой город идет по WAN в этот город и "выныривает" из своей сети в PSTN как можно ближе к адресату.
Интересно, что в некоторых странах Tail-End Hop-Off (TEHO) запрещен на уровне законодательства (Не Россия).

toll-bypass_ciscomaster.ru.jpg

teho_ciscomaster.ru.jpg

Различные PSTN requirments

Что такое PSTN requirments?
Возьмем город Устькут.
Для выхода в город через местного провайдера нужно набирать городской пятизначный номер, например 51705.
А для звонка в тот же Устькут через Москву нужно набрать 8 39565 51705.

В различных странах используется различные форматы для выхода в межгород (national access code), например в штатах это 1, в европе 0, в России это 8. Различны также и international access code: 011 в Штатах, 00 в Европе, 10 - у нас в России.

В различных странах (и даже у различных операторов в одной стране) могут быть различные требования к PSTN Dial Rules.
Вопросы с этим связанные могут возникнуть в случае если настроить маршрутизацию звонков по различным выходам при определённых условиях (например только что описанное TEHO)
Например в случае если PSTN requirments для primary gateway будут отличаться от PSTN requirments для backup gateway.

Аналогичная проблема существует и в приложении к Calling Number (Automatic Number Identification ANI) у входящих звонков.
Звонок может прийти как короткий городской, или как 10-значный включая area code, например из Устькута в Москву может прийти 83956551705. Номер может также прийти в формате international, который в себя включает также и country code.
Для стандартизации Calling Number ANI необходимо знать формат в котором приходит номер.
Формат можно определить через длину номера либо через ISDN Signaling message: Type Of Number, TON.

Следующей проблемой является хранение номеров. В каком формате хранить номера в Address Book, speed dials? Ведь этот формат должен позволять их использование из любого местоположения организации.

Организация оптимальных маршрутов с использованием TEHO или Least Call Routing (LCR) также требует использования некого общего формата.

Итак для успешной работы по стране или по всему миру нужен некий универсальный формат.
Например в мировом масштабе этим форматом является E.164. Это всем известные номера, начинающиеся со знака +. Например +79109125869.
Формат E.164 является международным форматом и универсален по всему миру.

Globalized Call Routing

При Globalized Call Routing все звонки связанные с external parties базируются на едином, общем формате.
Тогда говорят, что номера normalized:

Чтобы избежать путанины, рассмотрим некоторые термины:

Термин Описание
Number
Normalization
Процесс изменения номера на некий общий, универсальный формат: Normalized Format
Например возьмём московский номер 4955891215, если универсальным форматом для нашей организации будет 11-значный формат межгорода, нормализованный номер будет выглядеть с 8-кой: 84955891215. Такой номер "пройдет" через любой шлюз по России.
Number
Globalization
Процесс изменения номера на глобальный формат E.164.
К примеру если наша организация не российского, но мирового масштаба, то Normalized Format вида 84955891215 нам не подойдёт. Универсальным форматом в этом случае будет только E.164 или Globalized Format. Московский номер тогда будет выглядеть: +74955891215. Этот формат универсален по всему миру. Обратите внимание, что в этом случае термины Number Normalization и Number Globalization будут означать одно и тоже.
Number
localization
Процесс изменения от Normalized Format (в нашем случае это есть Global Format) на Local Format. Local Format - это формат удобный местным (local) пользователям и понятный для местного провайдера.
Например возьмём российскую глубинку Устькут 8 39565 52725. Этот номер будет выглядеть:
Global Format: +73956552725
Local Format: 52725

Итак, при использовании Globalized call routing, нормализуются как called-party numbers, так и calling=party numbers. Нормализация не требуется только в тех случаях, если звонок полностью внутренний, т.е. идёт от внутреннего источника на внутренний адресат.

  • Входящий звонок (Call Ingress) - с точки зрения CUCM входящий звонок может идти от внутреннего пользователя, Incoming PSTN call от шлюза, через транк и т.д.
    Если source of call не использует Normalized Format, такой процесс называется localized call engress, и формат звонка должен быть normalized перед осуществлением дальнейшей маршрутизации. Нормализация применяется ко всем входящим звонкам и к обоим Calling- и к Called-party number
  • Исходящий звонок (Call egress) - после того, как звонок был смаршрутизтрован, он в конечно счёте приходит на egress device. На этом egress device нормализованные номера должны быть изменены to local fromat. Такой процесс называется localized call egress. При этом localized call egress применяется следующим образом:
    - Calling- и Called-party number меняются для звонков идущих на Gateways или Trunks. Например при звонке из Усть-Кута до Москвы: Globalized Called-party number +74955891215 будет заменён на формат понятный местному провайдеру 84955891215; Globalized Calling-party number внутренний 78562 будет заменён на 83956539565.
    - Calling-party numbers для звонков от gateways или tranks. К примеру если звонок идёт снаружи на внутренний телефон и внутренний абонент Устькута желает видеть Calling-party number без кода города, а в местном 5-ти значном формате.

Таким образом, Globalized Call Routing упрощает International dial plans, поскольку ядро Call-Routing decision всегда базируется на общем нормализованном формате, независимо от того откуда идёт звонок и куда.

Схема Globalized Call Routing

voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_globalized_call_routing_ciscomaster.ru_0.jpg

Термин Описание
Incoming PSTN Call Звонок от PSTN на Internal Phone. Состоит из двух Call Legs:
- Incoming Call Leg: PSTN Gateway > CUCM
- Outgoing Call Leg: CUCM > Internal Phone
Outgoing PSTN Call Звонок от внутреннего телефона на PSTN. Состоит из двух Call Legs
- Incoming Call Leg: Internal Phone > CUCM
- Outgoing Call Leg: CUCM > PSTN Gateway
Call ingress Incoming call leg - recieved by CUCM
Call egress Outgoing Call Leg - call routed to destination by CUCM
Localized E.164 Номер PSTN в частичном формате E.164, подаваемый местными тел. провайдерами. Например для московского номера в формате E.164 +7 499 589 12 11 большинство провайдеров подают номер как: 499 589 12 11
E.164 Number Номер PSTN в полном формате E.164

Пара комментариев к рисунку:
В левой стороне рисунка изображены два типа источников звонка:

  • External Callers - Эти звонки CUCM получает через Gateway или Trunk. В этом случае Calling- и Called-Party numbers приходят в формате localized E.164.
  • Internal Callers - звонки, которые CUCM получает от внутренних телефонов. В случае звонка на Internal Destinations Calling- и Called-Party numbers приходят как internal directory numbers. В случае звонка на External Destination: Calling number - Directory Number, Callled Number - зависит от локальных правил набора.

В центре рисунка отображены стандарты для Noramlized Call Routing, а в нашем случае это Globalized Call Routing.

В правой стороне изображены два типа Call Targets для звонков Call Egress:

  • Gateway - Для обоих Calling- и Called-party Numbers используется Localized E.164 Format. Этот формат может существенно различаться в зависимости от местоположения шлюза.
  • Phones - Если звонок идёт с телефона на телефон, то тут для Calling- и Called-party Numbers используются Internal Directory numbers. Если же звонок идёт от внешнего источника, то Called-party Number: Internal Directory numbers, Calling-party Number: Большинство пользователей предпочитают видеть в localized Format.

Таким образом, localized Call Ingress должен быть Normalized, и, затем Normalized format должен быть Localized в случае Call Egress.

Normalization of Localized Call Ingress on Gateways

Рассмотрим подробнее что должно происходить на Gateway для нормализации входящего звонка.
Для нормализации звонка будут следующие требования:

  • Изменение Calling Number: Localized E.164 Format --> Global E.164 Format
    Для нормализации нужно добавить префикс. Префикс добавляется на уровне Gateway или Device pool, в разделе Incoming Calling Party Settings
    Здесь мы можем выполнить add prefix, strip digits, или выполнить более комплексное преобразование через использование Transformation CSS.
    Transformation CSS могут быть применены на уровне Gateway, Device Pool или Cisco CallManager service Parameters.

    Например настройка MGCP Gateway для Тюмени будет выглядеть:
    voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_gateway_normalization_ciscomaster.ru_0.jpg
    В результате Incoming Calling Party Number будет нормализован (Глобализован)

  • Изменение Called Number: Localized E.164 Format --> Internal Directory Number
    В случае использования DID, нам необходимо "откусить" левую часть номера. Этот функционал обеспечивается через Significant Digits на уровне Gateway или Device pool.
    voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_significant_digits_ciscomaster.ru.jpg
    В России чаще DID отсутствует, в этом случае мы можем использовать либо called-party settings на уровне Transformation CSS (под вопросом), либо используются Translation Patterns. Translation Patterns транслирует внешний номер на внутренний. Часто это используется одновременно со сменой CCS.
    voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_translation_pattern_example_ciscomaster.ru.jpg
  • Изменение Called Number: Localized E.164 Format --> Global E.164 Format (если требует ситуация)

Normalization of Localized Call Ingress from Phones

На телефоне номер можно набрать несколькими способами: из телефонной книги, через Redial вручную и т.д.
При этом на телефоне допускается набор номера в формате E.164, т.е. с префиксом +. Данный префикс не на всех моделях может быть набран вручную, поэтому чаще всего номер в формате E.164 набирается при использовании call lists, directories, speed dials, а также приложений типа click to dial.
Некоторые из этих способов могут потребовать номрализации.
Для нормализации на телефоне следующие требования:

  • Звонок наружу
    Calling party number: Internal Directory Number --> E.164; Используется External phone Number Mask в св-вах DN телефона. Но чаще преобразование происходит на уровне Gateway и Calling Number Transformation Pattern.
    Called party number: Любой --> E.164; Используется Translation Pattern, причём он должен быть связан с Line CSS (Translation Pattern также можно использовать и для Calling party number)
  • Звонок внутрь: Нормализация не требуется.

Localized Call Egress at Gateways

Вообще трансформацию для исходящих звонков можно выполнять грубо говоря в двух местах:
- На уровне route group at the route lists
- На уровне Gateway Global Transformations.
Второй вариант считается наиболее гибким и предпочтительным.

Единственное требование - изменить Calling и Called Party Number: E.164 --> Localized E.164.

Как уже было сказано Global Transformations выполняется на уровне Gateway, т.е. настройку Calling и Called Party Transformation patterns

Пару слов о Transformation patterns:
Calling и Called Party Transformation patterns - наиболее универсальный тип трансформации, хотя и более сложный в настройке.

- Called and Calling-Party Transformations Patterns настраиваются глобально.
- Patterns помещаются в свои, специально созданные Partitions.
- Called and Calling-Party Transformations CSS могут быть подключены на уровне Egress Device или на уровне Device pool, тем самым разграничивая зону действия паттерна.
- Настроенный Transformations CSS определяет кому данный Transformations Pattern будет виден, а кому нет.

Called and Calling-Party Transformations применяются только на звонки идущие от CUCM на девайс.
На практике это означает что например для шлюза в город Calling-Party Transformations будут применяться только для исходящих наружу звонках.

В качестве примера, на шлюз в г. Тюмени можно повесить следующие Called and Calling-Party Transformations:
voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_transformations_pattern_ciscomaster.ru.jpg
На рисунке первые 4 паттерна добавлены "на всякий случай". В идеале при правильной настройке Globalized Call Routing наружу должны валиться только номера подходящие трём последним паттернам.
Если к примеру звонок идёт на номер +79109126072, то согласно паттерну, у него отнимается "+7" и добавляется "8", получается номер 89109126072, понятный для местного провайдера.
Как видно, разным типам номера (Local, National, International) соответствуют разные шаблоны и разные преобразования. Тип номера определяется по его длине и шаблону. Тип номера можно также определять и по метке, приходящей вместе с номером. Эту метку (Local, National, International) можно также выставлять на уровне Called Party Transformation Pattern. В России тип номера достаточно задавать через шаблон, т.е. провайдер знает, что номер c "8" это Natinal, номер с 810 International, номер без префикса есть local.

Localized Call Egress at Phones

Для чего нужна Localized Call Egress at Phones.
Дело в том что не все пользователям нравится когда у них номер отображается в формате E.164. Например пользователи Устькута едва ли захотят видеть номера их города в формате +73956551705, для них гораздо понятней будет номер 51705, т.е. наиболее короткий subscriber number.
voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_inbound_call_ciscomaster.ru.jpg
Как видно из рисунка при применении Localized Call Egress at Phones локализация применяется в зависимости от расположения телефона и этот локализованный номер отображается на экране. Но при этом номер в Globalized Format остаётся и именно на него будет осуществляться Callback.

Единственное требование преобразования Calling Party Number: Global E.164 --> Localized E.164

Звонки на телефон можно преобразовывать с использованием Calling-party transformations patterns: паттерны кладутся в партиции, которые в свою очередь ассоциируются с CSS. В св-вах Device pool выставляется Calling Party Transformation CSS. На конечный телефон паттерны применяются через этот device pool.

Например для пользователей Тюмени удобно было бы видеть звонки из тюмени по короткому городскому номеру:
\+73452.XXXXXX PreDot, Prefix 9

Пример Outbound call

Рассмотрим пример внедрения Globalized Call Routing.
tyumen_global_routing_example_ciscomaster.ru_0.jpg

Предположим что пользователь в Тюменском центральном офисе набрал номер телефона 89109126072.
Normalization of Localized Call Ingress from Phones
Набранный номер попадёт на Translation pattern 98.XXXXXXXXXX: в результате его применения от номера отнимутся 98 и прибавится +7. В итоге номер станет вида Global E.164: +79109126072

CUCM Globalized Call Routing
Набранный номер подходит под общий Route Pattern \+!, который ведёт на Standard Local Route Group.
Поскольку в Тюменском Device Pool в поле Local Route Group прописана TMN_Tyumen_PSTN_RG_1, то звонок отправляется именно туда.

Localized Call Egress at Gateways
Далее звонок поступает на Шлюз.
Здесь у нас включаются Gateway Global Transformations с использованием Calling и Called Party Transformation patterns.
Called party: У номера отнимается +7 и добавляется 8.
Calling Party: Локальный номер источника подменяется на local 3452532507

Номер отдаётся оператору связи.

На примере также видно организация TEHO, см шаблоны:
+73452XXXXXX pattern
+7495XXXXXXX pattern
+734997XXXXX pattern
С помощью этих шаблонов некоторые специфические номера можно отправлять на определенные Route Lists.

Еще один хороший пример см. TVOICE V.8, стр. 3-205, глава Verifying Globalized Call-Routing Configuration Elements

Выполнение Tracing Inbound Globalized Call Setup

Со стороны шлюза трейс можно выполнить на маршрутизаторе MGCP (E1) через команду:
debug isdn q931

Со стороны CUCM выполнение трейса потребует нескольких пунктов:

  • CUCM Administration > System > Service Parameters
    Выставляем Digit Analysis Complexity на значение TranslationAndAltematePattemAnalysis
  • Enable Traces
    • Идем на http://:8443/ccmservice/ или CallManager Serviceability
    • Выбираем Trace > Configuration
      enable_log_traces_ciscomaster.ru.jpg
    • Выставляем параметры примерно как на скриншоте (выбрать можно и больше опций). Убедитесь что выставлены "Trace on", Debug trace level - Detailed, H245, H225
      voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_trace_filter_settings_ciscomaster.ru.jpg

      То же самое повторяем на всех остальных серверах кластера.

      Если мы хотим траблшутить Digit Analisis, нужно включить details about translation patterns and alternate matches - по умолчанию показывается только finally matched pattern.
      System > Service Parameters > Cisco Call Manager
      Выставить параметр Digit Analysis Complexity на значение TranslationAndAlternatePatternAnalysis.

      Если мы выбрали device name-based trace, можно задать число одновременно анализируемых устройств:
      System > Enterprise Parameters
      Параметр Max Number of Device Level Trace по умолчанию равен 12.

Определение времени звонков

Для определения времени проблемного звонка мы будем использовать "родной" CDR analysis and reporting
Его первоначальная настройка подробно описана в статье Настройка учета звонков в CUCM 7.1
CDR analysis and reporting позволит нам получить список все осуществленных звонков данным клиентом:
Открываем CDR analysis and reporting > CDR > Search > By User/Extension
Далее вводим временные рамки и производим поиск звонков.

Загрузка трейсов для анализа

Для загрузки нужно использовать утилиту RTMT.
Установка RTMT:
CUCM Administration -> Application -> Plugins

- Запускаем RTMT, и заходим под учеткой CM Administration
- Выбираем System > Tools > Trace > Trace & Log Central, выбираем Collect Files
RTMT_log_tarces_ciscomaster.ru.jpg
- В окне Сollect files выбираем Cisco CallManager service
- В следующем окне выбираем все сервисы
- Выбираем Time range, а также директорию куда кидать файлы. Зиповать не надо.
- Запускаем сбор логов

Интересующие нас логи окажутся в папке:
...\log4\gem1cm01\2012-08-01_13-41-30\cm\trace\ccm\sdi
где log4 - папка, выбранная как Dowload File Directory

Анализ

Файл лога будет выглядеть следующим образом:
voprosy_pravilnogo_postroeniya_dialplana_dialplan_v_krupnoy_organizacii_trace_file_example_ciscomaster.ru.jpg

В "голом" виде его анализировать может быть затруднительно, и можно использовать дополнительные инструменты, например Triple Combo Parser или Voice Log Translator tool.
Подробнее см. Логирование и трекинг (trace) звонков в CUCM

Подробнее по Tracing см. TVOICE v.8, Tracing Inbound Globalized Call Setup, стр. 3-208

Комментарии

Спасибо за труд, полезная статья

Не совсем понял про Localized Call Egress at Phones. Не могли бы привести пример как из номера 4951112222 показать на дисплее номер 1112222. Спасибо!

Добрый день, что конкретно не понятно?
Calling-party transformations patterns на телефонах работает совершенно аналогично как и на шлюзах, только применение идет на телефон.

Добрый день, появился один вопрос, есть основной офис, есть филиал, для выхода в городскую сеть филиала создан роут паттерн вида 984212.XXXXXX с partition привязанной к шлюзу филиала. Все здорово работает пока работает, но когда отваливается связь до филиала звонок продолжает обрабатываться этим паттерном, несмотря на то что шлюз не зарегестрирван. Как нибудь можно отслеживать состояние шлюза привязанного к паттерну и делать его неактивным чтобы звонок маршрутизировался по более общему паттерну и выходил через шлюз основного офиса?
Спасибо!

Добрый день,
привязывайте Route Pattern не к шлюзу а к Route List.
Подробнее см. http://ciscomaster.ru/content/setup-call-manager-cucm-from-scratch-part-...

Буду оформлять подписку )) ну я опустил промежуточные звенья, так и есть, привязка идет к роут листу, тот в свою очередь на роут группу в которой уже линии шлюза

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Допустимые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image