Cucm настройка external phone mask для провайдера

Обновлено: 05.07.2024

Сводка: Настройка CUCM для работы с Skype для бизнеса Server.

Эта возможность тестирована с помощью Cisco Unified Communications Manager (CallManager или CUCM) версии 10.5 с помощью установки магистралей только через TCP. Убедитесь, что среда CUCM соответствует этим критериям перед началом работы.

Описанные здесь параметры предназначены только в качестве примеров настройки CUCM для работы с VIS. Для достижения такого же результата также можно использовать другие параметры и/или использование альтернативных функций CUCM. Рекомендации относительно оптимальной конфигурации для определенного сценария не подразумеваются.

Для связи с VIS необходимо подтвердить или изменить ряд параметров CUCM. Выполните ниже процедуры, чтобы не пропустить необходимые параметры.

Настройка CUCM

Войдите в систему CUCM и перейдите в Cisco Unified CM Administration - > Call Routing- > Class of > Control-Partition.

На экране Конфигурация раздела введите имя и описание раздела и нажмите кнопку Добавить новые.

Перейдите к единому администрированию CM Cisco — маршрутику вызовов — класс пространства поиска по вызову > > > управления.

Перейдите в профиль безопасности магистральных магистральных магистрали Cisco Unified CM > > Administration-System-Security-SIP. >

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

Перейдите к единому cm-администрированию Cisco — > > > Параметры-SIP-профиле.

На экране конфигурации профилей SIP установите параметры сведений о профиле SIP, как показано.

На том же экране прокрутите вниз далее. В рамках специальной конфигурации магистрали профиля SIP выберите поддержку раннего предложения для голосовых и видеозвонков и установите ее в обязательный (при необходимости) параметр MTP. Это позволит CUCM настроить исходяющий вызов SIP с ранним предложением. Одна из новых функций в CUCM 8.5 и далее в том, что она поддерживает установку исходяющих вызовов с ранним предложением без необходимости точки прерывания мультимедиа (MTP).

Убедитесь, что в разделе PING Параметры SIP поле проверяется рядом с разделом "Включить параметры Ping для мониторинга состояния назначения для магистральных магистрали с помощью типа службы "Нет (по умолчанию)".

Когда вы закончите, нажмите кнопку Добавить новые.

Перейдите к Единой службе администрирования cm > Cisco- > Device-Trunk.

Установите протокол устройства для SIP и нажмите кнопку Далее.

В статье Сведения об устройстве установите имя и описание устройства (возможно, что-то SfBVideoInterop_SIPTrunk) и установите список групп медиаресумов в MRGL, содержащий нужные медиаресумы.

Прокрутите вниз. Точка прекращения мультимедиа (MTP) не требуется для видеозвонков, если она еще не снята, ото всех. Проверьте возможность запуска на всех активных узлах единой системы CM. Обратите внимание, что необходимо добавить все узлы CUCM в Skype для бизнеса Server конфигурацию.

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

Прокрутите вниз. В разделе SIP Information Destination конфигурации магистрали SIP укажите FQDN пула VIS или IP-адрес отдельных VIS-серверов в пуле (добавление нескольких записей). В порту назначения укажите порт, который VIS прослушивает для подключений из CUCM (по умолчанию — 6001). Также укажите профиль безопасности магистрали SIP и SIP-профиль, созданный ранее, как показано.

Прокрутите вниз. Установите сведения о записи, соответствующие вашей системе. Это нормально, чтобы оставить его за набором Нет.

Когда вы закончите, нажмите кнопку Добавить новые.

Перейдите к шаблону Маршрутная маршрутия и маршрут маршрутов Единой системы администрирования CM > > > Cisco.

На экране Конфигурация шаблона маршрутов введите параметры определения шаблона, показанные ниже. Прокрутите вниз в раздел "Преобразование партии" и установите маску, как показано, а затем нажмите кнопку Добавить новое по завершению.

Перейдите к шаблону маршрутного маршрута маршрутов Cisco Unified CM- > > Call Routing-SIP.

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

Если вы изменили тарифы звукового или видео бита из параметров по умолчанию, вам потребуется вернуть их по умолчанию. Чтобы установить битовую скорость для аудио- и видеозвонков, перейдите в Cisco Unified CM Administration- > System- > Region > Information-Region. По умолчанию показано ниже для справки:

На этом этапе видео шлюз CUCM настроен для работы с VIS. Соответствующая конфигурация должна быть сделана на каждом VTC, который вы хотите интегрировать.

Чтобы повысить устойчивость, может потребоваться настроить этот шлюз CUCM для работы со вторым пулом Video Interop Server или VIS. Дополнительные сведения см. в дополнительных сведениях о механизмах устойчивости.

Всех с прошедшими праздниками

Возможно, вопрос глупый, но всё же.

Есть CUCM с примерно 300 абонентами, которые сейчас делаю звонки в город с одного общего номера (его на шлюзовом роутере CUCME подставляет). А вот из города этим абонентам звонят примерно на 50 имеющихся городских номеров. Эти городские номера распределены на группы по 3-5 внутренних абонентов. При этом городской called number без изменений проходит через CUCME в CUCM и дальше звонки идут в соответствующие хант-группы.

Хочется простого - чтобы при звонках в город абонент в городе видел соответствующий группе городской номер звонящего и мог перезвонить на этот номер. Т.е. чтобы при звонке в город calling number подменялся не одним общим номером, а тем, который привязан к хант-группе. И хочется чтобы это происходило на CUCM.

не уверен что в Российских реалиях корректно работает (оператор может менять caller id/calling number), но на телефоне можно задать External Phone Number Mask. на FXO сделать точно не получиться, на E1 можно опробовать. после настройки External Phone Number Mask ловите calling number на CME через debug q931. не уверен что в Российских реалиях корректно работает (оператор может менять caller id/calling number), но на телефоне можно задать External Phone Number Mask. на FXO сделать точно не получиться, на E1 можно опробовать. после настройки External Phone Number Mask ловите calling number на CME через debug q931.

На CME можно и проще сделать - менять внутренний номер на внешний через translation-profile на dial-peer'е в E1. Только это неудобно админить и быстро упираешься в ограничение 100 правил в translation-rule.

В общем, вопрос в том, как это сделать именно на CUCM.

это именно про CUCM. про CME - debug q931 - для проверки, это намного быстрее чем через rtmt ловить.

это именно про CUCM. про CME - debug q931 - для проверки, это намного быстрее чем через rtmt ловить.

Прошу прощения, попутался

Вот что по этому поводу написано:

Indicate phone number (or mask) that is used to send Caller ID information when a call is placed from this line.

You can enter a maximum of 24 number, the international escape character +, and "X" characters. The Xs represent the directory number and must appear at the end of the pattern. For example, if you specify a mask of 972813XXXX, an external call from extension 1234 displays a caller ID number of 9728131234.

Setting applies only to the current device unless you check the check box at right (Update Shared Device Settings) and click the Propagate Selected button. (The check box at right displays only if other devices share this directory number.)

Если я всё правильно понял, такой метод не особо удобнее чем замена номера на CME. Получается, надо прописать внешний номер на каждый внутренний. В то время как уже есть Line Group - вот бы её как-то использовать.

напрямую Line Group не по используешь, в добавок в некоторых сценариях возможны недоразумения с внутренним отображением caller ID.

могу предложить к рассмотрению такой вариант уменьшения translation-pattern:

Дано ХХХ Line Group (Hunt Pilot) в них по YYY Lines

Задача сократить transformation-rules до XXX

Создаём XXX Partions/CSS ( line_to_external_121_PT/line_to_external_121_CSS)

на CUCM делаем Calling Party Transformation Pattern ( Call Routing ) в количестве XXX и заносим их в соответствующие партиции. Для упращения используем конструкцию Pattern=! Calling Party Trans Mask=LineGroup_DN ( вернее соответствующийHuntPilot_DN)

PS: внутренние абоненты будут видеть не номер телефона, а номер после трансформации.

PS: внутренние абоненты будут видет не сам номер телефона, а номер после трансформации.

Далее на телефонах принадлежащих Line Group XXX ( допустим 121 ) через Bulk выставляем Calling Party Transformation CSS на соответсвующий line_to_external_121_CSS

В итоге - CME должен прилететь номер LineGroup(HuntPilot_DN) , а не внутренний номер телефона. Далее translation-rule (уже по количеству XXX, а не общему YYY).

Хм, изменения в предыдущем посте не сохраняются.

Можно упростить,на самом HuntPilot есть Calling Party Transformations:
Включаем Use Calling Party`s External Phone Number Mask
в Calling Party Transform Mask рисуем желаемый номер
Save (работоспособность не проверял)

Хм, изменения в предыдущем посте не сохраняются.

Можно упростить,на самом HuntPilot есть Calling Party Transformations:
Включаем Use Calling Party`s External Phone Number Mask
в Calling Party Transform Mask рисуем желаемый номер
Save (работоспособность не проверял)

Попробовал - не работает к сожалению.
Сейчас подумалось - а почему дожно было сработать? HuntPilot ведь для входящих вызовов, а не для исходящих.

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

Hunt Pilot Configuration
Use Calling Party's External Phone Number Mask - Check the check box if you want the full, external phone number to be used for calling line identification (CLID) on outgoing calls. You may also configure an External Phone Number Mask on all phone devices.

подписанные в line group телефоны, могут использовать Calling Party`s Ext number mask при исходящих вызовах, настроенная на телефонах External Phone Number будет превалировать над этим шаблоном. Честно говоря работоспособность не проверял ибо не на чем >.<. debug q931 на cme показывал не изменённый номер?

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

Hunt Pilot Configuration
Use Calling Party's External Phone Number Mask - Check the check box if you want the full, external phone number to be used for calling line identification (CLID) on outgoing calls. You may also configure an External Phone Number Mask on all phone devices.

подписанные в line group телефоны, могут использовать Calling Party`s Ext number mask при исходящих вызовах, настроенная на телефонах External Phone Number будет превалировать над этим шаблоном. Честно говоря работоспособность не проверял ибо не на чем >.<. debug q931 на cme показывал не изменённый номер?

Честно говоря, дебаг не смотрел. При звонке наружу отрабатывает pattern на замену 4-значного номера на 7-значный. И на той стороне абоненты видят общий номер, а не тот что был привязан к line-group. По идее, если бы с CUCM прилетал уже 7-значный, pattern просто не срабатывал бы.

В общем, покопался я поглубже в этой теме и сделал следующие выводы:
- настройка подмены calling number в hunt pilot касается только звонков извне на номера хант-группы
- External Phone Number Mask в настройках телефона существует только для тех случаев, когда последние цифры городского номера совпадают с цифрами внутреннего
- единственный вариант подменять calling number при звонке в город, это использование Calling Party Transformation на Route Pattern'ах.

Однако делать для каждого городского номера наборы Route Pattern'ов (у меня это выходы на город, МГ, МН, сотовые) + наборы соответствующих CSS - как-то, мягко скажем, нерационально.

Было бы очень круто иметь что-то типа Translation Pattern, но наоборот - ловить звонки не по called number, a по calling и подменять его. Пусть хотя бы при помощи маски, без использования Line group. Наверняка что-то такое есть, просто я не знаю где это искать

Унифицированные коммуникации, CUCM, IP-телефония, VoIP: изучение, настройка, применение.

среда, 22 июля 2015 г.

Автоматическая регистрация телефонов в CUCM

Ну вот и первая запись. Сначала я думал опубликовать кое-что иное, в качестве первой записи, но решил начать с простого. Можно сказать с азбуки. С буквы A.
Итак, Авторегистрация телефонов на CUCM. Тема простая и большинству, скорее всего, прекрасно известная.
Небольшая предыстория. Вчера, мой коллега получил заявку на подключение телефона новому сотруднику. Задача элементарная, каждый день несколько раз повторяемая.
У нас в компании авторегистрация на CUCM включена постоянно. Да, я знаю что Cisco не рекомендует держать ее постоянно включенной из соображений безопасности, но так уж у нас сложилось, тем более что все розетки, в которые можно воткнуть телефон находятся на закрытой территории и посторонние доступ к ним не имеют.
И вот мой коллега, достав новый телефон из коробки и включив его в сеть вместо ожидаемой надписи Your current options и номера из пула для авторегистрации увидел следующее: Registration Rejected: Security Error.
Дальше уже я полез копаться в дебагах CUCM-а. И вот в SDL-трейсах я узрел такую строчку:
AddDevice returns There are no free autoreg DN in the system free DN between 1010 and 1099.
Это значит, что процесс авторегистрации CUCM-а не смог создать новый DN в заданном диапазоне и в заданном Partition. А почему не смог? А всего лишь потому, что такие DN-ы уже есть в системе! Их можно посмотреть, зайдя в раздел Call Routing -> Directory Number.
Решение проблемы элементарно - либо в настройках авторегистрации меняем диапазон, либо просто удаляем ненужные DN-ы. Ведь авторегистрация, как правило используется для того, чтобы не вбивать MAC адрес вручную. И после автоматической регистрации телефон настраивают вручную.

Теперь вкратце о том как настраивать авторегистрацию.
1. Идем System -> Enterprise Parameters. В секции Enterprise Parameters Configuration в параметре Auto Registration Phone Protocol указываем какой протокл будет использоваться при авторегистрации. По умолчанию - SCCP.
2. Создаем Partition для авторегистрации. Теоретически можно не создавать, но так правильнее. Вообще Partitions и Calling Search Space это очень мощный механизм в CUCM.
3. Конфигурируем Device pool (если еще не сконфигурирован).
4. Идем Device -> Device Settings -> Device Defaults и тут для всех используемых типов телефонов указываем дефолтный device pool, например тот который сконфигурировали ранее.
5. Теперь в System -> Cisco Unified CM выбираем сервер на котором включим авторегистрацию. В секции Auto-registration Information указываем диапазон номеров, Partition и, при желании, External Phone Number Mask. Главное ВЫКЛЮЧАЕМ галку Auto-registration Disabled on this Cisco Unified Communications Manager. Таким образом можно настроить несколько серверов для авторегистрации. Только желательно указывать для них разные диапазоны DN.
6. В System -> Cisco Unified CM Groups, проверяем CM группы. Авторегистрация может быть включена только на одной группе! Если хотите включить на другой, то зайдите в настройки группы и отметьте пункт Auto-registration Cisco Unified Communications Manager Group.

Естественно для того чтобы авторегистрация работала, в Cisco Unified Serviceability должны быть включены все соответсвующие сервисы, т.е. как минимум Cisco Callmanager, на тех нодах, на которых авторегистрация настроена.

Вот и все. Надеюсь, эта заметка окажется полезной. Будут вопросы - пишите в комментариях.

Доброго времени!
Сегодня заметка будет посвящена настройке, которая позволит ограничить доступ в городскую телефонную сеть абонентам IP телефонии.

Сначала рассмотрим то что у нас есть, а затем что нужно сделать. Ну а после соответственно перейдем к настройке.

Итак, у нас есть на предприятии телефония, которая построена на основе CUCM 6.
Все друг другу звонят, общаются, переводят звонки и прочее, все хорошо. Но нужен доступ в ТФОП, причем некоторым нужен доступ только на городские телефоны, некоторым доступ к междугородним звонкам, а некоторым вобще не нужен доступ 🙂

Теперь нужно указать в CUCM, куда пересылать звонки которые идут в ТФОП.

После всего этого сохраняем.

Так же создаем еще один Route Pattern для межгорода, 9.8XXXXXXXXXX, сохраняем, проверяем.
Одно дело сделано :), теперь необходимо разобраться с правами доступа.
Как описывалось в начале статьи, у нас будет три группы доступа.

  1. Звонки разрешены только внутри
  2. Звонки разрешены внутри и по городу
  3. Звонки разрешены внутри, по городу, межгороду

Когда мы создавали IP телефонию, все внутренние номера у нас находились в одной партиции ( Partition ), в простом случае.

Заходим в CUCM -> Call Routing Class of Control -> Add New

Указываем имя и описание. Если для города то например так:

Тоже самое делаем для второй партиции.

Name: no-international

Description: Call to other city

Теперь нужно задать эти партиции в Route Pattern, которые мы создавали выше. Думаю в этом не возникнет проблем. (После того как вы поменяли партицию, со всех телефонов не будет доступен выход в город, межгород, пока не сделаем сл. шаги.)

После всего этого, нам необходимо сделать самое основное, это назначить права доступа конкретным телефонам, кто на что имеет доступ.

Соответсвенно кто имеет доступ только к внутренним вызовам ничего не меняется.

А для других нужно создать два CSS (Calling Search Space).

Переходим Call Routing -> Class of Control -> Calling Search Space.

Добавляем новый, называем CSS City

Должно получиться нечто такое:

Далее создаем второй CSS no-international по той же схеме. Выделяем нужные Партиции, которые будут доступны в этой CSS.

Переходим в Device -> Phone, находим нужный нам телефон, открываем его, и в поле Calling Search Space указываем нужный нам уровень доступа, например CSS City (доступ только по внутренним телефонам и в город).

Сохраняем, далаем Reset, звоним, проверяем. Теперь звонок должен проходить.

Тоже самое делаем и для других нужных телефонов.

Таким образом, с помощью Partition и CSS мы можем достаточно гибко создавать свои политики ограничения прав доступа к тем или иным видам звонков.

Это можно делать не только используя Route Pattern, но и чтоб ограничить от звонков внутренний номер, например, сделать так, чтоб обычный работяга не мог связаться с генеральным директором напрямую набрав его номер.

С эти разобрались, а что же у нас произойдет с входящими звонками?

Правильно, ничего 🙂 . Ведь для них нет никаких правил.

Для этого на порту 0/0/0 необходимо прописать:

voice-port 0/0/0

cptone RU

connection plar opx 100

Но этого не достаточно, шлюз ничего не знает о номере 100, поэтому нужно создать dial-peer:

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.0.0.21

Теперь если позвонить на городской номер, который воткнут в voice port 0/0/0, будет звонить внутренний IP телефон 100.

Может возникнуть вопрос, а если нужно чтоб переадресация шла не на один номер, а на несколько? Здесь на помощь к нам придет Hunt, где можно указать как будет распространяться звонок, широковещательно (т.е. на всех сразу), по очереди, и так далее.

Читайте также: