По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Решение Cisco для контактных центров UCCX является решением для взаимодействия с клиентом. Основными функциями CCX является обеспечение функционала голосового меню Interactive Voice Response (IVR) и распределение вызова Automatic Call Distribution (ACD). Голосовое меню (IVR) это программный продукт, обеспечивающий клиента возможностью самообслуживания. Обычно, IVR используется для входящих вызовов. При звонке клиенту предлагается нажать одну или несколько кнопок для связи с тем, или иным отделом, предоставляется возможность распознавания речи Automatic Speech Recognition (ASR), автоматически произносится запрашиваемая информация по технологии Text to Speech (TTS). Данное взаимодействие осуществляется по протоколу Media Resource Control Protocol (MRCP), который описан в RFC 4463. Посмотрите структуру взаимодействия UCCX в корпоративном сегменте: Корпоративная сеть с элементом контактного центра на базе решение Cisco Unified Contact Center Express весьма обширна, поэтому, давайте разбираться: Голосовой шлюз - Соединяет Cisco Unified Communications Manager (CUCM) к сегмента телефонной сети общего пользования (ТфОП). Входящие и исходящие транзакции проходят через голосовой шлюз; Кластер серверов CUCM - Обеспечивает функционал телефонии для оконечных устройств (End point), управляет шлюзами по протоколу MGCP, телефонной сигнализацией SIP/SCCP/H.323 и видеоконференцсвязью; UCCX сервер - Обеспечивает функционал многоуровневого голосового меню (IVR) и распределения звонков между операторами; Редактор сценариев IVR (CCX script editor) - Программа, предназначенная для создания, изменения, проверки и отладки сценариев голосового меню, выполненная в виде графического редактора; Ноутбук администратора (Desktop Work Flow Administrator) - Утилита для конфигурации агентов и определения работы агентов; Система отчетности (Cisco Unified Intelligence Center) - Система отчетности. Обеспечивает удобный интерфейс взаимодействия супервизора для просмотра отчетов по работе операторов и производительности контактного центра; Внешние БД - Базы данных, из которых UCCX может получать информацию, например, чтобы предоставлять ее автоматическими средствами TTS звонящему клиенту; ASR/TTS сервер - Сервер, на котором расположены программный продукты для синтеза и распознавания речи; Веб - интерфейс продукта сделан в привычном для Cisco дизайне: Сервер Cisco UCCX, как и любой другой продукт, создан для получения прибыли и, соответственно, имеет лицензионные и пакетные ограничения. В данном описании собраны опции, которые ограничиваются лицензией: Порты IVR (лицензируются поштучно); Проигрывание аудио файлов и обработка цифр по DTMF; Контроль вызова, такой как ответ, отбой, трансфер и так далее; Отказоустойчивость (требуется дополнительная лицензия); Интеграция с корпоративными продуктами через Java DataBase Connectivity (JDBC) интерфейс; Обработка HTTP запросов; Обработка исходящих e-mail; VXML поддержка для голосовых технологий; Интеграция через CTI интерфейс; Обработка XML; Интеграция с сервисами TTS/ASR по протоколу MRCP; Функции автосекретаря; Историческая отчетность и реального времени; Распределение опций по пакетам и соответствующее лицензирование: Опция Cisco Unified CCX Standard Cisco Unified CCX Enhanced Cisco Unified CCX Premium Порты IVR Не ограничено. Определяется производительностью сервера Есть Два IVR порта на одного агента, интеграция по интерфейсу JDBC, исходящие e-mail, VXML для голосовых приложений. Аудио файлы и обработка DTMF Есть Есть Есть Контроль вызова Есть Есть Есть Маршрутизация вызовов, ACD алгоритм и очереди. Есть Есть Есть Контроль агента Контроль вызова, коды отбоя, контроль очереди в реальном времени Автоматические задачи, CTI процессы, запись вызовов по требованию, интегрированный чат Интегрированное место, работа с e-mail и чатами, исходящий обзвон, возможности WFO. Отчетность Есть Дополнительная историческая отчетность реального времени Есть Место «супервизора» Контроль агентов, метрики реального времени для распределения вызовов. Командный чат, мониторинг без ведома агента, запись разговора агента по требованию Есть Функции автосекретаря Есть Есть Есть Интеграция с Cisco IM&P Есть Есть Есть SNMP индикаторы Есть Есть Есть Отказоустойчивость Нет Есть Есть Приоритет в очереди Нет Есть Есть MRCP для TTS/ASR Нет Нет Есть Сервер Cisco UCCX может быть установлен в виртуальной среде VMware, а так же, на следующих аппаратных платформах: Сервера серии MCS-78xx (MCS-7815, MCS-7816, MCS-7835, MCS-7845) Сервера серии HP DL IBM сервера X – серии. Виртуальная машина на Unified Computing System (UCS) B и C серии. Голосовые шлюзы для исходящего обзвона должны иметь прошивку IOS 15.1 (3) T или выше. Поддерживаемые модели 28xx, 29xx, 38xx, 39xx.
img
В этой серии лекций продолжается рассмотрение распределенных плоскостей управления, добавляя к изучению еще три протокола маршрутизации. Два из них являются протоколами состояния канала, а третий – единственный, широко распространенный протокол вектора пути, Border Gateway Protocol (BGP) v4. В этих лекция мы уделим внимание тому, почему каждый из этих протоколов реализован именно так. Очень легко увлечься и запутаться в изучении мельчайших деталей работы протоколов, но нам гораздо важнее помнить о проблемах, для решения которых эти протоколы были разработаны, и о диапазоне возможных решений. Каждый изучаемый вами протокол будет представлять собой комбинацию умеренно ограниченного набора доступных решений: существует очень мало доступных новых решений. Существуют различные комбинации решений, реализованных иногда уникальными способами для решения конкретных наборов проблем. Изучая эти принципы работы протокола, вы должны попытаться выбрать общие решения, которые они реализуют. Затем отразить эти решения обратно в набор проблем, которые должна решить любая распределенная плоскость управления, чтобы устранить проблемы в реальных сетях. Краткая история OSPF и IS-IS Протокол Intermediate System to Intermediate System (IS-IS или IS to IS) был разработан в 1978 году. Open Shortest Path First (OSPF) изначально задумывался как альтернатива IS-IS, предназначенная специально для взаимодействия с сетями IPv4. В 1989 году первая спецификация OSPF была опубликована Internet Engineering Task Force, а OSPFv2, значительно улучшенная спецификация, была опубликована в 1998 году как RFC2328. OSPF, безусловно, был более широко используемым протоколом, причем ранние реализации IS-IS практически не применялись в реальном мире. Были некоторые аргументы за и против, и многие функции были «позаимствованы» из одного протокола в другой (в обоих направлениях). В 1993 году компания Novell, в то время крупный игрок в мире сетевых технологий, использовала протокол IS-IS как основу для замены собственного протокола маршрутизации Netware. Протокол транспортного уровеня Novell, Internet Packet Exchange (IPX), в то время работал на большом количестве устройств, и возможность использования одного протокола для маршрутизации нескольких транспортных протоколов была решающим преимуществом на сетевом рынке (EIGRP, также может маршрутизировать IPX). Этот протокол замены был основан на IS-IS. Чтобы реализовать новый протокол Novell, многие производители просто переписали свои реализации IS-IS, значительно улучшив их в процессе. Это переписывание сделало IS-IS привлекательным для крупных провайдеров Интернет-услуг, поэтому, когда они отказались от протокола RIP, они часто переходили на IS-IS вместо OSPF. Intermediate System to Intermediate System Protocol В протоколе Intermediate System to Intermediate System (IS-IS) маршрутизатор называется Intermediate System (Промежуточной системой (IS), а хост- End System (Конечной системой (ES). Оригинальный дизайн набора состоял в том, чтобы каждое устройство, а не интерфейс, имело один адрес. Службы и интерфейсы на устройстве будут иметь точку доступа к сетевым службам (Network Service Access Point - NSAP), используемую для направления трафика к определенной службе или интерфейсу. Таким образом, с точки зрения IP, IS-IS изначально был разработан в рамках парадигмы маршрутизации хоста. Промежуточные и конечные системы связываются непосредственно с помощью протокола End System to Intermediate System (ES-IS), позволяющего IS-IS обнаруживать службы, доступные в любой подключенной конечной системе, а также сопоставлять адреса нижних интерфейсов с адресами устройств более высокого уровня. Еще один интересный аспект дизайна IS-IS - он работает на канальном уровне. Разработчикам протокола не имело большого смысла запускать плоскость управления для обеспечения доступности транспортной системы через саму транспортную систему. Маршрутизаторы не будут пересылать пакеты IS-IS, поскольку они параллельны IP в стеке протоколов и передаются по локальным адресам связи. Когда была разработана IS-IS, скорость большинства каналов была очень низкой, поэтому дополнительная инкапсуляция также считалась расточительной. Каналы связи также довольно часто выходили из строя, теряя и искажая пакеты. Следовательно, протокол был разработан, чтобы противостоять ошибкам при передаче и потере пакетов. Адресация OSI Поскольку IS-IS был разработан для другого набора транспортных протоколов, он не использует адреса Internet Protocol (IP) для идентификации устройств. Вместо этого он использует адрес взаимодействия открытых систем (Open Systems Interconnect - OSI) для идентификации как промежуточных, так и конечных систем. Схема адресации OSI несколько сложна, включая идентификаторы для органа, распределяющего адресное пространство, идентификатор домена, состоящий из двух частей, идентификатор области, системный идентификатор и селектор услуг (N-селектор). Многие из этих частей адреса OSI имеют переменную длину, что еще больше затрудняет понимание системы. Однако в мире IP используются только три части этого адресного пространства. Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) и область, где все обрабатывается как одно поле. Системный идентификатор по-прежнему рассматривается как системный идентификатор. N Selector, или NSAP, обычно игнорируется (хотя есть идентификатор интерфейса, который похож на NSAP, используемый в некоторых конкретных ситуациях). Таким образом, промежуточные системные адреса обычно принимают форму, показанную на рисунке 1. На рисунке 1: Точка разделения между системным идентификатором и остальной частью адреса находится в шестом октете или если отсчитать двенадцать шестнадцатеричных цифр с правой стороны. Все, что находится слева от шестого октета, считается частью адреса области. Если N-селектор включен, это один октет или две шестнадцатеричные цифры справа от идентификатора системы. Например, если для адреса A был включен N-селектор, это могло бы быть 49.0011.2222.0000.0000.000A.00. Если в адрес включен N-селектор, вам нужно пропустить N-селектор при подсчете более шести октетов, чтобы найти начало адреса области. A и B находятся в одном домене flooding рассылки, потому что у них одни и те же цифры от седьмого октета до крайнего левого октета в адресе. C и D находятся в одном flooding domain. A и D представляют разные системы, хотя их системный идентификатор одинаков. Однако такая адресация может сбивать с толку и поэтому не используется в реальных развертываниях IS-IS (по крайней мере, вдумчивыми системными администраторами). Вы посчитать эту схему адресации более сложной, чем IP, даже если вы регулярно работаете с IS-IS в качестве протокола маршрутизации. Однако есть большое преимущество в использовании схемы адресации, отличной от той, которая используется на транспортном уровне в сети. Гораздо проще различать типы устройств в сети и гораздо проще отделить узлы от адресатов, если продумать алгоритм Дейкстры по кратчайшему пути (SPF). Маршаллинг данных в IS-IS IS-IS использует довольно интересный механизм для маршалинга данных для передачи между промежуточными системами. Каждая IS генерирует три вида пакетов: Hello-пакеты Пакеты с порядковыми номерами (PSNP и CSNP) Одиночный пакет состояния канала (Link State Packet - LSP) Единый LSP содержит всю информацию о самой IS, любых доступных промежуточных системах и любых доступных адресатах, подключенных к IS. Этот единственный LSP форматируется в Type Length Vectors (TLV), которые содержат различные биты информации. Некоторые из наиболее распространенных TLV включают следующее: Типы 2 и 22: достижимость к другой промежуточной системе Типы 128, 135 и 235: достижимость до пункта назначения IPv4 Типы 236 и 237: достижимость к адресату IPv6 Существует несколько типов, потому что, IS-IS изначально поддерживал 6-битные метрики (большинство процессоров на момент появления протокола могли хранить только 8 бит за раз, и два бита были «украдены» из размера поля, чтобы нести информацию о том, был ли маршрут внутренним или внешним, а также другую информацию). Со временем, по мере увеличения скорости связи, были введены различные другие метрические длины, включая 24 - и 32-битные метрики, для поддержки широких метрик. Одиночный LSP, несущий всю информацию о доступности IS, IPv4 и IPv6, а также, возможно, теги MPLS и другую информацию, не поместится в один пакет MTU. Для фактической отправки информации по сети IS-IS разбивает LSP на фрагменты. Каждый фрагмент рассматривается как отдельный объект в процессе лавинной рассылки. Если изменяется один фрагмент, лавинной рассылкой по сети распространяется только измененный фрагмент, а не весь LSP. Благодаря этой схеме IS-IS очень эффективен при лавинной рассылке информации о новой топологии и достижимости без использования полосы пропускания, превышающей минимальную требуемую. Обнаружение соседей и топологии Хотя IS-IS изначально был разработан, чтобы узнать о доступности сети через протокол ES-IS, когда IS-IS используется для маршрутизации IP, он «действует так же, как протоколы IP», и узнает о достижимых местах назначения через локальную конфигурацию каждого из них. устройства и путем перераспределения из других протоколов маршрутизации. Следовательно, IS-IS - это проактивный протокол, который изучает и объявляет достижимость без ожидания пакетов, которые будут переданы и переадресованы через сеть. Формирование соседей в IS-IS довольно просто. Рисунок 2 иллюстрирует этот процесс. На рисунке 2: IS A передает приветствие в сторону B. Это приветствие содержит список соседей, от которых получен сигнал, который будет пустым. Настройку времени удержания (hold time) B следует использовать для A, и добавляется к максимальному блоку передачи (MTU) локального интерфейса для канала связи. Пакеты приветствия дополняются только до завершения процесса формирования смежности. Не каждый пакет приветствия дополняется MTU канала. IS B передает приветствие к A. Это приветствие содержит список соседей, от которых получен ответ, который будет включать A. Настройку времени удержания A следует использовать для B. Добавляется к MTU локального интерфейса. Поскольку A находится в списке «слышимых соседей» B, A рассмотрит B и перейдет к следующему этапу формирования соседей. Как только A включил B в список «услышанных соседей» хотя бы в одно приветствие, B рассмотрит A и перейдет к следующему этапу формирования соседа. B отправит полный список всех записей, которые он имеет в своей таблице локальной топологии (B описывает LSP, которые он имеет в своей локальной базе данных). Этот список отправляется в Complete Sequence Number Packet (CSNP). A проверит свою локальную таблицу топологии, сравнив ее с полным списком, отправленным B. Любые записи в таблице топологии (LSP), которых он не имеет, он будет запрашивать у B с использованием Partial Sequence Number Packet (PSNP). Когда B получает PSNP, он устанавливает флаг Send Route Message (SRM) для любой записи в его локальной таблице топологии (LSP), запрошенной A. Позже процесс лавинной рассылки будет проходить по таблице локальной топологии в поисках записей с установленным флагом SRM. Он заполнит эти записи, синхронизируя базы данных в A и B. Примечание. Описанный здесь процесс включает изменения, внесенные в RFC5303, который определяет трехстороннее рукопожатие, и дополнение приветствия, которое было добавлено в большинство реализаций примерно в 2005 году. Установка флага SRM отмечает информацию для лавинной рассылки, но как на самом деле происходит лавинная рассылка? Надежная лавинная рассылка. Для правильной работы алгоритма SPF Дейкстры (или любого другого алгоритма SPF) каждая IS в flooding domain должна совместно использовать синхронизированную базу данных. Любая несогласованность в базе данных между двумя промежуточными системами открывает возможность зацикливания маршрутизации. Как IS-IS гарантирует, что подключенные промежуточные системы имеют синхронизированные базы данных? В этой лекции описывается процесс создания point-to-point каналов. Далее будут описаны модификации, внесенные в процесс flooding domain по каналам с множественным доступом (например, Ethernet). IS-IS полагается на ряд полей в заголовке LSP, чтобы гарантировать, что две промежуточные системы имеют синхронизированные базы данных. Рисунок 3 иллюстрирует эти поля. На рисунке 3: Длина пакета (packet length) содержит общую длину пакета в октетах. Например, если это поле содержит значение 15 , длина пакета составляет 15 октетов. Поле длины пакета составляет 2 октета, поэтому оно может описывать пакет длиной до 65 536 октетов - больше, чем даже самые большие MTU канала. Поле оставшегося времени жизни (remaining lifetime) также составляет два октета и содержит количество секунд, в течение которых этот LSP действителен. Это вынуждает периодически обновлять информацию, передаваемую в LSP, что является важным соображением для старых технологий передачи, где биты могут быть инвертированы, пакеты могут быть усечены или информация, передаваемая по каналу связи, может быть повреждена. Преимущество таймера, который ведет обратный отсчет, а не на увеличение, состоит в том, что каждая IS в сети может определять, как долго ее информация должна оставаться действительной независимо от каждой другой IS. Недостаток в том, что нет четкого способа отключить описанный функционал. Однако 65 536 секунд - это большое время - 1092 минуты, или около 18 часов. Повторная загрузка каждого фрагмента LSP в сети примерно каждые 18 часов создает очень небольшую нагрузку на работу сети. LSP ID описывает сам LSP. Фактически, это поле описывает фрагмент, поскольку оно содержит идентификатор исходной системы, идентификатор псевдоузла (функцию этого идентификатора рассмотрим позже) и номер LSP, или, скорее, номер фрагмента LSP. Информация, содержащаяся в одном фрагменте LSP, рассматривается как «один блок» во всей сети. Отдельный фрагмент LSP никогда не «рефрагментируется» какой-либо другой IS. Это поле обычно составляет 8 октетов. Порядковый номер (Sequence Number) описывает версию этого LSP. Порядковый номер гарантирует, что каждая IS в сети имеет одинаковую информацию в своей локальной копии таблицы топологии. Это также гарантирует, что злоумышленник (или «кривая» реализация) не сможет воспроизвести старую информацию для замены новой. Контрольная сумма (Checksum) гарантирует, что информация, передаваемая во фрагменте LSP, не была изменена во время передачи. Лавинная рассылка описана на рисунке 4. На рисунке 4: А подключен к 2001: db8: 3e8: 100 :: / 64. A создает новый фрагмент, описывающий этот новый достижимый пункт назначения. A устанавливает флаг SRM на этом фрагменте в сторону B. Процесс лавинной рассылки в какой-то момент (обычно это вопрос миллисекунд) проверит таблицу топологии и перезальет все записи с установленным флагом SRM. Как только новая запись будет помещена в свою таблицу топологии, B создаст CSNP, описывающий всю свою базу данных, и отправит его в A. Получив этот CSNP, A удаляет свой флаг SRM в направлении B. B проверяет контрольную сумму и сравнивает полученный фрагмент с существующими записями в своей таблице топологии. Поскольку нет другой записи, соответствующей этой системе и идентификатору фрагмента, он поместит новый фрагмент в свою таблицу локальной топологии. Учитывая, что это новый фрагмент, B инициирует процесс лавинной рассылки по направлению к C. А как насчет удаления информации? Есть три способа удалить информацию из системы IS-IS flooding: Исходящая IS может создать новый фрагмент без соответствующей информации и с более высоким порядковым номером. Если весь фрагмент больше не содержит какой-либо действительной информации, исходящая IS может заполнить фрагмент с оставшимся временем жизни (lifetime) равным 0 секунд. Это приводит к тому, что каждая IS в домене лавинной рассылки повторно загружает фрагмент zero age и удаляет его из рассмотрения для будущих вычислений SPF. Если таймер lifetime во фрагменте истекает в любой IS, фрагмент заполняется лавинной рассылкой с zero age оставшегося времени жизни. Каждая IS, получающая этот фрагмент с zero age, проверяет, что это самая последняя копия фрагмента (на основе порядкового номера), устанавливает оставшееся время жизни для своей локальной копии фрагмента на ноль секунд и повторно загружает фрагмент. Это называется удалением фрагмента из сети. Когда IS отправляет CNSP в ответ на полученный фрагмент, она фактически проверяет всю базу данных, а не только один полученный фрагмент. Каждый раз, когда фрагмент лавинно рассылается по сети, вся база данных проверяется между каждой парой промежуточных систем. Подведение итогов об IS-IS IS-IS можно описать как: Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в flooding domain (протокол состояния канала). Расчет loop-free -путей с использованием алгоритма SPF Дейкстры. Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол). Проверка двусторонней связи при формировании соседей путем переноса списка «замеченных соседей» в своих пакетах приветствия. Удаление информации из домена лавинной рассылки с помощью комбинации порядковых номеров и полей оставшегося времени жизни (lifetime) в каждом фрагменте. Проверка MTU каждой линии связи путем заполнения первоначально обмененных пакетов приветствия. Проверка правильности информации в синхронизированной базе данных с помощью контрольных сумм, периодического перезапуска и описаний базы данных, которыми обмениваются промежуточные системы. IS-IS - это широко распространенный протокол маршрутизации, который доказал свою работоспособность в широком диапазоне сетевых топологий и эксплуатационных требований.
img
Для присоединения к другим телефонным станциям, в SoftX3000 создаются транковые группы разных типов. Для начала рассмотрим порядок создания SIP-транка, который чаще всего используется для подключения небольших АТС предприятий УПАТС. Для начала следует определиться с правилами нумерации транков и сопутствующих записей внутри нашей АТС. Например, пусть SIP-транки будут иметь нумерацию с 1 по 100, транки ОКС-7 со 101 п 199. В рамках одного транка все команды и записи удобно будет вести с одним номером, чтобы было проще ориентироваться в настройках позже. ADD OFC этой командой создаем направление. Здесь параметры имеют следующее назначение: Office direction number порядковый номер направления. На этот номер будем ссылаться в других команда и таблицах. Office direction name название направления. Для удобства идентификации можно указать любое название. Peer office type тип удаленной станции, может принимать значения: PBX - УПАТС СС местная сельская АТС CMPX местная городская и сельская АТС NATT междугородная АТС INTT международная АТС Peer office level - уровень противоположной станции по отношению к текущей. Значения: HIGH выше текущей станции SAME одного уровня LOW ниже текущей ADD SRT создаем подмаршрут, который будет привязан непосредственно к транку. Можно создать несколько подмаршрутов и объединить их в один маршрут: при проблемах с первым подмаршрутом в списке станция будет пытаться использовать следующий. Параметры команды: Sub-route number порядковый номер подмаршрута. Можно установить любой свободный номер, но предпочтительнее, чтобы он совпадал с номером OFC, заданный в предыдущей команде. Office direction number номер OFC, который задан в предыдущей команде. Sub-route name название подмаршрута любое удобное название. ADD RT создаем маршрут, в котором указываем один или несколько подмаршрутов, созданных предыдущей командой. Если указано несколько подмаршрутов, станция будет пытаться использовать первый в списке, если он не доступен, то следующий по списку. Параметры команды: Route number порядковый номер маршрута. Любое число, но, по договоренности, устанавливаем то же значение, что и в командах ранее. Route name произвольное название. 1 st sub-route первый подмаршрут. Указываем номер подмаршрута, созданного в предыдущей команде. Остальные параметры необходимы, если создано несколько подмаршрутов и необходимо настроить параметры выбора между ними. ADD RTANA правило выбора маршрута. Эта таблица определяет по какому маршруту будет направлен вызов, основываясь на многочисленных параметрах вызова, среди которых: категория абонента, тип А-номера, дополнительный атрибут абонента прочие. Параметры команды: Route selection code код выбора маршрута. На этот код ссылается запись в таблице префиксов CNACLD Route selection source code этот код является одним из параметров callsrc. Caller category категория абонента, задается при создании абонента в командах ADD VSBR или ADD MSBR. Caller category категория абонента, устанавливается в командах ADD VSBR или ADD MSBR в параметре Subscriber type. Так же можно применить данное свойство для транзитных вызовов, задав категорию в команде ADD CNACLR. Service attribute указывает, какие типы вызовов могут использовать данный маршрут (INTT - международные, NATT - междугородные, CITY - местные, ALL - любые) Caller access если необходимо, чтобы маршрут могли выбрать только абоненты ISDN, выбрать ISDN, если только не ISDN-абоненты, то NONISDN. Transmission capability тип поддерживаемого трафика (голос, данные, видео и прочее) Time index временной индекс. Если в станции используется маршрутизация по временным меткам. Если не используется, устанавливается значение по-умолчанию 0. Route number номер маршрута, который задан в команде ADD RT. Signaling as prior приоритет выбора подмаршрута в соответствии с типом сигнализации. Nature of callee address indicator тип вызываемого номера (International, National, Subscriber, ALL) Customized caller type дополнительный параметр абонента, который задается в командах ADD VSBR или ADD MSBR (Customized subscriber type) Called number Plan identity план нумерации вызываемого номера. Чтобы вызов прошел по данному маршруту, должны совпасть все условия. Чтобы какое-то условие игнорировалось при выборе маршрута, необходимо установить значение в ALL или значение по-умолчанию. Применение Пример 1 Допустим, у нас есть направление OFC=1, на которое ссылается подмаршрут SRT=1, на который, в свою очередь, ссылается маршрут RT=1. Допустим, это присоединение УПАТС, и все вызовы на это направление с любых источников должны проходить без ограничений. В таком случае создадим правило RTANA со следующими параметрами: В данном случае: Route selection code = 1 код выбора маршрута, который нужно указать в команде ADD CNACLD Route number указание на созданный ранее маршрут RT=1 Route selection source code параметр, задаваемый в callsrc. Значение остальных параметров установлены так, что при их любом значении вызов будет смаршрутизирован. Пример 2 Допустим, направление из предыдущего примера является выходом на оператора междугородной связи и доступ к нему могут получать лишь те абоненты, которые заключили с ним договор. Эти абоненты имеют отличительный признак - Customized subscriber type=8. В таком случае устанавливаем в параметре Customized caller type значение CUST8, и абоненты, у которых этот параметр отличается от CUST8 не смогут использовать данный маршрут. По такому же принципу работает ограничение и по другим параметрам. Пример 3 Если ограничивающие параметры не применимы для вызова (например, Customized subscriber type невозможно задать для вызовов, приходящих с другого транка), то и ограничения данных вызовов не произойдет. Чтобы ограничить транзитные вызовы со входящих транков, необходимо создать дополнительный callsource и задать в нем произвольный Route selection source code, отличный от значения по-умолчанию: Теперь, если мы назначим входящем транку созданный callsrc, то сможем применять Route selection source code для маршрутизации, указывая его в команде RTANA. Пример 4 Так же мы можем создать несколько правил RTANA с одним и тем же Route selection code, но разными параметрами, как в примере ниже: Здесь приведено правило RTANA для звонков на междугородные направления, а выбора маршрута осуществляется в зависимости от различных параметров вызова (в частности, Caller category и Customize subscriber type). ADD SIPTG создает транк-группу, в которой задается количество каналов, код источника вызова (для входящих вызовов), и номер подмаршрута, к которому привязана транк-группа. Trunk group number порядковый номер транк-группы Call source code код источника вызова, используется для маршрутизации входящих вызовов Sub-route number номер подмаршрута, указываем созданный ранее подмаршрут Maximum caller number restriction максимальное количество вызовов в транке. При достижении этого количества вызовов в транке, все последующие вызовы отбрасываются. Stop call restriction при снижении количества вызовов до числа, указанного в этой команде, ограничение вызовов, сработавшее по предыдущему параметру, снимается ADD SIPIPPAIR задает параметры непосредственного стыка с противоположным оборудованием (ip-адрес удаленной станции, локальный порт для приема сигнализации) Trunk group number порядковый номер транк-группы, указываем номер из предыдущей команды IFMI module number номер модуля IFMI в системе, можно узнать, дав команду LST BRD Local server port порт приема сигнализации SIP Remote URI 1 ip-адрес противоположной станции. Если sip-транк настраивается через SBC, здесь указывается loopback-интерфейс, который назначен транку.` ADD CNACLD этой командой задается префикс выхода на созданную транк-группу. Local DN set номер Local DN set, в которой будет находится префикс набора. Как правило, в станции только один Local DN set, указываем его номер Call prefix префикс набора, по которому вызовы будут направляться в созданное нами направление Service attribute тип исходящего вызова, принимает значения: LCO (Intra-officce) внутренние вызовы станции, LC (Local), LCT (Local toll) местные, NTT (National toll) междугородные (федеральные), ITT (International toll) международные, EMC экстренные вызовы. Route selection code код выбора маршрута, номер, указанный в команде RTANA. Minimum number length минимальная длина номера по данному префиксу Maximum number length максимальная длина номера по данному префиксу Charging selection code код источника тарификации. Настройка SIP -транка в пограничном контроллере сессий Huawei SE 2200 Общие правила настройки sip-транка в SBC Interface LoopBack 1 интерфейс, который указываем в SoftX3000 как противоположную станцию description test - trunk справочное название интерфейса ip address 192.168.33.1 255.255.255.255 адрес созданного интерфейса Interface LoopBack 2 интерфейс, который указываем в противоположной станции как адрес SoftX3000 description test - trunk справочное название интерфейса ip address 192.168.44.1 255.255.255.255 адрес созданного интерфейса acl number 3011 создаем список доступа rule 0 permit ip source 192168.55.1 0 разрешаем трафик от адреса противоположной станции rule 5 permit ip source 192.168.22.0 0.0.0.255 разрешаем трафик от SoftX3000 и сопутствующего оборудования (в этой сети, вероятно, так же будет UMG и прочее оборудование в составе SoftX3000) rule 10 deny ip запретить все прочие адреса Выше обозначенная группа команд необходима для обеспечения безопасности, на нашей сети используются другие методы и эти команды не используются и не проверялись автором. Здесь они приведены для полной информации о правильной последовательности настройки. sbc wellknowport clientaddr 192.168.33.1 sip 5060 разрешаем прием сигнализации SIP по порту 5060 на адресе 192.168.33.1 (от SoftX3000) sbc wellknowport clientaddr 192.168.44.1 sip 5060 разрешаем прием сигнализации SIP по порту 5060 на адресе 192.168.44.1 (от противоположной станции) sbc wellknowport softxaddr 192.168.22.1 sip 5060 обозначаем адрес SoftX3000. (Если SBC уже настроен ранее и работает, данная команда уже, вероятно, есть в конфигурации) sbc mapgroup intercom - ip 1001 создаем mapgroup в сторону SoftX3000 description == test - trunk == - справочное название clientaddr 192.168.44.1 адрес в сторону противоположной станции match acl 3011 проверка адресов согласно списка acl 3011 serveraddr 192.168.33.1 адрес в сторону SoftX softxaddr 192.168.22.1 - адрес SoftX3000 media - clientaddr 192.168.44.1 адрес в сторону противоположной станции media - serveraddr 192.168.33.1 адрес в сторону SoftX enable команда на активацию mapgroup sbc mapgroup intercom - ip 1002 создаем mapgroup в сторону противоположной станции description ==test-trunk== clientaddr 192.168.33.1 адрес в сторону SoftX match acl 3011 - проверка адресов согласно списка acl 3011 serveraddr 192.168.44.1 адрес в сторону противоположной станции softxaddr 192.168.55.1 - адрес противоположной станции media - clientaddr 192.168.33.1 адрес в сторону SoftX media - serveraddr 192.168.44.1 адрес в сторону противоположной станции enable команда на активацию mapgroup
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59