cm fallback service operating что это значит
Азы IP-телефонии от Cisco или знакомство с Cisco CallManager Express
Совсем недавно на нашу организацию вышел клиент, который попросил настроить IP-AТС на основе платформы Cisco 2921 и софта Cisco CallManager Express (CME). Клиентами разбрасываться не прилично в наше время, посему решили данную услугу оказать.
Взялся я за это дело не столько с целью срубить бабла для компании, сколько с целью ознакомиться как у этой самой Cisco устроена Ip-телефония, с целью саморазвития то бишь.
Ознакомился. Тема приятная; для меня как для цискаря работать гораздо удобнее нежели чем с Asterisk.
Писать про возможности CME можно много. Сегодня расскажу про самые его основы.
Попробуем решить простую задачу: есть пара телефонов — один работает по SIP, другой по SCCP, надо заставить их звонить друг на друга. Как это сделать — под катом.
Первоначальная настройка CME
Нулевым пунктом считается настройка dhcp-сервера на маршрутизаторе, так как практически все телефоны по умолчанию настроены на получение IP-адреса именно таким способом. Если кто-то подзабыл или не знал, то на Цисках это делается так:
CME#conf t
CME#(config)ip dhcp pool voicepool
CME#(config-ip-dhcp)network 192.168.101.0 255.255.255.0
CME#(config-ip-dhcp)default-router 192.168.101.1
CME#(config-ip-dhcp)option 150 ip 192.168.101.1
CME#(config-ip-dhcp)lease 0 0 30
Все настройки вроде бы очевидны. За исключением, наверное 150-ой опции. Данная опция передаёт в DHCP-настройках адрес tftp-сервера (про использование tftp-сервера в этой статье я писать не буду, но вещь это очень полезная для работы с телефонами)
По умолчанию, Cisco очень хорошо и с пониманием относится к работе протокола SCCP (в силу того, что данный протокол принадлежит самой Cisco), и не очень дружит с более распространным SIP-ом. Так, например чтобы просто разрешить звонки между SIP-телефонами, подключенными к нашей АТС необходимо сконфигурировать:
CME#conf t
CME#(config)voice service voip
CME#(config-voice)allow-connections sip to sip
Далее конфигурируем срок регистрации SIP-телефонов:
CME#conf t
CME#(config)voice service voip
CME#(config-voice)sip
CME#(config-voice-sip)registrar server expires max 3600 min 3600
Теперь необходимо создать т.н. класс кодеков — набор кодеков, которые планируется использовать:
CME#conf t
CME#(config)voice class codec 1
CME#(config-voice)codec preference 1 g711alaw
CME#(config-voice)codec preference 2 g711ulaw
CME#(config-voice)codec preference 3 g729br8
Первым будет сделана попытка использовть кодек 711alaw, если не удастся, то g711ulaw, ну и дальше интуитивно понятно.
Этих настроек будет достаточно.
Настройка для работы c SCCP
Все настройки касающиеся работы протокола SCCP происходят в разделе telephony-service. Вот необходимый нам минимум:
CME#conf t
CME#(config)telephony-service
CME#(config-telephony)max-ephones 10
CME#(config-telephony)max-dn 10
CME#(config-telephony)ip source-address 192.168.101.1 port 2000
ephone — это такая штука, которая, упрощённо говоря, символизирует собой телефон, ну то есть образ телефонного апарата в понятии CME. Параметр max-ephones отвечает, соответственно за то, какое количество SCCP-телефонов может быть зарегистрировано на данной АТС.
dn — (directory number) это такая штука, которая, упрощённо говоря, символизирует собой телефонный номер. По аналогии ясно, за что отвечает параметр max-dn.
К слову сказать, не очень правильно указывать слишком большое количество ephone и dn, ибо под каждый из этих «юнитов» CME будет выделять оперативную память при инициализации.
Плюс ко всему количество поддерживаемых ephone и dn зависит от модели платформы и версии софта.
ip source-address задаёт IP-адрес (и как следствие интерфейс) и порт, на котором будут слушаться запросы от SCCP-телефонов
Настройка CME для работы с SIP-телефонами
Все настройки касающиеся работы протокола SIP происходят в разделе voice register global. Вот необходимый нам минимум:
CME#conf t
CME#(config)voice register global
CME#(config-voice)mode cme
CME#(config-voice)source-address 192.168.101.1 port 5060
CME#(config-voice)max-dn 50
CME#(config-voice)max-pool 36
Два отличия. Первое — необходимо выполнить команду mode cme, которая как бы намекает роутеру что отныне с SIP-телефонами будет работать CME (это к тому, что с протоколом SIP у Cisco работает не только описываемый нами софт). Второе — теперь вместо ephon-ов мы будем оперировать voice-pool-ами
Регистрируем телефоны
Можно приступать к настройке нумерации и параметров регистрации телефонов.
Технология в обоих протоколах одинакова и достаточно проста — сначала создаётся dn, потом создаётся «телефон», и к телефону привязывается его номер (или несколько).
В нашем примере для авторизации телефонных аппаратов на сервере мы будем использовать их MAC-адреса. Это логично, так как на практике за определённым человеком закрепляется один и тот же телефонный аппарат и телефонный номер, а человек обычно редко перемещает своё рабочее место в офисе, а если и перемещает, то и телефончик с собой переносит.
Регистрируем SCCP-телефон
Создаём телефонный номер:
CME#conf t
CME#(config)ephone-dn 1
CME#(config-ephone-dn)number 100
CME#(config-ephone-dn)description Beauty-User
CME#(config-ephone-dn)name The Real Man
Создали телефонный номер 100, описание внутри CME — «Beauty-User», отображаемое на телефоне имя будет «The Real Man»
Создаём образ телефоного аппарата. привязываем его к MAC-адресу реального аппарата, привязываем к нему номер:
CME#conf t
CME#(config)ephone 1
CME#(config-ephone)mac-address B4A4.E328.BDEC
CME#(config-ephone)button 1:1
Привязывание телефонного аппарата (а точнее телефонной линии нашего аппарата) происходи командой button 1:1. Формат следующий — сначала набираем ключевое слово «button», потом указываем номер этой «кнопки» (первый в нашем примере), потом указываем действие, которое требуется совершить («:» — двоеточие означает, что сейчас мы привяжем к выбранной линии какой-нибудь телефонный номер) и потом параметр соответствующий действию — в нашем случае указываем телефонный номер (то есть номер настроенного заранее dn).
Вы же наверняка видели в жизни\на картинках цискофон? Видели там много всяких кнопок возле экранчика? Это и есть те самые button-ы. На самом деле, каждая из этих кнопок отвечает за свою линию. А действий над ними можно совершать много (не только привязывать к какому нибудь номеру). Но это достойно отдельной статьи.
Регистрируем SIP-телефон
directory number создаётся следующим образом:
CME#conf t
CME#(config)voice register dn 1
CME#(config-voice-register-dn)number 200
Думаю, всё понятно. Описываем далее параметры для телефона:
CME#conf t
CME#(config)voice register pool 1
CME#(config-voice-register-pool)id mac 1CDF.0F4A.152E
CME#(config-voice-register-pool)number 1 dn 1
CME#(config-voice-register-pool)voice-class codec 1
CME#(config-voice-register-pool)username test password test
Привязка к первой линии первого номера происходит командой number 1 dn 1.
Командой voice-class codec 1 определяем для телефона набор допустимых кодеков (этот набор мы описывали в начале самом).
Далее командой username\password задаём аутентифкационные данные.
Чтобы телефон зарегистрировался, необходимо зайти на его веб-морду и в настройках первой линии указать адрес сервера — 192.168.101.1 и аутентификационные данные. Сохраняем.
Перезагружаем.
…
PROFIT!
Вроде бы всё. Были описаны минимальные настройки CME чтобы на нём могли зарегистрироваться два телефона (SIP и SCCP), получив адрес через DHCP.
Источники знаний
Основной источник знаний для начала был видео-курс к CCNA Voice от Jeremy Cioara. Довольно живым языком (английским правда) рассказывается об IP-телефонии вообще и о нюансах настройки этого самого CME. Правда там ни словом не затрагивается настройка SIP-телефонов.
Очень хороший мануал, конечно, есть на cisco.com. Называется он Cisco Unified Communications Manager Express System Administration Guide. Доступен тут. Там же есть ссылка для скачивания в PDF.
В дальнейшем постараюсь рассказывать о разных нюансах настройки IP-телефонии на Cisco в общем, и о CME в частности — настройка tftp сервера для заливания прошивок на телефоны, подключение линий от ТфОП, специфика установки CME и прочие фичи.
Cisco Unified Communications Manager Express System Administrator Guide
Book Title
Cisco Unified Communications Manager Express System Administrator Guide
Chapter Title
SRST Fallback Mode
View with Adobe Reader on a variety of devices
Results
Chapter: SRST Fallback Mode
SRST Fallback Mode
Prerequisites for SRST Fallback Mode
The IP address of the Cisco Unified CME router must be registered as the SRST reference on the Cisco Unified Communications Manager device pool.
Cisco Unified CME 4.0 or a later version must be installed on the Cisco Unified CME router that is configured in SRST mode.
Following tasks must be completed:
Configure System-Level Parameters. Note that the max-dn command must be explicity configured with the preference keyword to support calls between PSTN and IP phones during SRST fallback mode.
Restrictions for SRST Fallback Mode
SRST Fallback Mode is applicable only for SCCP phones. SIP phones are not supported.
The call-manager-fallback command, which is used to configure Cisco Unified SRST, cannot be used on a router that is configured for Cisco Unified CME.
The telephony-service setup command and auto assign command must not be enabled on a Cisco Unified CME router configured for SRST fallback mode. If you used the telephony-service setup command before configuring the router for SRST fallback support, you must remove any unwanted ephone directory numbers created by the setup process.
The number of phones that fall back to a Cisco Unified CME router in SRST mode cannot exceed the maximum number of phones that is supported by the router. To find the maximum number of phones for a particular router and Cisco Unified CME version, see the appropriate Cisco CME Supported Firmware, Platforms, Memory, and Voice Products document at http://www.cisco.com/en/us/products/sw/voicesw/ps4625/products_device_support_tables_list.html.
The ephone-dns and ephones that are created from fallback may have less information associated with them than appears in their original configuration on a Cisco Unified Communications Manager or on an active Cisco Unified CME system. This situation occurs because the Cisco Unified CME router in SRST mode is designed to learn only a limited amount of information from the fallback IP phones. For example, if an ephone-dn has in its configuration the command number 4888 no-reg (to keep that extension from registering under its E.164 address), after fallback the no-reg part of this command will be lost because this information cannot be learned from the IP phones.
The order of the SRST fallback ephone-dns and ephones will be different from the order of the active Cisco Unified Communications Manager or Cisco Unified CME ephone-dns and ephones. For example, ephone 1 on an active Cisco Unified Communications Manager might be numbered ephone 5 on the Cisco Unified CME router in SRST mode, because the order of learned ephone-dns and ephones is determined by the sequence of the ephone fallback occurrence, which is random.
Information About SRST Fallback Mode
SRST Fallback Mode Using Cisco Unified CME
This feature enables routers to provide call-handling support for Cisco Unified IP phones if they lose connection to remote primary, secondary, or tertiary Cisco Unified Communications Manager installations or if the WAN connection is down. When Cisco Unified SRST functionality is provided by Cisco Unified CME, provisioning of phones is automatic and most Cisco Unified CME features are available to the phones during periods of fallback, including hunt-groups, call park and access to Cisco Unity voice messaging services using SCCP protocol. The benefit is that Cisco Unified Communications Manager users will gain access to more features during fallback without any additional licensing costs.
This feature offers a limited telephony feature set during fallback mode. Customers who require the following features should continue to use Cisco Unified SRST, because these features are not supported with SRST fallback support using Cisco Unified CME.
More than 240 phones during fallback service
Cisco VG 248 Analog Phone Gateway support
Secure voice fallback during SRST fallback service
Simple, one-time configuration for SRST fallback service
Cisco Unified Communications Manager supports Cisco Unified IP phones at remote sites attached to Cisco Integrated Services Routers across the WAN. This new feature combines the many features available in Cisco Unified CME with the ability to automatically detect IP phone configurations that is available in Cisco Unified SRST to provide seamless call handling when communication with the Cisco Unified Communications Manager is interrupted.
When the system automatically detects a failure, Cisco Unified SRST uses Simple Network Auto Provisioning (SNAP) technology to auto-configure a branch office router to provide call processing for the Cisco Unified IP phones that are registered with the router. When the WAN link or connection to the primary Cisco Unified Communications Manager is restored, call handling returns to the primary Cisco Unified Communications Manager.
A limited number of phone features are automatically detected at the time that call processing falls back to Cisco Unified CME in SRST Fallback Mode, and an advantage of SRST fallback support using Cisco Unified CME is that you can choose to prebuild a Cisco Unified CME configuration that contains a number of extensions (ephone-dns) with additional features that you want them to have for some or all of your extensions. The configurations will contain ephone-dn configurations but will not identify which phones (which MAC addresses) will be associated with which ephone-dns (extension numbers).
By copying and pasting a prebuilt configuration onto Cisco Unified CME routers at several locations, you can use the same overall configuration for sites that are identically laid out. For example, if you have a number of retail stores, each with five to ten checkout registers, you can use the same overall configuration in each store. You might use a range of extensions from 1101 to 1110. Stores with fewer than ten registers will simply not use some of the ephone-dn entries you provide in the configuration. Stores with more extensions than you have prebuilt will use the auto-provisioning feature to populate their extra phones. The only configuration variations from store to store will be the specific MAC addresses of the individual phones, which are added to the configurations at the time of fallback.
When a phone registers for SRST service with a Cisco Unified CME router and the router discovers that the phone was configured with a specific extension number, the router searches for an existing prebuilt ephone-dn with that extension number and then assigns that ephone-dn number to the phone. If there is no prebuilt ephone-dn with that extension number, the Cisco Unified CME system automatically creates one. In this way, extensions without prebuilt configurations are automatically populated with extension numbers and features as the numbers and features are “learned” by the Cisco Unified CME router in SRST mode when the phone registers to the router after a WAN link fails.
The SRST fallback support using Cisco Unified CME feature is able to interrogate phones to learn their MAC addresses and the extension-to-ephone relationships associated with each phone. This information is used to dynamically create and execute the Cisco Unified CME button command for each phone and automatically provision each phone with the extensions and features you want it to have.
The following sequence describes how Cisco Unified CME provides SRST services for Cisco Unified Communications Manager phones when they lose connectivity with the Cisco Unified Communications Manager and fall back to the Cisco Unified CME router in SRST mode:
Phones are configured as usual in Cisco Unified Communications Manager.
The IP address of the Cisco Unified CME router is registered as the SRST reference on the Cisco Unified Communications Manager device pool.
SRST mode is enabled on the Cisco Unified CME router.
(Optional) Ephone-dns and features are prebuilt on the Cisco Unified CME router.
Number of lines or buttons
The option defined with the srst mode auto-provision command determines whether Cisco Unified CME adds the learned phone and extension information to its running configuration. If the information is added, it appears in the output when you use the show running-config command and is saved to NVRAM when you use the write command.
Use the srst mode auto-provision none command to enable the Cisco Unified CME router to provide SRST fallback services for Cisco Unified Communications Manager.
If you use the srst mode auto-provision dn or srst mode auto-provision all commands, the Cisco Unified CME router includes the phone configuration it learns from Cisco Unified Communications Manager in its running configuration. If you then save the configuration, the fallback phones are treated as locally configured phones on the Cisco Unified CME-SRST router which could adversely impact the fallback behavior of those phones.
While in fallback mode, Cisco Unified IP phones periodically attempt to reestablish a connection with Cisco Unified Communications Manager every 120 seconds (default). To manually reestablish a connection to Cisco Unified Communications Manager you can reboot the Cisco Unified IP phone.
An IP phone connected to the Cisco Unified CME-SRST router over a WAN reconnects itself to Cisco Unified Communications Manager as soon as it can establish a connection to Cisco Unified Communications Manager over the WAN link. However, if the WAN link is unstable, the IP phone switches back and forth between Cisco Unified CME-SRST and Cisco Unified Communications Manager, causing temporary loss of phone service (no dial tone). These reconnect attempts, known as WAN link flapping issues, continue until the IP phone successfully reconnects itself back to Cisco Unified Communications Manager.
WAN link disruptions can be classified into two types: infrequent random outages that occur on an otherwise stable WAN, and sporadic, frequent disruptions that last a few minutes.
To resolve WAN-link flapping issues between Cisco Unified Communications Manager and SRST, Cisco Unified Communications Manager provides an enterprise parameter and a setting in the Device Pool Configuration window called Connection Monitor Duration. (Depending on system requirements, the administrator decides which parameter to use.) The value of the parameter is delivered to the IP phone in the XML configuration file.
Use the enterprise parameter to change the connection duration monitor value for all IP phones in the Cisco Unified Communications Manager cluster. The default for the enterprise parameter is 120 seconds.
Use the Device Pool Configuration window to change the connection duration monitor value for all IP phones in a specific device pool.
A Cisco Unified IP phone will not reestablish a connection with the primary Cisco Unified Communications Manager at the central office if it is engaged in an active call.
After the First Fallback
Additional features can be set up, such as ephone hunt groups, which can contain learned extensions and prebuilt extensions. The complete core set of Cisco Unified CME phone features is available to the IP phones and extensions, whether they are learned or configured.
Figure 51-1 shows a branch office with several Cisco Unified IP phones connected to a Cisco Unified CME router in SRST fallback mode. The router provides connections to both a WAN link and the PSTN. The Cisco Unified IP phones connect to their primary Cisco Unified Communications Manager at the central office via this WAN link. Cisco Unified CME provides SRST services for the phones when connectivity over the WAN link is interrupted.
Figure 1. SRST Fallback Support using Cisco Unified CME 
Prebuilding Cisco Unified CME Phone Configurations
Prebuilding Cisco Unified CME ephone-dns allows you to create a set of directory numbers with extension numbers and some features, which will provide service during fallback that is similar to the service that is provided during normal operation. You can prebuild all of your normal extensions, a limited set of your extensions, or none of your extensions. Directory numbers that are not prebuilt will be populated with extension numbers and features as they are “learned” by the Cisco Unified CME router in SRST mode at the time of fallback.
An ephone-dn is the IP equivalent of a normal phone line in most cases. It represents a potential call connection and is associated with a virtual voice port and virtual dial peer. An ephone-dn has one or more extension or telephone numbers associated with it, which allow call connections to be made. An ephone-dn can be single-line, which allows one call connection to be made at a time, or dual-line, which allows two simultaneous call connections. Dual-line ephone-dns are useful for features such as call transfer or call waiting, in which one call is put on hold to connect to another. Single-line ephone-dns are required for certain features such as intercom, paging, and message-waiting indication (MWI). For more information, see Cisco Unified CME Overview.
If an ephone-dn is manually configured in Cisco Unified CME, incoming calls will always route to the manually configured ephone-dn in Cisco Unified CME rather than to Cisco Unified Communications Manager using the voip dial peer. To avoid incorrect routing, configure a higher preference for the voip dial peer than the preference for the prebuilt directory number. For configuration example, see Example for Prebuilding DNs.
Auto provision Directory Numbers in SRST Fallback Mode
Cisco Unified CME 4.3 and later versions support octo-line directory numbers in SRST fallback mode. You can specify whether Cisco Unified CME in SRST fallback mode creates octo-line or dual-line directory numbers based on the phone type. For the Cisco Unified IP Phone 7902 or 7920, or an analog phone connected to the Cisco VG224 or Cisco ATA, the system creates a dual-line directory number; it creates an octo-line directory number for all other phone types. This applies only to the ephone-dns that are “learned” automatically from ephone configuration information, and not to ephone-dns that are manually configured in Cisco Unified CME.
Cisco ISR and SRST fallback mode
Введение
SRST (Survivable Remote Site Telephony) – функционал маршрутизатора, позволяющий обеспечивать сервис телефонии для IP телефонов в случае отсутствия связи с центральным сервером. Наиболее типичный сценарий применения – это филиал или удаленный офис компании, в котором сервис телефонии обеспечивается центральным сервером CUCM (Cisco Unified Communication Manager). В случае отсутствия WAN канала до центрального офиса, где расположен сервер CUCM, а так же в иных случаях потери связи с серверами CUCM, маршрутизатор может предоставить базовый сервис для IP телефонов. Таким образом, звонки внутри удаленного офиса и выход в городскую сеть связи (если шлюз находится на этой же площадке) будут работать. Система автоматически обнаруживает пропажу связи, а после ее восстановления передает сервис обратно, с маршрутизатора на CUCM.
Когда связь с CUCM теряется, телефон должен установить связь с SRST маршрутизатором. Для IP телефона шлюз по умолчанию в сетевых настройках указывает на адрес маршрутизатора в режиме SRST. Возможность телефона получить временный сервис Cisco Unified CM fallback зависит от его модели. Те телефоны, которые не поддерживаются маршрутизатором, потеряют сервис.
В настройках по умолчанию, телефон 3 раза с интервалом в 30 секунд ждет ответ от сервера CUCM, прежде чем считать, что он не доступен. Если телефон имеет standby connection с маршрутизатором SRST, то процесс перерегистрации занимает 10-20 секунд после принятия решения о том, что CUCM не доступен.
В том случае, если IP телефон имеет множество серверов CUCM в перечне Unified Communications Manager list, то процесс идет в соответствие со списком, ожидается ответ от первого сервера до последнего, и уже только потом телефон регистрируется на локальном маршрутизаторе. Таким образом, прерывание связи может длиться несколько минут. Более того, каждая модель телефона характеризуется своим временем на перерегистрацию, которое может быть от 10 секунд до 2.5 минут. Телефон, зарегистрированный на SRST маршрутизаторе делаем попытки связаться с CUCM каждые 120 секунд, это время может быть изменено. После возобновления связи телефон автоматически перерегистрируется на CUCM сервере.
Cisco Unified SRST поддерживает следующие возможности звонков:
• SCCP phone to SCCP phone
• SCCP phone to PSTN/router voice-port
• SCCP phone to WAN VoIP using SIP or H.323
• SIP phone to SIP phone
• SIP phone to PSTN / router voice-port
• SIP phone to SCCP phone
• SIP phone to WAN VoIP using SIP
На рисунке ниже показан типичный пример инсталляции SRST маршрутизатора:
Рис. 1 Схема включения маршрутизатора Cisco Unified SRST
Настройка сети
Когда пропадает WAN канал, Cisco Unified IP телефон определяет, что он больше не получает keepalive пакеты от CUCM. Затем, телефон регистрируется на локальном маршрутизаторе. В это время на маршрутизаторе автоматически активируется программное обеспечение Cisco Unified SRST и создается локальная база подключенных телефонов (не больше настроенного максимума). В качестве DHCP сервера рекомендуется использовать локальный маршрутизатор Cisco Unified SRST.
Настройка CUCM
IP телефон должен знать информацию об альтернативном сервере для регистрации, когда потеряет связь с CUCM. Для этого в CUCM следует настроить следующим образом.
Из меню Cisco Unified CMAdministration выбрать меню System > SRST > Add New, указать IP адрес маршрутизатора и по желанию изменить номер порта (по умолчанию 5060).
Рис. 2 Добавление SRST маршрутизатора в CUCM
Ссылка на SRST маршрутизатор ассоциируется с IP телефоном, используя Device Pool. Так, в меню System > Device Pool в требуемом пуле можно выбрать SRST маршрутизатор из списка заданных:
Рис. 3 Добавление SRST в Device Pool
Теория настройки SRST маршрутизатора в Cisco IOS
#call-manager-fallback – активация SRST
#max-conferences max-conference-numbers – устанавливает максимальное количество three-party разговоров
#ip source-address ip-address [port port] – команда задает IP адреса и порта, куда будет привязан сервис SRST, телефон и маршрутизатор будут общаться именно через этот адрес. Данная команда обязательна для запуска SRST. Дополнительные параметры “any-match” и “strict-match” определяют принимать ли запросы IP телефонов с любых IP адресов или только от явно заданных соответственно.
#max dn max-directory-numbers [dual-line] [preference preference-order] – команда задает максимальное количество номеров DNs (directory numbers) или виртуальных голосовых порта, а так же активация режима dual-line. В добавок есть опциональная команда preference – задает приоритет для созданных для VoIP dial peers для всех DN, значения в диапазоне от 0 о 10, наименьшее имеет высший приоритет, по умолчанию значение preference равняется нулю.
#max-ephones max-phones – команда задает максимальное количество цифровых телефонов.
#limit-dn <7945 | 7960>max-lines – определение максимального числа линий у телефона
#keepalivae seconds – команда задает интервал, с которым IP телефон будет отправлять keepalive сообщения маршрутизатору. По умолчанию, 30 секунд.
#dialplan-pattern tag pattern extension-length length [extension-pattern extension-pattern] [no-reg] – определяет нумерационный план, задает глобальный префикс, который может быть использован для исходящих и исходящих вызовов. Здесь tag – индивидуальный идентификатор, может иметь значение от 0 до 5. Параметр pattern – выражение, задающее код зоны, префикс, первые одну или две цифры расширения, а так же wildcard маску для номера. Параметр extension-length определяет количество символов справа от номера, которое будет использоваться в caller ID. Параметр extension-pattern задает dial-plan, который будет сопоставляться с pattern.
#translation-profile
#cor
#alias tag number-patternto alternate-number [ preference preference-value ] [ cfw number timeout timeout-value ] [ huntstop ] – команда определяет набор правил для переадресации вызовов в режиме SRST fallback. Здесь tag – идентификатор переадресации, значение от 1 до 50. Значения number-pattern и alternate-number – откуда и куда осуществлять переадресацию. Опциональная команда preference задает приоритет команды, от 0 до 10. Опциональная команда cfw позволяет сделать переадресацию для случая no answer и call forward busy, параметрtimeout задает время в секундах, через которое сработает переадресация в случае no answer.
#timeouts interdigit seconds – задает интервал времени в секундах, сколько телефон, зарегистрированный на маршрутизаторе в режиме SRST будет ждать набора каждой последующей цифры.
Практика настройки SRST маршрутизатора в Cisco IOS
Рассмотрим полную настройку маршрутизатора для работы в режиме SRST fallback, расположенного в удаленном офисе компании.
Рассмотрим типовой сценарий подключения маршрутизатора ISR в филиале компании, где есть WAN канал с центральным офисом, где расположен CUCM, а так же провайдер городских линий по SIP.
enable secret Pa$$word
username admin privilege 15 secret Pa$$word
aaa authentication login default local
no ip domain-lookup
crypto key generate rsa #сгенерировать ключ длиной не менее 1024
clock timezone MSK 4 0
transport input telnet ssh
transport output telnet ssh
no access-class 23 in #если маршрутизатор новый, из коробки
transport input telnet ssh
transport output telnet ssh
no access-class 23 in #если маршрутизатор новый, из коробки
! убрать следующее, если маршрутизатор новый
no ip dhcp excluded-address 10.10.10.1
no ip dhcp pool ccp-pool
ip address 10.0.1.254 255.255.255.0
ip address 192.168.1.1 255.255.255.0
ip dhcp excluded-address 10.0.1.1 10.0.1.10
ip dhcp excluded-address 10.0.1.254
ip dhcp pool IP_Phone
network 10.0.1.0 255.255.255.0
option 150 ip 10.0.0.1 10.0.0.2
dns-server 10.0.0.3 10.0.0.4
ip helper-address 10.0.0.5 #в том случае, если используется внешний DHCP сервер, указывается куда перенаправлять DHCP запросы
voice service voip
ip address trusted list
ipv4 10.0.1.0 255.255.255.0 #внутренняя сеть VoIP предприятия
ipv4 192.168.1.254 255.255.254.254 #SIP сервер провайдера
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
registrar server expires max 300 min 60
no call service stop
voice class codec 1
codec preference 1 g711alaw #задаем список кодеков с приоритетом
!Задаем COR (class of restriction) листы
dial-peer cor custom
dial-peer cor list Internal
dial-peer cor list City
dial-peer cor list Moible
! настройка translation-rule для звонков в город «через девятку»
voice translation-rule 1
voice translation-profile OutCall
translate calling 1
timeouts interdigit 4
ip source-address 10.0.1.254 port 2000
max-dn 500 dual-line
Если на удаленном сайте свой префикс, 555, то для звонков внутри маршрутизатора нужно указать префикс, а так же длину локального номера:
dialplan-pattern 1 555…. extension-length 4
Безусловная переадресация вызова с 5551001 номера на 5551002
alias 1 5551001 to 5551002
Безусловная переадресация вызова с диапазона номеров 5551100-5551199 номера на 5551002
alias 1 55511.. to 5551002
Переадресация в случае если занятости абонента или недоступности, а так же после 12 секунд «длинного гудка» выглядит так:
alias 2 5551002 to 5551002 preference 1 cfw 5551003 timeout 12
В примере ниже звонок на 5551000 будет «охотиться» на номера 1005, 1006, 1007 соответственно:
alias 3 5551000 to 5551005 cfw 5551000 timeout 12
alias 4 5551000 to 5551006 cfw 5551000 timeout 12
alias 5 5551000 to 5551007 cfw 5551000 timeout 12
Настройка доступа абонентов:
cor incoming Internal 1 5551000 – 5551099
cor incoming City 1 5551100 – 5551199
cor incoming Mobile 1 5551200 – 5551299
Пример применения COR листа на dial-peer
dial-peer voice 10 voip
corlist outgoing City
translation-profile outgoing OutCall
session protocol sipv2
session target ipv4:192.168.1.1:5060
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
clid network-number 7777777
dial-peer voice 20 voip
corlist outgoing Mobile
translation-profile outgoing OutCall
session protocol sipv2
session target ipv4:192.168.1.1:5060
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
clid network-number 7777777
При обрыве связи с CUCM регистрация SCCP телефонов произойдет в автоматическом режиме, а для регистрации SIP телефонов необходимо создать список из voice register pool. В этих примерах регистрируется каждый телефон в отдельности:
voice register global
timeouts interdigit 4
voice register pool 1
id network 10.0.1.0 mask 255.255.255.0
cor incoming City default
voice-class codec 1
voice register pool 2
id network 10.0.1.0 mask 255.255.255.0
cor incoming Mobile default
voice-class codec 1
В этом примере разрешается регистрация сразу нескольких телефонов по маске, а именно с 5551100 до 5551199:
voice register pool 3
id network 10.0.1.0 mask 255.255.255.0
cor incoming Internal default
voice-class codec 1
Troubleshooting
Существует масса команд для поиска неисправностей, приведу лишь главные и наиболее часто применяемые из них:
#show call-manager-fallback all – Выводит детальную информацию по всей настройке телефонии в SRST маршрутизаторе
#debug ephone register – При обрыве связи с CUCM (обрыв канала WAN и пр.) позволит наблюдать как телефоны перерегистрируются с CUCM на маршрутизатор
Aug 13 16:13:50: VOICE REGISTER POOL-1 has registered. Name: IP:10.0.1.20 DeviceType:Phone
Aug 13 16:13:51: VOICE REGISTER POOL-2 has registered. Name: IP:10.0.1.21 DeviceType:Phone
%IPPHONE-6-REGISTER_NEW: ephone-25:ANF70D02EA3D402 IP:10.0.1.23 Socket:56 DeviceType:Phone has registered.
#show voice register all – Покажет список всех voice register pool (для SIP телефонов) с подробной информацией:
Network address is 10.0.1.0, Mask is 255.255.255.0
Number list 1 : Pattern is 5551112
Proxy Ip address is 0.0.0.0
Class of Restriction List Tag: default
Incoming corlist name is Mobile
DTMF Relay is enabled, rtp-nte
kpml signal is enabled
Lpcor Type is none
paging-dn: config 0 [multicast] effective 0 [multicast]
Dial-peers for Pool 1:
dial-peer voice 40035 voip
corlist incoming Mobile
session target ipv4: 10.0.1.112:15061
session protocol sipv2
digit collect kpml
voice-class codec 1
Active registrations : 1
Total SIP phones registered: 1
Total Registration Statistics
Registration requests : 4
Registration success : 4
Registration failed : 0
unRegister requests : 3
unRegister success : 3
unRegister failed : 0
Attempts to register
after last unregister : 0
Last register request time : 16:14:40.572 MSK Wed Aug 13 2014
Last unregister request time : 10:36:41.196 MSK Tue Aug 12 2014
Register success time : 16:14:40.572 MSK Wed Aug 13 2014
Unregister success time : 10:36:41.196 MSK Tue Aug 12 2014