Интерфейсы и модули Cisco : Cisco Unified SIP Proxy

Cisco унифицированная обработка вызовов прокси SIP

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как Cisco Унифицированный Прокси Протокола SIP делает решения о маршрутизации вызова.

Внесенный Аджитом Сингхом, специалистом службы технической поддержки Cisco.

Предварительные условия

Требования

Cisco рекомендует ознакомиться с унифицированным прокси-сервером Cisco SIP (CUSP).

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

Модель обработки CUSP

Сеть

В этом разделе описываются понятие сети, используемой в потоке обработки вызова CUSP.

  • Сеть содержит логическое объединение локальных интерфейсов, которые лечат то же от общих назначений маршрутизации.
  • Сообщения SIP, по прибытию, привязаны к сети, в которой сообщения получены (входящая сеть).
  • Исходящая сеть установлена как часть логики маршрутизации CUSP, и сообщения переданы/переданы сети набора.
  • Каждая сеть SIP имеет эти свойства:
    • Слушайте Точки - могут иметь множественный, слушают точки на сеть
    • Группы серверов - элементы в Группах серверов (SG), такие как кластеры Cisco Unified Communications Manager (CUCM)
    • Sip timer - количество повторной передачи
    • Опции Ping - контролируют состояние каждого элемента в SG и настроены на сеть
    • Рекордный Маршрут - режимы вызова не сохранены, потому что существуют таблицы маршрутизации
    • Через Разделение Заголовка - для сокрытия топологии

Например:

sip listen Net-PSTN udp 14.128.100.169 5060

 !
sip network Net-PSTN standard
  no non-invite-provisional
 allow-connections
 retransmit-count invite-client-transaction 3
  retransmit-count invite-server-transaction 5
 retransmit-count non-invite-client-transaction 3
  retransmit-timer T1 500
  retransmit-timer T2 4000
  retransmit-timer T4 5000
  retransmit-timer TU1 5000
  retransmit-timer TU2 32000
  retransmit-timer clientTn 64000
  retransmit-timer serverTn 64000
  tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
 !

Спусковые механизмы

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

  • Спусковой механизм является рядом условий, используемых для определения, какая политика маршрутизации и нормализации применена к запросу SIP.
  • Более аккуратное условие определяет соответствие, выносит обвинительное заключение определенным, некоторый заголовкам или полям в сообщении SIP, сети и типе передачи (UDP, TCP, Transport Layer Security (TLS)).
  • Спусковой механизм оценен как любая истина или ложь для каждого полученного запроса.
  • Если условие истинно, то заданные способы поведения вызваны.
  • Операция И достигнута путем определения заголовков или полей в одиночной команде более аккуратного условия.
  • Операция OR достигнута с несколькими более аккуратными условиями, каждый определенный порядковым номером.
  • Условия оценены в порядке возрастания на основе порядкового номера.
  • Середина диалогового условия является первой, так, чтобы шаг политики был пропущен для середины диалоговых сообщений.

Например:

trigger condition TC-from-CUCM
 sequence 1
  in-network Net-CUCM
   method INVITE
   end sequence
 sequence 2
   in-network Net-PSTN
   local-port 5060
  end sequence
end trigger condition

Маршрутизация политики поиска

В этом разделе описываются политику поиска маршрутизации для потока обработки вызова CUSP. 

  • Каждая политика маршрутизации выражена как последовательность шагов, и каждый задан для выполнения поиска в таблице.
  • CUSP выполняет каждый шаг в заказ:
    • Каждый шаг имеет выбираемый ключ.
    • Если шаг производит маршрут, тот маршрут используется.
    • Если результаты шага в "без соответствия", предпринят следующий шаг.
  • Запрос SIP может маршрутизироваться к одному месту назначения или к Группе маршрутов (RG).
  • Политика имеет Многоуровневое Усовершенствование Маршрута в RG и имеет конфигурируемые коды ответа SIP аварийного переключения.
  • На основе политики отклонение запроса включено (4xx ответы и выше).
  • Встроенная политика позволена.
  • Основанная на таблице маршрутизация используется, который имеет эти свойства:
    • Это поддерживает большое число маршрутов в таблице (10,000 +).
    • Маршруты в таблице заполнены через CLI или файл маршрута.
    • Ключи поиска используются, такие как вызов и номер вызываемого абонента, коды носителя и номера маршрутизации местоположения.
    • Гибкое соответствие правила используется, такие как "самое длинное совпадение префиксов".

Политика нормализации

В этом разделе описываются вызов CUSP, обрабатывающий политику нормализации потока. 

  • Заголовки SIP нормализованы на основе настроенной политики.
  • Нормализация включает добавление, модификацию и удаление заголовков SIP.
  • Это применимо и к запросам SIP и к ответам.
  • Это используется для решения несовместимостей или проблем взаимодействия между другими серверами SIP.
  • Это может быть выполнено, прежде или после того, как логика маршрутизации выполняется (Преднормализация и Постнормализация).
  • Логика нормализации:
    • Политика нормализации - Определяет то, какие изменения должны быть внесены в сообщение SIP.
    • Спусковые механизмы нормализации - Определяют, как выбрана политика нормализации.
  • Политика состоит из шагов, и каждый шаг задает одиночное изменение к сообщению SIP. Например: :
    • Нормализация количества
    • Преобразования TEL/SIP
    • Доменные преобразования
    • Обработка регулярного выражения

Вот блок-схема, которая показывает процесс:

Поток преднормализации CUSP

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

В данном примере пользовательская часть  Запроса Унифицированного идентификатора ресурса (URI) SIP  заменена 4082022222, если значение, которое существует, 2022222.

!trigger pre-normalization sequence 1 policy CUCM-Prefix-408 condition TC-from-CUCM
!
policy normalization CUCM-Prefix-408
 uri-component update request-uri user 2022222 4082022222
 end policy
!

Вот блок-схема Преднормализации:

Поток маршрутизации CUSP

Этот раздел иллюстрирует поток маршрутизации CUSP. Вот диаграмма потока маршрутизации CUSP:

Поток группы маршрутов CUSP

В этом разделе описываются поток RG CUSP.

  • RG задает несколька маршрутов, которые запрос SIP мог бы взять (подобный RG CUCM).
  • Каждый маршрут настроен как элемент.
  • Когда условие спускового механизма маршрутизации оценено как истинное, политика поиска, которая соответствует ему, используется для создания списка применимых таблиц маршрутизации.
  • Каждая запись в таблице маршрутизации указывает к определенному RG, SG или определенному назначению.
  • Маршруты усовершенствованы между элементами до успешный. Например, если вы хотите направить вызов к кластеру CUCM, Абонент может быть одним элементом, в то время как Издатель является вторым.
  • Усовершенствования маршрута между элементами управляются на полученном ответе SIP (ответ аварийного переключения).
  • Элементы RG неоднородны. Например, один маршрут возглавляет к CUCM и другому к Открытой коммутируемой телефонной сети (PSTN).
  • Элемент RG может указать к SG.
  • Запросы SIP маршрутизируются на основе времени дня.

CUSP поддерживает эти действия: 

  • Синхронизируемая маршрутизация в RG
  • Percentage/weight-based, направляющий в RG или SG
    • Это обеспечивает распределение нагрузки трафика среди нисходящих элементов, на основе предварительно установленного веса.
    • Это предоставляет q-значения для приоритетного/наименьшего количества маршрутизации на основе стоимости.

Вот пример RG с SG, настроенным как целевое назначение:

!
route group RG-UC520
 element target-destination SG-UC520 Net-UC520 q-value 1.0
  failover-codes 502 - 503
  weight 0
  end element
 end route
!
server-group sip group SG-UC520 Net-UC520
 element ip-address 14.128.100.161 5060 udp q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

Вот блок-схема Группы маршрутов CUSP:

Поток группы серверов CUSP

В этом разделе описываются поток SG CUSP.

  • SG является кластером нисходящих элементов, которые CUSP обрабатывает как одиночный логический маршрут.
  • Участники SG являются гомогенными, такими как стек/кластер Унифицированных элементов границы Cisco (CUBEs).
  • Запросы распределены нагрузку среди участников.
  • Приоритет каждого участника (элемент) в SG назначен q-значениями (0.0? 1.0), с 1.0 как самое высокое.
  • SG обеспечивает задействованный контроль исправности (эхо-запрос).
  • SG обеспечивает автоматическое восстановление на задействованном восстановлении.

   
Вот пример SG с двумя элементами (Издатель и подписчик CUCM)

!
server-group sip group SG-CUCM.ajeet.com Net-CUCM
 element ip-address 14.128.64.191 5060 udp q-value 1.0 weight 50
 element ip-address 14.128.64.192 5060 udp q-value 1.0 weight 100
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

Вот блок-схема Группы серверов: 

Поток постнормализации CUSP

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

В данном примере пользовательская часть Запроса URI SIP заменена 85224044444, если значение, которое существует, 4444:

!
trigger post-normalization sequence 1 policy UC520-Four-to-Full
condition TC-UC520-to-PSTN
!
policy normalization UC520-Four-to-Full
 uri-component update request-uri user 4444 85224044444
 end policy
!

Вот блок-схема Постнормализации:

Дополнительные сведения


Связанные обсуждения сообщества поддержки Cisco

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


Document ID: 116251