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

Mulisite Dial Plan

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

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

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

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

DID или Direct inward dialing - услуга, оказываемая некоторыми телефонными провайдерами, которая позволяет осуществить соединение на внутренние абоненты без использования IVR, автоответчика или секретаря.
Посмотрим как это выглядит на следующем примере:

Здесь приём звонков в главном офисе происходит через 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) запрещен на уровне законодательства (Не Россия).

Различные 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:

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

Итак, при использовании 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

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

• 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 для Тюмени будет выглядеть:
  
  В результате Incoming Calling Party Number будет нормализован (Глобализован)

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

На рисунке первые 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.

Как видно из рисунка при применении 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.

Предположим что пользователь в Тюменском центральном офисе набрал номер телефона 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
    
  • Выставляем параметры примерно как на скриншоте (выбрать можно и больше опций). Убедитесь что выставлены "Trace on", Debug trace level - Detailed, H245, H225
    

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

    Если мы хотим траблшутить 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

- В окне Сollect files выбираем Cisco CallManager service
- В следующем окне выбираем все сервисы
- Выбираем Time range, а также директорию куда кидать файлы. Зиповать не надо.
- Запускаем сбор логов

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

Анализ

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

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

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