По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет описан процесс настройки SIP – транка на IP – АТС Asterisk с помощью в FreePBX 13 для провайдера Телфин.
Создание SIP - транка
Первый шаг является стандартным для настройки транка –в веб-интерфейсе необходимо открыть следующую вкладку: Connectivity – Trunks. Далее кликнуть на кнопку + Add Trunk.
Выберите «Add SIP (chan_sip) Trunk». Далее необходимо присвоить имя транку и задать исходящий CallerID
После, необходимо зайти во вкладку sip Settings и вновь ввести имя SIP - транка и информацию в поле Details:
Соответственно, Username – номер, полученный от провайдера Телфин, Secret – ваш пароль и host – адрес самого провайдера.
context=inbound_telphin
type=peer
username=4996546542 \тут должен быть ваш логин
fromuser=4996546542
secret=P@ssw0rd \тут должен быть ваш пароль
host=voice.telphin.com
port=5068
promiscredir=yes
Следующим шагом является настройка входящих параметров SIP - транка. Откроем вкладку Incoming, заполним поля “Context”, “Details”, “Register String”
type=peer
username=4996546542
host=voice.telphin.com
port=5068
И строка регистрации:
4996546542:P@ssw0rd@voice.tephin.com:5068/4996546542
Теперь ваша АТС будет регистрироваться у Телфина и входящие звонки будут приходить в контекст [inbound_telphin] на экстеншен 4996546542.
Исходящая маршрутизация
Далее необходимо задать имя маршрута и номер в Outbound Routes – номер такой же, как и при создании транка - в данном случае 4996546542.
Обратите внимание, так же необходимо указать транк в Trunk Sequence for Matched Routes, который был только что создан.
И, как финальный шаг, указываем правила набора для использования данного маршрута
После всех проведенных манипуляций, жмём Apply Config наверху страницы.
Для присоединения к другим телефонным станциям, в 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
В сегодняшней статье речь пойдет о проприетарном протоколе компании Cisco Systems - SCCP – (Skinny Client Control Protocol), который предназначен для построения корпоративных телефонных сетей на основе продуктов Cisco, таких как:
IP-Телефоны серии 7900
Софт-фоны Cisco IP communicator
Cisco Unified Communications Manager
Cisco Unity
Стоит заметить, что в телефонии существует ещё один протокол с абсолютно идентичной аббревиатурой – SCCP – Signalling Connection and Control Protocol, однако данный протокол относится к сигнализации ОКС-7, тогда как SCCP – (Skinny Client Control Protocol) работает в стеке TCP/IP.
Протокол SCCP занимает то же самое место в VoIP что и SIP, H.323 и MGCP и выполняет те же самые функции. Однако, в отличие от всех перечисленных протоколов, имеет гораздо более простой синтаксис и требует меньше компьютерных ресурсов для обработки своих сообщений.
Как и большинство VoIP протоколов SCCP предназначен для обмена сигнальными сообщениями между клиентом и сервером в процессе установления и завершения звонка.
В процессе передачи речевых данных SCCP не участвует, для этих целей служит протокол RTP - (Real-Time Transport Protocol). Кроме того, стоит отметить, что в SCCP не используется RTСP - (Real-Time Transport Control Protocol), который передает диагностическую информацию о текущем соединении. Для этих целей в SCCP имеются собственные механизмы.
Как уже было замечено, Протокол SCCP имеет очень простой синтаксис. По заголовку того или иного сообщения можно однозначно определить в каком статусе находится текущее соединение, что делает Протокол SCCP крайне удобным при траблшутинге. Для передачи сообщений SCCP используется TCP (Transmission Control Protocol) well-known порт 2000.
Соединение по SCCP невозможно рассматривать без сервера (чаще всего CUCM). SCCP имеет большое множество сообщений и отправляет их на сервер по каждому поводу, ожидая руководства к дальнейшим действиям. Выглядит это примерно так:
IP-Телефон: StationInit: Кто-то снял телефонную трубку
Сервер: StationD: Включи зуммер
Сервер: StationD: Выведи на дисплее сообщение “Введите номер”“
IP-Телефон: StationInit: Начинаю вызывать абонента, первая цифра его номера – “4”
IP-Телефон: StationInit: Вторая цифра – “7”
Каждое событие фиксируется вплоть до получения сервером сообщения о том, что телефонная трубка снова в исходном положении.
Обратите внимание, что сообщения SCCP отправляются как в сторону клиента, так и сторону сервера, поэтому для определения источника сообщения используются идентификаторы. StationInit, если источником является клиент и StationIniD, если источником является сервер телефонии. Таким образом появляется возможность в мельчайших деталях отследить любой звонок, совершенный внутри корпоративной сети.
Приведем пример некоторых сообщений SCCP:
0x0000 - Keep Alive Message – Отправляется от сервера к клиенту сразу после регистрации
0x0001 - Station Register Message – Запрос регистрации на сервере
0x0002 - Station IP Port Message – Отправляет клиент. Номер UDP порта для RTP сессии
0x0006 - Station Off Hook Message – Отправляет клиент. Снятие телефонной трубки
0x0099 - Station Display Text Message – Выводит на дисплей сообщение “Введите номер”
0x0082 - Station Start Tone Message – Включает зумер.
0x27 - Station Soft Key Event Message (new call/end call) – Если это начало вызова, то данное сообщение содержит первую цифру номера вызываемого абонента. Может также содержать промежуточные цифры номера, а также запрос на разрыв соединения (end call)
0x107 - Station Connection Statistics Request Message – Отправляется клиентом. Запрос диагностической информации (информации о задержках и потерях медиа-пакетов, джиттер-буфере, принятых и отправленных пакетах и т.д. ). Это тот самый механизм, который компенсирует отсутствие RTCP.
Как видно из данного примера, MessageID каждого сообщения крайне точно описывает соответствующее ему событие, поэтому чтение трассировок SCCP обычно не составляет труда.
Стоит также добавить, что некоторые компании, занимающиеся разработкой голосовых решений, такие как: Digium, SocketIP и Symbol Technologies, добавили поддержку протокола SCCP в свои продукты.