Использование аппаратных медиа-ресурсов для CUCME

В авторизованных курсах Cisco достаточно подробно говорится о работе медиа-ресурсов с "большим" колменеджером (CUCM), но не рассказывается, как их использовать с CUCME (Cisco Unified Communication Manager Express). Восполним упущение вендора и осветим данную тему более подробно.

Медиа-ресурсами в терминологии Cisco называются аппаратные (hardware) или программные (software) средства, которые производят определенную обработку голосовых потоков / сессий. К операциям обработки голосовых потоков относятся:

• Voice Termination - преобразование "традиционных" (т.е аналоговых или цифровых) речевых сигналов в IP-пакеты;
• Conferencing - объединение (мультиплексирование) нескольких голосовых потоков в конференцию, т.е разговор нескольких абонентов одновременно;
• Transcoding - преобразование кодека, использующего в голосовой сесиии одним устройством, в кодек, который может использоваться другим устройством.
• Media Termination Point (MTP) - соединение ("бриджевание") двух голосовых сессий между собой, например, в случаях, когда в сессии использован один и тот же кодек, но разные интервалы пакетирования или законы компандирования.
• Music on Hold - проигрывание музыки при постановки одного из абонентов на удержание
• Announciator - проигрывание речевых сообщений или акустических сигналов в различных ситуациях, например при наборе несуществующего номера и т.п.

Некоторые операции обработки голосовых потоков могут быть осуществлены только на аппаратных средствах (Voice Termination, Transcoding), а другие - только на программных средствах (Music on Hold, Announciator). Conferencing и MTP могут быть реализованы и на аппаратных, и на программных ресурсах. Использование аппаратных средств предпочтительнее, так как програмные ресурсы увеличивают вычислительную нагрузку на процессоры серверов и голосовых шлюзов. В большинстве случаев в качестве аппаратных средств используются DSP (Digital Signal Proccessor) голосовых шлюзов. Для работы в качестве транскодера, конференц-моста или MTP DSP микросхемы объединяются в конструкцию, которая называется dspfarm (дословно: DSP-ферма). Обязательным условием является регистрация dspfarm на колменеджере. Для управления медиа-ресурсами колменеджер использует протокол сигнализации SCCP.

Программирование медиа-ресурсов для работы с CUCME рассмотрим на примере конференц-моста и транскодера. Чтобы использовать DSP для транскодирования или конференции, необходимо выполнить следующие действия (привожу пример конфигурации роутера Cisco 2811 с функционалом CUCME, пояснения даны курсивом; значения совпадающих параметров выделены одинаковым цветом):

voice-card 0 - номер слота, в котором расположены платы с микросхемами DSP 

dsp services dspfarm - включается конструкция dspfarm для DSP в слоте 0

!

!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/0.124 - подинтерфейс для голосового VLAN

 description BR-2 Phones
 encapsulation dot1Q 124
 ip address 10.2.4.102 255.255.255.0
!

interface FastEthernet0/0.125 - подинтерфейс VLAN для передачи данных  

 description BR-2 Data

 encapsulation dot1Q 125
 ip address 10.2.5.102 255.255.255.0
!

interface Loopback 0

description For_CUCME

ip address 10.2.250.102 255.255.255.0

!
!
sccp local FastEthernet0/0.124 - указываем локальный интерфейс для сигнализации SCCP 
sccp ccm 10.2.250.102 identifier 1 version 7.0 - указываем IP-адрес CUCME, на котором будут регистрироваться медиа-ресурсы, его идентификатор и версию ПО
sccp - включаем сигнализацию SCCP
!

sccp ccm group 1 - задается группа колменеджеров, на которых будет осуществлена регистрация  

associate ccm 1 priority 1 - задается приоритет серверов в группе для последовательности регистрации 

associate profile 2 register Transcoder - указывается имя, под которым будет регистрироваться транскодер 

associate profile 1 register HW_CFB - указывается имя, под которым будет регистрироваться конференц-мост

!

dspfarm profile 2 transcode - создается профиль для транскодера 

 codec g711ulaw - перечисляются кодеки, которые могут использованы с транскодером 

 codec g711alaw

 codec g729ar8
 codec g729abr8
 codec g729r8

 maximum sessions 2 - максимальное количество сессий транскодирования 

 associate application SCCP - активируется протокол SCCP для данного профиля 

 no shutdown - включается транскодер
!

dspfarm profile 1 conference - создается профиль для конференции 

 codec g711ulaw - перечисляются кодеки, которые могут использованы при объединении сессий в конференцию 

 codec g711alaw

 codec g729ar8
 codec g729abr8
 codec g729r8
 codec g729br8

 maximum sessions 2 - максимальное количество конференц-сессий 

 associate application SCCP - активируется протокол SCCP для данного профиля 

 no shutdown - включается конференц-мост
!

!
telephony-service - настройки CUCME

 conference hardware - разрешить использование аппаратных ресурсов для конференции 

 sdspfarm units 2 - количество используемых профилей 

 sdspfarm tag 1 HW_CFB - имя конференц-моста (должно совпадать с именем профиля) 

 sdspfarm tag 2 Transcoder - имя транскодера (должно совпадать с именем профиля) 

 max-ephones 10

 max-dn 10
 ip source-address 10.2.250.102 port 2000 - IP адрес CUCME

При конфигурировании профилей dspfarm может возникнуть ситуация, когда система не даст Вам возможности ввести требуемое количество сессий (maximum sessions). Это свидетельствует о нехватке DSP ресурсов. Нужно либо добавлять платы с микросхемами DSP, либо сокращать количество портов традиционной телефонии (аналоговые телефоны, тайм-слоты потоков Е1).

После конфигурирования проверяем регистрацию медиа-ресурсов:

BR-2#sh dspfarm profile 1
Dspfarm Profile Configuration

 Profile ID = 1, Service = CONFERENCING, Resource ID = 1
 Profile Description :
 Profile Service Mode : Non Secure
 Profile Admin State : UP Profile Operation State : ACTIVE Application : SCCP   Status : ASSOCIATED Resource Provider : FLEX_DSPRM   Status : UP
 Number of Resource Configured : 2
 Number of Resource Available : 2
 Codec Configuration
 Codec : g711ulaw, Maximum Packetization Period : 30 , Transcoder: Not Required
 Codec : g711alaw, Maximum Packetization Period : 30 , Transcoder: Not Required
 Codec : g729ar8, Maximum Packetization Period : 60 , Transcoder: Not Required
 Codec : g729abr8, Maximum Packetization Period : 60 , Transcoder: Not Required
 Codec : g729r8, Maximum Packetization Period : 60 , Transcoder: Not Required
 Codec : g729br8, Maximum Packetization Period : 60 , Transcoder: Not Required

BR-2#sh dspfarm profile 2
Dspfarm Profile Configuration

 Profile ID = 2, Service = TRANSCODING, Resource ID = 2
 Profile Description :
 Profile Service Mode : Non Secure
 Profile Admin State : UP Profile Operation State : ACTIVE Application : SCCP   Status : ASSOCIATED Resource Provider : FLEX_DSPRM   Status : UP
 Number of Resource Configured : 1
 Number of Resource Available : 1
 Codec Configuration
 Codec : g711ulaw, Maximum Packetization Period : 30
 Codec : g711alaw, Maximum Packetization Period : 30
 Codec : g729ar8, Maximum Packetization Period : 60
 Codec : g729abr8, Maximum Packetization Period : 60
 Codec : g729r8, Maximum Packetization Period : 60

Из приведенных выше данных видно, что наши аппаратные медиа-ресурсы успешно зарегистрированы на CUCME и готовы к использованию (Operation State: ACTIVE, SCCP Status: ASSOSIATED). Иногда не удается сразу получить регистрацию аппаратных ресурсов, в этом случае спасает реинициализация протокола SCCP:

BR-2#(Config) no sccp

BR-2#(Config) sccp

CUBE High Availability с использованием HSRP

CUBE High Availability с использованием HSRP

         Допустим,  у вас есть необходимость подключить свой кластер CUCM к провайдеру телефонных услуг с помощью SIP-транка. Как известно, для этого нам необходим IP-IP шлюз - Cisco Unified Border Element (CUBE). Да еще не просто подключить, а обеспечить высоко доступность данного подключения с использованием box-to-box избыточности. Что человеческим языком означает: есть 2 CUBE (один основной, второй резервный), 1 SIP провайдер – нужно сделать так, чтоб во время нормальной работы сети все звонки выходили через основной CUBE, а в случае его сбоя (или его интерфейсов) – через резервный. Все это должно происходить автоматически и с сохранением текущих активных звонков.

         Решить данную задачу мы можем с использованием Hot Standby Routing Protocol (HSRP).

         Что необходимо:

1.    Два идентичных Cisco ISR G2s c лицензией UC Technology Package (SL-29-UC-K9 or SL-39-UC-K9), 1GDRAM памяти и Cisco IOS Software release 15.1.2T или позже.

     Cisco IOS Software release 15.1.2T поддерживает сохранение активных SIP-SIP звонков во время HSRP switchover, но не поддерживает сохранение сигнализации. Поддержка сохранения сигнализации появилась в Cisco IOS Software release 15.2.3T.

2.    Оба маршрутизатора физически должны быть расположены в одной Ethernet LAN.

3.    Конфигурация функционала CUBE должна быть идентична на обоих маршрутизаторах.

4.    Один маршрутизатор явно должен быть определен как HSRP Active, второй – как HSRP Standby

         

         Для реализации CUBE box-to-box избыточности, как уже было указано, необходимо два идентичных CiscoISR G2: один определяется как активный, второй как резервный. HSRP настраивается на физических или субинтерфейсах маршрутизаторов, формируя HSRP группу.

         В случае выхода из строя активного маршрутизатора, резервный берет на себя все его обязанности, в том числе продолжает пересылать те же RTP пакеты, маршрутизацией которых занимался активный маршрутизатор до сбоя.
         В чистом виде протокол HSRP занимается мониторингом интерфейсов, а вот мониторингом сессий занимается Statefull Switchover (SSO), именно эта технология позволяет активному и резервному маршрутизаторам обмениваться информацией о сессиях. Это и дает возможность сохранять передачу медиа потока активного звонка во время HSRP switchover. Звонки же, которые находятся в переходном состоянии (еще не установлены или в процессе изменения за счет использования функций hold, transfer и т.п. ) во время failover обрываются. Так же терпят неудачу звонки, которые используют ресурсы DSP (транскодирование, например).

Схема нашего подключения выглядит так:

         Ну что же, поехали!

         Считаем, что функционал CUBE и маршрутизация звонков уже настроено. Минимально необходимые команды для запуска CUBE и разрешения SIP-to-SIP звонков:

voice service voip

 mode border-element

 allow-connections sip to sip

Полное руководство по конфигурации CUBE здесь  
       
         Первое, что нужно сделать – это настроить HSRP.
         Исходя из нашей схемы, у нас будет 2 HSRP группы. В первую группу, возьмем для нее номер 0, будут входить внешние интерфейсы маршрутизаторов (GigabitEthernet0/0 на обоих), а во вторую (под номером 1) – внутренние (GigabitEthernet0/1 на обоих). Эти группы независимы друг от друга, то есть маршрутизатор может быть одновременно активным в одной и резервным в другой группе.
         Тогда решаем, кто и где будет главным. Здесь нужно помнить, что активный маршрутизатор занимается пересылкой трафика и отвечает на запросы, отправленные на виртуальный HSRP IP адрес. Резервный только слушает и мониторит работоспособность активного. Исходя из этого, для корректной маршрутизации наших звонков, один маршрутизатор должен быть активным в обоих HSRP группах.
         Выбираем главным CUBE-1, с него и начинаем

CUBE-1:

   interface GigabitEthernet0/1 – наш внутренний интерфейс
     ip address 10.10.24.14 255.255.255.0
     standby version 2
     standby 1 ip 10.10.24.1
     !Активируем HSRP, задаем номер HSRP группы 1 и виртуальный IP адрес.
     После этих команд HSRP уже включился и начал отправлять hello пакеты на поиски других участников группы и для участия в выборах. Вспоминаем, что на выборах побеждает участник с большим приоритетом. Хм, но приоритет мы не задавали. Но он есть, правда у все одинаковый – 100. В таком случае побеждает маршрутизатор с большим IP адресом. Но на это не стоит надеяться, а задать приоритет явно.
     standby 1 priority 110
     !Задаем приоритет маршрутизатора в указанной группе. Диапазон 0-255.
     standby 1 name SB
     !Задаем имя нашей группе. Нужно для SSO. Дальше рассмотрим зачем 

   interface GigabitEthernet0/0 – наш внешний интерфейс
     ip address 10.10.25.14 255.255.255.0
     standby version 2
     standby 0 ip 10.10.25.1
     standby 0 priority 110

Переходим к резервному

CUBE-2: 

   interface GigabitEthernet0/1 – наш внутренний интерфейс
     ip address 10.10.24.13 255.255.255.0
     standby version 2
     standby 1 ip 10.10.24.1
     standby 1 priority 100
     standby 1 name SB

   interface GigabitEthernet0/0 – наш внешний интерфейс
     ip address 10.10.25.13 255.255.255.0
     standby version 2
     standby 0 ip 10.10.25.1
     standby 0 priority 100

После этого получаем первые результаты

CUBE-1#sh standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active   Standby     Virtual IP
  Gi0/1    1   110   Active  local  10.10.24.13   10.10.24.1
  Gi0/0    0   110   Active  local  10.10.25.13   10.10.25.1

         HSRP поднялся, активный CUBE выбран. Можно подумать, что все. Но нет…
Давайте теперь посмотрим, что будет, если один из интерфейсов на активном маршрутизаторе выйдет из строя.
         Допустим, Gi0/0 отвалился. В таком случае в группе 0 роль активного переходит к CUBE-2. Но в группе 1 ничего не меняется, CUBE-1 остается активным. И что станется с нашими звонками? В такой ситуации не то что текущие звонки не сохраняются, а и новые не устанавливаются.
         Тогда нам нужно как-то заставить поменяться ролями маршрутизаторы в 0 группе в зависимости от положения дел в группе 1.
         Тут мы можем сделать такое: сказать CUBE-1, если его интерфейс Gi0/0 уходит в down, уменьшить приоритет маршрутизатора в группе 1 на 11.

CUBE-1:
   interface GigabitEthernet0/1
     standby 1 track 1 decrement 11
     !Определяем уменьшение приоритета маршрутизатора на 11 если трек 1 возвращает результат false

   track 1 interface GigabitEthernet0/0 line-protocol
   !Отслеживаем состояние интерфейса GigabitEthernet0/0. Если этот интерфейс по какой-то причине упадет, track 1 получит значение false.

         

         И того, если интерфейс Gi0/0 падает – приоритет CUBE-1 в группе 1 уменьшается с 110 до 99, что меньше приоритета CUBE-2 в этой же группе (100). Значит, CUBE-2 теперь должен стать активным. Может, конечно, и должен, но не станет.
         Вспоминаем еще одну характеристику протокола HSRP. Если в группе уже выбран активный маршрутизатор, то он не отдаст свою роль до тех пор, пока находится в рабочем состоянии. Даже если появится участник с большим приоритетом. Это дефолтное поведение.
         Нам такое не подходит. Поэтому, воспользуемся правом изменить дефолтные установки. И в этом нам поможет следующая команда:
   interface GigabitEthernet0/1
     standby 1 preempt

         Вот только теперь мы получим то, что хотели. Если на CUBE-1 выйдет из строя интерфейс Gi0/0, он потеряет роль активного в обеих группах. Такое же необходимо сделать и для интерфейса Gi0/1.

   interface GigabitEthernet0/0
     standby 0 track 2 decrement 11
     standby 0 preempt

   track 2 interface GigabitEthernet0/1 line-protocol 

Не забываем про резервный

CUBE-2:
   interface GigabitEthernet0/0
     standby 0 track 2 decrement 11
     standby 0 preempt

   interface GigabitEthernet0/1
     standby 1 track 1 decrement 11
     standby 0 preempt

   track 1 interface GigabitEthernet0/0 line-protocol 
   track 2 interface GigabitEthernet0/1 line-protocol

         А как насчет скорости сходимости? Как быстро резервный маршрутизатор определяет, что активный немного мертв и берет на себя его обязанности? По умолчанию, в HSRP hello таймер 3 сек, а hold таймер 10 сек. Значит, максимум через 10 сек резервный маршрутизатор определит неработоспособность активного. Если нам нужно быстрее (а нам нужно), эти цифры можно поменять.
         Cisco рекомендует не ставить hello таймер слишком маленьким (не меньше 1 сек), чтоб не грузить процессор. А hold таймер должен быть не менее 3*hello (возьмем 4), чтобы предотвратить флапание HSRP состояний. Так же таймеры должны быть обязательно одинаковыми на всех маршрутизаторах одной HSRP группы.
Спорить не будем 

CUBE-1:
   interface GigabitEthernet0/0
     standby 0 timers 1 4
     !hello 1 сек, hold 4 сек
   interface GigabitEthernet0/1
     standby 1 timers 1 4

CUBE-2:
   interface GigabitEthernet0/0
     standby 0 timers 1 4
   interface GigabitEthernet0/1
     standby 1 timers 1 4

         Еще один способ предотвратить флапание HSRP состояний – задать задержку запуска HSRP на интерфейсе. Кроме этого, так как наши устройства настроены как preempt, то после восстановления работоспособности (перезагрузился или интерфейс включился), они должны установить полное соединение с остальной сетью прежде, чем получить обратно роль активного. Значит preempt тоже нужно задержать, достаточно только на активном маршрутизаторе.
Делам так

CUBE-1:
   interface GigabitEthernet0/0
     standby delay minimum 30 reload 300
     !Задаем задержку (в секундах) инициализации HSRP на интерфейсе после того как интерфейс включился (minimum, в сек) и после перезагрузки маршрутизатора (reload, в сек). 
     standby 0 preempt minimum 30 reload 300
     !То же, только для preempt

   interface GigabitEthernet0/1
     standby delay minimum 30 reload 300
     standby 1 preempt minimum 30 reload 300

         Какие значения задержек выбирать? Задержка minimum – 30 сек должно быть достаточно. Для задержки reload есть рекомендация, что она должна быть на 50% больше чем время перезагрузки маршрутизатора. Где найти время перезагрузки, не знаю. Это зависит от модели оборудования, комплектации и версии IOS. Мой маршрутизатор (2911, IOS 15.4(2)T) перезагружался ≈ 3 мин. Задержку установила на 5 мин.
 С HSRP это все для нашей задачи.
Более подробно о настройке HSRP можно почитать здесь

         Так как теперь у нас работает HSRP, указываем нашим CUBE использовать как адрес источника для SIP сообщений виртуальные адреса

   dial-peer voice 100 voip
     description to-SIP
     voice-class sip bind control source-interface GigabitEthernet0/0
     voice-class sip bind media source-interface GigabitEthernet0/0
   !
   dial-peer voice 200 voip
     description to-CUCM
     voice-class sip bind control source-interface GigabitEthernet0/1
     voice-class sip bind media source-interface GigabitEthernet0/1

         Ну и SIP транк на CUCM адресуем тоже на виртуальный адрес нашей внутренней HSRP группы. Если мы этого не сделает, то звонки на реальные адреса CUBE проходить не будут.
         

         Теперь отказоустойчивость работает корректно. Если активный CUBE (или один из его интерфейсов) выйдет из строя, резервный подхватит его работу. Но если в момент switchover будут активные звонки, то они, к сожалению, сорвутся. Во избежание этого, настраиваем отказоустойчивость с сохранением состояния наших звонков (SSO).
         Для начала нужно указать нашим CUBE, что у них теперь работает резервирование, и хорошо было бы им отслеживать и обмениваться информацией о звонках. Это для того, чтоб в момент Switchover резервный шлюз мог подхватить передачу RTP потоков текущих звонков.

   voice service voip
     redundancy

         Дальше переходим к конфигурации собственно SSO. Так как информацией о сессиях обмениваются активный и резервный маршрутизаторы, здесь необходимо указать группу HSRP откуда их брать.

 CUBE-1(config)# redundancy inter-device 
 !Включаем SSO 
 CUBE-1(config-red-interdevice)# scheme standby SB
 !Указываем HSRP группу, которую мы раньше создавали

         Для связи между активным и резервным маршрутизаторами необходимо настроить линию связи и транспорт (Inter Process Communication (IPC)).

CUBE-1(config)#ipc zone default
 !Используем эту команду для входа в режим конфигурации линии связи между активным и резервным устройствами.
CUBE-1(config-ipczone)#association 1
 !Ассоциируем два наших устройства друг с другом. ID этого процесса должен быть одинаковым на обоих маршрутизаторах.
Замечание: в документации указано, что диапазон разрешенных association ID – 1..255, но…
CUBE-1 (config-ipczone)#association ?
<1-255> Association ID
CUBE-1 (config-ipczone)#association 3
% IPC association id 3 is not supported. Id 1 is only supported
CUBE-1(config-ipc-protocol-sctp)#no sh
 !Включаем все это дело
CUBE-1(config-ipczone-assoc)#protocol sctp
 !Входим в режим конфигурации Stream Control Transmission Protocol (SCTP), который будет использоваться для передачи SSO сообщений. Задаем его параметры 
CUBE-1(config-ipc-protocol-sctp)#local-port 5000
 !Локальный SCTP порт. Конкретного значения порта здесь нет, главное чтоб он был одинаковым на обоих наших устройствах.
CUBE-1(config-ipc-local-sctp)#local-ip 10.10.24.14
 !локальный адрес для коммуникации с резервным устройством
CUBE-1(config-ipc-local-sctp)#exit
 !В этом месте обязательно нужно выйти
CUBE-1(config-ipc-protocol-sctp)#remote-port 5000
 !SCTP порт резервного маршрутизатора 
CUBE-1(config-ipc-remote-sctp)#remote-ip 10.10.24.13
 !его адрес
CUBE-1(config-ipc-remote-sctp)#end

         В рекомендациях указано, что для этой коммуникации лучше использовать выделенный отдельный физический линк, который не используется для передачи данных.

На резервном все аналогично, только IP меняем:
CUBE-2(config)# redundancy inter-device
CUBE-2(config-red-interdevice)# scheme standby SB

CUBE-2(config-red-interdevice)# exit 

CUBE-2(config)#ipc zone default
CUBE-2(config-ipczone)#association 1
CUBE-2(config-ipc-protocol-sctp)#no sh
CUBE-2(config-ipczone-assoc)#protocol sctp
CUBE-2(config-ipc-protocol-sctp)#local-port 5000
CUBE-2(config-ipc-local-sctp)#local-ip 10.10.24.13
CUBE-2(config-ipc-local-sctp)#exit
CUBE-2(config-ipc-protocol-sctp)#remote-port 5000
CUBE-2(config-ipc-remote-sctp)#remote-ip 10.10.24.14
CUBE-2(config-ipc-remote-sctp)#end

         Данная конфигурация вступит в силу только после перезагрузки маршрутизаторов. До перезагрузки все выглядит так:

CUBE-1#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_INIT
  Pending Scheme: Standby (Will not take effect until next reload)
      Pending Groupname: b2bha
Scheme: <NOT CONFIGURED>
Peer present: UNKNOWN
Security: Not configured

После перезагрузки: 
CUBE-1#show redundancy inter-device 
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
  Scheme: Standby
      Groupname: b2bha Group State: Active
Peer present: RF_INTERDEV_PEER_COMM
Security: Not configured

         Во время failover звонки могут некорректно завершаться, что приводит к, так называемым, зависшим сессиям. Для того, чтобы их очистить мы  можем использовать Media Inactivity Timer. Если Активный/Резервный маршрутизатор не получает RTP пакетов для определенного звонка в течении указанного времени, сессия этого звонка сбрасывается. 

   ip rtcp report interval 3000
   !Эта команда настраивает средний интервал между последовательными передачами отчетов RTCP для данного голосового сеанса, в милисекундах.
   gateway
     media-inactivity-criteria rtcp
     !Указываем, что как параметр определения висит звонок или нет, выбираем RTCP отчеты. Этот вариант более надежен, по сравнению с детектированием RTP пакетов, так как во время звонка бывают моменты когда одна сторона (или даже обе) не передают RTP пакетов.
     timer receive-rtcp 10
     !Множитель для интервала времени, заданного в ip rtcp report interval

         В итоге имеем, что если в течении времени 3*10=30 сек маршрутизатор не получает RTCP или RTP пакетов, звонок завершается.

  И так, как же все это теперь у нас работает.
         1. Если звонок уже установлен и происходит switchover, передача RTP пакетов этого звонка переходит на резервный CUBE практически незаметно для абонентов. Заметна лишь только небольшая пауза.
         2. Этот же звонок (который перешел на резервный CUBE во время switchover) можно без проблем поставить на удержание, сделать ему трансфер и т.п. Сигнализация сохраняется, так как я использую IOS 15.4
         3. Если звонок еще не установился (еще не взяли трубку с другой стороны), то во время switchover он оборвется. 

Проверить

CUBE-1#show redundancy states 
  my state = 13 -ACTIVE
 peer state = 8 -STANDBY HOT
   Mode = Duplex
   Unit ID = 0
   …

CUBE-2#sh redundancy states
  my state = 8 -STANDBY HOT
 peer state = 13 -ACTIVE
   Mode = Duplex
   Unit ID = 0
   …

CUBE-1#sh standby brief
                  P indicates configured to preempt.
                  |
Interface Grp Pri P State   Active   Standby     Virtual IP
  Gi0/1    1  110 P Active  local  10.10.24.13   10.10.24.1
  Gi0/0    0  110 P Active  local  10.10.25.13   10.10.25.1


CUBE-2#sh standby brief
                  P indicates configured to preempt.
                  |
Interface Grp Pri P  State     Active     Standby  Virtual IP
  Gi0/1    1  110 P Standby  10.10.24.14   local   10.10.24.1
  Gi0/0    0  110 P Standby  10.10.25.14   local   10.10.25.1


Теперь давайте протестируем.
         1. Идем на активный CUBE, смотрим что у нас сейчас один звонок установлен через него 

CUBE-1#sh voip rtp connections 
VoIP RTP active connections :
No.  CallId  dstCallId  LocalRTP  RmtRTP    LocalIP      RemoteIP
1     1011     1012      16384    22824   172.18.46.68  172.18.46.65
2     1012     1011      16386    23118   172.18.46.82  172.18.46.84
Found 2 active RTP connections 

         Смотрим, что на резервном 

CUBE-2#sh voip rtp connections
VoIP RTP active connections :
No.  CallId  dstCallId  LocalRTP  RmtRTP   LocalIP      RemoteIP
1     1011     1012      16384    22824  172.18.46.68  172.18.46.65
2     1012     1011      16386    23118  172.18.46.82  172.18.46.84
Found 2 active RTP connections 
Данные о RTP сессии синхронизируются

         2. Выключаем один из интерфейсов на активном маршрутизаторе или перезагружаем его. И смотрим, что там на резервном 

CUBE-2#sh voip rtp connections 
VoIP RTP active connections : 
No.  CallId  dstCallId  LocalRTP  RmtRTP   LocalIP      RemoteIP 
1     1011     1012      16384    22824  172.18.46.68  172.18.46.65 
2     1012     1011      16386    23118  172.18.46.82  172.18.46.84 
Found 2 active RTP connections 

Сессия сохранилась, все как ожидали.

Но что там сейчас с CUBE-1? 

CUBE-1(config)#int g0/0 
CUBE-1(config-if)#shutdown
*Oct 3 09:28:47.535: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 0 state Active -> Init
*Oct 3 09:28:48.603: %HSRP-5-STATECHANGE: GigabitEthernet0/1 Grp 1 state Active -> Speak
*Oct 3 09:28:48.603: %RF-5-RF_RELOAD: Self reload. Reason: Not in correct state for becoming Standby
*Oct 3 09:28:48.603: %RF_INTERDEV-4-RELOAD: % RF induced self-reload. my state = ACTIVE peer state = STANDBY HOT 

         Он перезагружается, хотя мы просто выключили интерфейс! Но в случае использования SSO, изменение роли устройства (активный/резервный) сопровождается его перезагрузкой. Вот так это работает. Из разряда – это не баг, это фича )).

Немного про VPDN

Определения:

• LAC/NAS - L2TP/L2F Access Server - устройство принимающее вызовы от клиентов.
• LNS - L2TP/L2F Network Server - логическая точка терминации PPP сессии, который туннелирован со стороны LAC. 

Glossary

• Client: PC or router attached to a remote access network, which is the initiator of a call.
• L2TP: Layer 2 Tunnel Protocol. PPP defines an encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Typically, a user obtains an L2 connection to a Network Access Server (NAS) using a technique such as dialup plain old telephone service (POTS), ISDN or Asymmetric Digital Subscriber Line (ADSL). The user then runs PPP over that connection. In such a configuration, the L2 termination point and PPP session endpoint reside on the same physical device (the NAS).
  L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a network. With L2TP, the user has an L2 connection to an access concentrator, and the concentrator then tunnels individual PPP frames to the NAS. This allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit.
• L2F: Layer 2 Forwarding Protocol. L2F is a tunneling protocol older than L2TP.
• LAC: L2TP Access Concentrator. A node that acts as one side of an L2TP tunnel endpoint and is a peer to the LNS. The LAC sits between an LNS and a client and forwards packets to and from each. Packets sent from the LAC to the LNS require tunneling with the L2TP protocol. The connection from the LAC to the client is typically through ISDN or analog.
• LNS: L2TP Network Server. A node that acts as one side of an L2TP tunnel endpoint and is a peer to the LAC. The LNS is the logical termination point of a PPP session that is being tunneled from the client by the LAC.
• Home Gateway: Same definition as LNS in L2F terminology.
• NAS: Same definition as LAC in L2F terminology.
• Tunnel: In L2TP terminology, a tunnel exists between a LAC-LNS pair. The tunnel consists of a control connection and zero or more L2TP Sessions. The tunnel carries encapsulated PPP datagrams and control messages between the LAC and the LNS. The process is the same for L2F.
• Session: L2TP is connection-oriented. The LNS and LAC maintain a state for each call that is initiated or answered by an LAC. An L2TP session is created between the LAC and LNS when an end-to-end PPP connection is established between a client and the LNS. Datagrams related to the PPP connection are sent over the tunnel between the LAC and LNS. There is a one-to-one relationship between established L2TP sessions and their associated calls. The process is the same for L2F.

Overview of the VPDN Process

In the description of the VPDN process below, we use the L2TP terminology (LAC and LNS).

1. The client calls the LAC (typically using a modem or an ISDN card).
2. The client and the LAC starts the PPP phase by negotiating the LCP options (authentication method Password Authentication Protocol [PAP] or Challenge Handshake Authentication Protocol [CHAP], PPP multilink, compression, and so on).
3. Let's suppose that CHAP has been negotiated in step 2. The LAC sends a CHAP challenge to the client.
4. The LAC gets a response (for instance username@DomainName and password).
5. Based on the domain name received in the CHAP response or the Dialed Number Information Service (DNIS) received in the ISDN setup message, the LAC checks whether the client is a VPDN user. It does this by using its local VPDN configuration or contacting an Authentication, Authorization, and Accounting (AAA) server.
6. Because the client is a VPDN user, the LAC gets some information (from its local VPDN configuration or from an AAA server) that it uses to bring up a L2TP or L2F tunnel with the LNS.
7. The LAC brings up a L2TP or L2F tunnel with the LNS.
8. Based on the name received in the request from the LAC, the LNS checks if the LAC is allowed to open a tunnel (the LNS checks its local VPDN configuration). Moreover, the LAC and the LNS authenticate each other (they use their local database or contact an AAA server). The Tunnel is then up between both devices. In this tunnel, several VPDN sessions can be carried.
9. For the client username@DomainName, a VPDN session is triggered from the LAC to the LNS. There is one VPDN session per client.
10. The LAC forwards the LCP options it has negotiated to the LNS with the client along with the username@DomainName and password received from the client.
11. The LNS clones a virtual-access from a virtual-template specified in the VPDN configuration. The LNS takes the LCP options received from the LAC and authenticate the client locally or by contacting the AAA server.
12. The LNS sends a CHAP response to the client.
13. The IP Control Protocol (IPCP) phase is performed and then the route is installed: the PPP session is up and running between the client and the LNS. The LAC just forwards the PPP frames. The PPP frames are tunneled between the LAC and the LNS.

Tunneling Protocols

A VPDN tunnel can be built using either Layer-2 Forwarding (L2F) or Layer-2 Tunneling Protocol (L2TP).

• L2F was introduced by Cisco in Request For Comments (RFC) 2341 and is also used to forward PPP sessions for Multichassis Multilink PPP.
• L2TP, introduced in RFC 2661, combines the best of the Cisco L2F protocol and Microsoft Point-to-Point Tunneling Protocol (PPTP). Moreover, L2F supports only dial-in VPDN while L2TP supports both dial-in and dial-out VPDN.

Both protocols use the UDP port 1701 to build a tunnel through an IP network to forward link-layer frames. For L2TP, the setup for tunneling a PPP session consists of two steps:

1. Establishing a tunnel between the LAC and the LNS. This phase takes place only when there is no active tunnel between both devices.
2. Establishing a session between the LAC and the LNS.

The LAC decides that a tunnel must be initiated from the LAC to the LNS.

1. The LAC sends a Start-Control-Connection-Request (SCCRQ). A CHAP challenge and AV Pairs are included in this message.
2. The LNS responds with a Start-Control-Connection-Reply (SCCRP). A CHAP challenge, the response to LAC's challenge and AV Pairs are included in this message.
3. The LAC sends a Start-Control-Connection-Connected (SCCCN). The CHAP response is included in this message.
4. The LNS responds with a Zero-Length Body Acknowledgement (ZLB ACK). That acknowledgement may be carried in another message. The tunnel is up.
5. The LAC sends an Incoming-Call-Request (ICRQ) to the LNS.
6. The LNS responds with an Incoming-Call-Reply (ICRP) message.
7. The LAC sends an Incoming-Call-Connected (ICCN).
8. The LNS responds back with a ZLB ACK. That acknowledgement may also be carried in another message.
9. The session is up.

Note: The messages above used for opening a tunnel or a session carry Attribute Value Pairs (AVPs) defined in RFC 2661. They describe properties and information (such as Bearercap, hostname, vendor name and window size). Some AV pairs are mandatory and others are optional.

Note: A Tunnel ID is used to multiplex and demultiplex tunnels between the LAC and LNS. A session ID is used to identify a particular session with the tunnel.

For L2F, the setup for tunneling a PPP session is the same as for L2TP. It involves:

1. Establishing a tunnel between the NAS and the Home Gateway. This phase takes place only when there is no active tunnel between both devices.
2. Establishing a session between the NAS and the Home Gateway.

The NAS decides that a tunnel must be initiated from the NAS to the Home Gateway.

1. The NAS sends a L2F_Conf to Home Gateway. A CHAP challenge is included in this message.
2. The Home Gateway responds with a L2F_Conf. A CHAP challenge is included in this message.
3. The NAS sends a L2F_Open. The CHAP response of the Home Gateway challenge is included in this message.
4. The Home Gateway responds with a L2F_Open. The CHAP response of the NAS challenge is included in this message. The tunnel is up.
5. The NAS sends a L2F_Open to the Home Gateway. The packet includes the username of the client (client_name), the CHAP challenge sent by the NAS to the client (challenge_NAS) and its response (response_client).
6. The Home Gateway, by sending back the L2F_OPEN, accepts the client. Traffic is now free to flow in either direction between the client and the Home Gateway.

Note: A tunnel is identified with a CLID (Client ID). Multiplex ID (MID) identifies a particular connection within the tunnel.