sip diversion что это
Взаимодействие клиентов SIP. Часть 1
Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.
Чтобы не перегружать читателя, я решил разбить статью на две части. В первой части мы рассмотрим работы протокола SIP при взаимодействии двух клиентов.
Простое взаимодействие клиентов
Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.
Диалог – это равноправное взаимодействие двух User Agent (UA) в виде последовательности SIP-сообщений между ними. При этом, существуют запросы, не образующие диалогов. Однако обо всем по-порядку.
Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:
Петр хочет начать обмен сообщениями с Иваном, для этого он посылает INVITE-сообщение с данными о типе сессии (простая, мультимедиа и т.д.). Сообщения имеют следующий формат: стартовая строка, одно или несколько полей заголовка, пустая строка, обозначающая конец полей заголовка и необязательное тело сообщения.
Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.
Поля заголовков имеют следующий формат: :
Первая строка начинается с заголовка Via. Каждое SIP-устройство, создающее или пересылающее сообщение, добавляет свой адрес в поле Via (как это происходит, я планирую показать в следующей части статьи). Обычно адрес представляет собой имя хоста, которое может быть разрешено с помощью DNS-запроса. Поле Via содержит версию SIP, знак “/”, пробел, транспортный протокол (UDP, TCP, TLS, SCTP), двоеточие, номер порта и branch – идентификатор транзакции. Ответы на этот запрос будут содержать такой же номер транзакции.
Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.
Следующее поле, Max-Forwards, содержит относительно большое целое число. Каждый сервер SIP, который пересылает сообщение, уменьшает это число на единицу. Данное поле обеспечивает простой механизм обнаружение петель (loop).
Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.
Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.
Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.
Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.
Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны. Это поле используется, чтобы из всех устройств, которыми одновременно может пользоваться Петр, ответ был отправлен именно на данное устройство. Обратите внимание на значения полей From и Contact. Первый раз я не заметил разницу:
В сообщении присутствует опциональное поле Subject, то есть тема сообщения. Некоторые SIP-клиенты могут выводить значение этого поля на экран. Для маршрутизации и идентификации диалога поле не используется и может быть произвольным.
Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки:
Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:
В ответ на INVITE SIP-клиент Ивана отправляет два сообщения: 180 Ringing и 200 OK. Первое сообщает, что на стороне Ивана SIP-клиент подает звуковой сигнал звонка, второе – подтверждает установку диалога. Разберемся с каждым из них.
Так будет выглядеть сообщение 180 Ringing:
Бледным выделен текст, который не изменился по сравнению с сообщением INVITE.
Обратите внимание на поля заголовков To и From. Несмотря на то, что данное сообщение идет со стороны Ивана, значения полей остаются такими же, как были в первоначальном запросе (от Петра к Ивану). Это объясняется тем, что данные поля определяют направление запроса, а не сообщения.
Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.
Как я и обещал, в поле To добавился tag, идентифицирующий диалог. Все последующие сообщения в рамках диалога будут содержать неизменные значения tag.
Наконец, в поле Contact содержится актуальный адрес Ивана.
Так выглядит сообщение 200 ОК, которое отправил SIP-клиент Ивана:
Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.
В ответ на 200 ОК клиент Петра отправляет подтверждение:
Данное сообщение подтверждает, что клиента Петра успешно получил ответ от клиента Ивана. Оба клиента договорились о параметрах меди-сессии, которая будет осуществляться по протоколу RTP.
Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.
Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:
Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:
Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).
В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.
Использование дополнительного поля в SIP протоколе «Diversion» или просто RDNIS
RDNIS – Redirected Dialed Number Identification Service. В простой терминологии «промежуточный номер при переадресации». Получить данное значение от оператора связи 2-я способами: При подключении по потоку Е1. При подключении по SIP протоколу.
Сразу хочу сказать, что получение данной информации есть дополнительным информационным сообщением в том или ином протоколе сигнализации. Соответственно оператор связи оставляет за собой право передачи данной информации клиенту, плюс что не мало важно напрямую зависит от промежуточного оборудование в которое включен клиент.
Сразу скажу, что ТП оператора связи моего корпоративного подключения подразумевают нетарифицированный обьем услуг на другие сети и сети фиксированной связи.
Со временем 8-и портового шлюза стало не достаточно, приобретать дополнительный шлюз не было рационально, я начал изучать вопрос RDNIS.
Задав вопрос оператору связи, я был включен по DSS1, поток PRI о возможности подставить данную информацию в мой поток, на что мне оператор ответил что необходимо стыковаться по ОКС 7. Да, Asterisk в open source поддерживает ОКС 7, но:
В связи с этим данным способ не подходит.
Есть второй вариант и это в SIP сообщении дополнительное поле Diversion.
Задав вопрос о возможном включении по SIP. Ответ положителен от оператора связи. Номер получил фиксированной связи, потому как мобильные маски строго под сеть GSM. Произвели включение и проверяем получаем ли мы необходимую информацию.
Настройка подключения оператора связи по SIP:
sip.conf
[general]
register => 151515:[email protected]/151515
Настройка маршрутизации звонков:
При входящем звонке проверяем на доп. поле и если оно есть, то обращаемся к БД что бы узнать действительно ли сотрудник установил переадресацию и если «да», то производим набор через оператора который предоставляет международное направление (с возможностью подстановки clip). Что в данном случаи вообще великолепно для сотрудника находящегося в роуминге.
INVITE sip:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKnkoj7ljjo88bl7hoy7vi7e788
User-Agent: Huawei SoftX3000 V300R010
o=HuaweiSoftX3000 29333672 29333672 IN IP4 1.1.1.1
m=audio 40384 RTP/AVP 8 101
Как видим, SIP Header Diversion отсутствует.
INVITE sip:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKev7hvxbjncukvj8hy7hkycncl
User-Agent: Huawei SoftX3000 V300R010
Diversion: Anonymous ;reason=unconditional;counter=1
o=HuaweiSoftX3000 29333914 29333914 IN IP4 1.1.1.1
m=audio 40640 RTP/AVP 8 101
Вот что нам было и необходимо.
Александр Чалый, специально для «Вокс Линк»
Sip diversion что это
Помогите решить мою задачку.
Есть 13 астериск с каналом PJSIP.
Подключен SIP-T на Ростелеком.
Два внутренних номера. Звонки ходят наружу внутри и т.д.
Соответственно аппарат кидает в Астериск такой пакетик
SIP/2.0 302 Moved Temporarily
и добавляет строку:
Diversion : ;reason=unconditional
В поле From идет внешний номер, на который сделана переадресация (все гут).
Ростелеком говорит, что в Diversion должен быть номер который изначально пришел на астериск или вообще убрать поле Diversion.
И вот чтобы я ни делал я не могу:
Убрать Diversion
Изменить поле Diversion
Прочитать поле Diversion
Пытался это делать я с помощью PJSIP_HEADER.
Более того, PJSIP_HEADER даже не может ничего прочитать из заголовка, при этом ошибок в консоли нет.
В других случаях PJSIP_HEADER работает исправно, только для Invite после Moved Temporarily не работает.
У кого какие идеи как подправить/удалить поле Diversion из Invite или как-то иначе выйти из положения?
Спасибо.
Re: Переадресация с аппарата наружу через SIP-T
На канале SIP и астериске 1.8 данная штука полечилась добавлением оператора:
SIPAddHeader(Diversion:222333;reason=no-answer);
При этом в SIP-T улетало два поля Diversion.
Попытки удалить строку Diversion от телефона в диалплане не увенчались успехом.
Re: Переадресация с аппарата наружу через SIP-T
2) Манипулировать SIP заголовками можно и нужно, не только через SIPAddHeader
3) лучше бы переадресацию делать средствами станции, сервисный код
Call Forward All Activate *72
и там много ещё
Re: Переадресация с аппарата наружу через SIP-T
1) Необходимость использования PJSIP:
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
— Можно хоть каждого SIP клиента посадить на свой порт, особенно актуально когда много удаленных офисов, хотя можно обойтись и каналом SIP.
— Сообщество движется в сторону PJSIP и скорее всего переход произойдет.
2) Даже при использовании канала SIP, он не может удалить Diversion, прилетающий с телефона (только доьавить еще один). При использовании PJSIP функции SIP_HEADER нет. К тому же SIP_HEADER не может изменить заголовок.
Спасибо за рассмотрение других вариантов, но тем не менее остается, что функциия PJSIP_HEADER в разных ситуациях работает непредсказуемо..
Re: Переадресация с аппарата наружу через SIP-T
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
— Можно хоть каждого SIP клиента посадить на свой порт, особенно актуально когда много удаленных офисов, хотя можно обойтись и каналом SIP.
— Сообщество движется в сторону PJSIP и скорее всего переход произойдет.
Re: Переадресация с аппарата наружу через SIP-T
ЗЫ: интересно, считается это багом и куда его можно заявить?
Re: Переадресация с аппарата наружу через SIP-T
Re: Переадресация с аппарата наружу через SIP-T
Re: Переадресация с аппарата наружу через SIP-T
Уф решено! Мир стоит!
В 1.8 send_diversion ни как не влияло.
В итоге функция PJSIP_HEADER работает исправно во всех случаях. Влияла опция send_diversion на канале SIP-T.
Если ее не поставить в send_diversion=no, то поле diversion перезаписывается независимо от бубнов с PJSIP_HEADER.
Re: Переадресация с аппарата наружу через SIP-T
1) Необходимость использования PJSIP:
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
FreePBX Advanced Settings
Расширенные установки FreePBX
Advanced Settings Details
Display Friendly Name
Display Readonly Settings
Эта опция отображает установки, которые имеют статус только для чтения. Эти параметры обычно предназначены только для внутреннего пользования, и неинтересны большинству обычных пользователей. Так как они в статусе только для чтения, их можно только видеть.
AS_DISPLAY_READONLY_SETTINGS
Override Readonly Settings
Установка этой опции в true позволяет редактировать значения в статусе только для чтения.
AS_OVERRIDE_READONLY
Asterisk Builtin mini-HTTP server
Встроенный HTTP сервер. Подходит для небольших HTML конфигурационных файлов.
Enable Static Content
— true/false
Enable the mini-HTTP Server
— true/false
HTTP Bind Address
HTTP Bind Port
HTTP Prefix
Asterisk Manager
Asterisk Manager Host
Имя хоста для интерфейса Asterisk Manager (AMI )
ASTMANAGERHOST
Asterisk Manager Password
AMPMGRPASS
Asterisk Manager Port
— 5038
Asterisk Manager Proxy Port
— blank
Asterisk Manager User
— admin
Asterisk Manager Write Timeout
— 5000
Call Flow Control Module
Hook Time Conditions Module
DAYNIGHTTCHOOK
DAHDi Configuration Module
Allow PRI Discrete Channels
Конфигурация транка DAHDi предполагает использование каналов в группе для PRI. Установка значения true позволит настроить каждый канал в отдельности. Это может быть полезно при поиске проблем в PRI и помочь изолировать плохой B канал.
Интерфейсы SIP
В данном разделе настраиваются общие параметры конфигурации стека SIP, индивидуальные настройки для каждого направления, работающего по протоколу SIP/SIP-Т/SIP-I, и профили SIP абонентов.
Протокол SIP (Session Initiation Protocol) – протокол сигнализации, используемый в IP-телефонии. Обеспечивает выполнение базовых задач управления вызовом, таких как открытие и завершение сеанса.
Адресация в сети SIP основана на применении схемы SIP URI:
sip:user@host:port;uri-parameters user – номер абонента SIP;
@ – разделитель между номером и доменом абонента SIP;
host – домен, либо IP-адрес абонента SIP;
port – UDP-порт, на котором запущена служба SIP-абонента;
uri-parameters – дополнительные параметры.
Одним из дополнительных параметров SIP URI является параметр user=phone. Если этот параметр присутствует, то синтаксис номера абонента SIP (в части user) должен соответствовать синтаксису TEL URI, описанному в RFC 3966. В этом случае будут обрабатываться запросы, в номере абонента SIP которых будут присутствовать символы «+», «;», «=», «?», а также при использовании протокола SIP-T, если будет производиться вызов на международный номер, Коралл-РА добавит символ «+» перед номером вызываемого абонента автоматически.
Протоколом SIP определено два типа ответов на запрос, инициирующий соединение (INVITE) – предварительные и окончательные. Ответы класса 2хх, 3хх, 4хх, 5хх и 6хх являются окончательными и передаются надежно – с подтверждением их сообщением АСК. Ответы класса 1хх, за исключением ответа 100 Trying, являются предварительными и передаются ненадежно – без подтверждения (rfc3261). Эти ответы содержат информацию о текущей стадии обработки запроса INVITE, а в протоколе SIP-T/SIP-I в ответы класса 1хх инкапсулируются сообщения ОКС-7, вследствие чего потеря этих ответов нежелательна. Использование надежных предварительных ответов также предусмотрено протоколом SIP (rfc3262) и определяется наличием тега 100rel в инициирующем запросе, в этом случае предварительные ответы подтверждаются сообщением PRACK.
Максимально возможно создать до 255 интерфейсов. Для создания, редактирования и удаления интерфейсов SIP/SIP-T используется меню «Объекты» – «Добавить объект», «Объекты» – «Редактировать объект» и «Объекты» – «Удалить объект», а также кнопки:
Сигнальный процессор шлюза выполняет функции кодирования аналогового речевого трафика, данных факса/модема в цифровые сигналы, а также обратного декодирования. Шлюз поддерживает следующие кодеки: G.711 (A/U), G.729 (A/B).
G.711 – представляет собой ИКМ-кодирование без сжатия речевой информации. Данный кодек должен быть обязательно поддержан всеми производителями VoIP-оборудования. Кодеки G.711A и G.711U отличаются друг от друга законом линейного кодирования (А-закон и U-закон).
G.729 – кодек со сжатием речевой информации, имеет скорость передачи 8 Кбит/с, поддерживает детектор речевой активности и обеспечивает генерацию комфортного шума (Annex B).
Параметры STUN-сервера и Public IP:
Сетевой протокол STUN (RFC 5389) позволяет приложениям, находящимся за сервером трансляции адресов NAT, определить свой внешний IP-адрес и порт, связанный с внутренним портом. Используется в случае, если Коралл-РА находится за NAT. Для определения внешнего адреса может использоваться либо STUN, либо Public IP, но не одновременно.
Перед отправкой сигнального сообщения с интерфейса отправляется запрос (Binding Request) на STUN-сервер, в ответном сообщении (Binding Response) STUN-сервер сообщает внешний IP-адрес и port (UDP) устройства, которые Коралл-РА использует при формировании сигнальных сообщений.
Запросы на STUN-сервер формируются перед каждой отправкой сигнального сообщения SIP, но не чаще, чем сконфигурированное время периода запросов.
В режиме интерфейса «SIP-профиль» настройка Public IP не используется.
Вкладка «Настройка протокола SIP»
Настройка опций для про то ко лов SIP/SIP-T/SIP-I.
Данные методы также выполняют функцию поддержания соединения на NAT.
Настройка опций для режима SIP-профиль.
Данные методы также выполняют функцию поддержания соединения на NAT.
– Детектор активности речи / Генератор комфортного шума (VAD/CNG) – при установленном флаге детектор тишины и генератор комфортного шума включены. Детектор активности речи позволяет отключать передачу разговорных пакетов RTP в моменты молчания, тем самым уменьшая нагрузку в сети передачи данных;
– Контроль IP:Port источника RTP – при установленной настройке контролируется поступление медиа трафика с IP-адреса и UDP-порта указанных в описании сеанса связи SDP, иначе принимается трафик с любого IP-адреса и UDP-порта;
– Эхокомпенсация – режим эхокомпенсации:
– voice(default) – эхокомпенсаторы включены в режиме передачи голосовой информации;
– voice nlp-off – эхокомпенсаторы включены в голосовом режиме, нелинейный процессор NLP выключен. В случае, когда уровни сигналов на передаче и приеме сильно различаются, слабый сигнал может быть подавлен нелинейным процессором NLP. Для предотвращения подавления используется данный режим работы эхокомпенсаторов;
– modem – эхокомпенсаторы включены в режиме работы модема (фильтрация постоянной составляющей сигнала выключена, контроль процессором NLP выключен, генератор комфортного шума выключен);
– off – не использовать эхокомпенсацию (данный режим установлен по умолчанию);
– DSCP для RTP – тип сервиса (DSCP) для RTP и UDPTL (T.38) пакетов;
– Таймаут ожидания RTP-пакетов – функция контроля состояния разговорного тракта по наличию RTP-трафика от взаимодействующего устройства. Диапазон допустимых значений от 10 до 300 секунд. При снятом флаге контроль RTP выключен, при установленном – включен. Контроль осуществляется следующим образом: если в течение данного таймаута от встречного устройства не поступает ни одного RTP-пакета и последний пакет не был пакетом подавления пауз, то вызов отклоняется;
– Таймаут ожидания RTP-пакетов после получения Silence-Suppression (множитель) – таймаут ожидания RTP-пакетов при использовании опции подавления пауз. Диапазон допустимых значений от 1 до 30. Коэффициент является множителем и определяет, во сколько раз значение данного таймаута больше, чем «Таймаут ожидания RTP-пакетов». Контроль осуществляется следующим образом: если в течение данного времени от встречного устройства не поступает ни одного RTP-пакета и последний пакет был пакетом подавления пауз, то вызов отклоняется;
– Период передачи пакетов RTCP (с) – период времени в секундах (5-65535 c.), через который устройство отправляет контрольные пакеты по протоколу RTCP. При отсутствии установленного флага протокол RTCP не используется;
– Контроль активности сессии по протоколу RTCP – функция контроля состояния разговорного тракта, принимает значения из диапазона 5-65535. Количество интервалов времени (RTCP timer), в течение которого ожидаются пакеты протокола RTCP со встречной стороны. При отсутствии пакетов в заданном периоде времени установленное соединение разрушается. При этом в сторону TDM и IP-протоколов устанавливается причина разъединения «cause 3 No route to destination». Значение контрольного периода определяется по формуле: RTCP timer * RTCP control period секунд. При отсутствии установленного флага функция выключена;
– Clear Channel – канал, организованный для прозрачной передачи цифровых данных, при организации такого канала устройство не пытается его перекодировать, а передает прозрачно. Для организации такого соединения необходимо получение поля «Transmission Medium Requirement» со значениями:
– restricted digital info (протокол Q.931);
– unrestricted dig.info (протокол Q.931);
– video (протокол Q.931);
– 64 kbit/s unrestricted (протокол ОКС-7).
– Clear Channel override – при установленном флаге при организации clear channel в SDP будет указан только один кодек CLEARMODE, если на первом плече вызова была запрошена работа по Clear Channel. Если флаг не установлен, то в SDP всегда будет передаваться весь список выбранных кодеков в порядке приоритета;
– ClearChannel-transit – это режим, позволяющий напрямую передавать RTP из входящего плеча соединения в исходящее в случае соединения SIP – SIP, минуя внутренние шины коммутации устройства, тем самым полностью сохраняя исходный RTP-трафик, в том числе и время пакетизации.
Цифровое усиление.
– Усиление сигнала на приеме (0.1 dB) – громкость принимаемого сигнала, усиление/ослабление уровня сигнала, принятого от взаимодействующего шлюза;
– Усиление сигнала на передаче (0.1 dB) – громкость передаваемого сигнала, усиление/ослабление уровня сигнала, передаваемого в сторону взаимодействующего шлюза.
AGC (Auto Gain Control).
– Соответствие с ITU-T G.169 – при активации опции автоматическое усиление начинает работать в соответствии с требованием ITU-T G.169. Режим работы по-умолчанию использует несколько отличные от рекомендации алгоритмы, обепечивающие лучшее подавление фонового шума в отсутствии речи.
Параметры усиления на приеме.
– Включить усиление – активировать автоматическое усиление сигнала в приёмном тракте;
– Ограничить во время одновременного разговора – ограничить уровень усиления, если абоненты говорят одновременно;
– Номинальный уровень сигнала, dBm0 – уровень сигнала, к которому будет стремиться усиление;
– Максимальное значение усиления, dB – максимально допустимое значение усиления исходного сигнала;
– Минимальное значение усиления, dB – минимально допустимое значение усиления исходного сигнала;
Параметры усиления на передаче.
– Включить усиление – активировать автоматическое усиление сигнала в передающем тракте;
– Ограничить во время одновременного разговора – ограничить уровень усиления, если абоненты говорят одновременно;
– Номинальный уровень сигнала, dBm0 – уровень сигнала, к которому будет стремиться усиление;
– Максимальное значение усиления, dB – максимально допустимое значение усиления исходного сигнала;
– Минимальное значение усиления, dB – минимально допустимое значение усиления исходного сигнала;
Прием/передача DTMF.
Для возможности использования донабора во время разговора убедитесь, что аналогичный метод передачи сигналов DTMF настроен на встречном шлюзе!
– Обработка сигнала Flash (RFC2833) – флаг активации обработки сигнала FLASH методами INFO, frc2833 и re-invite для работы услуги ДВО «Передача вызова»;
– RFC2833 PT – тип динамической нагрузки, используемой для передачи пакетов DTMF по RFC2833. Разрешенные для использования значения – от 96 до 127. Рекомендация RFC2833 определяет передачу сигналов DTMF посредством RTP-протокола. Данный параметр должен согласовываться с аналогичным параметром взаимодействующего шлюза (наиболее часто используемые значения: 96, 101);
– Одинаковый RFC2833 PT – при установленном флаге в случае, когда SMG является стороной, отправившей offer SDP, на прием ожидаются пакеты RFC2833 со значением PT, отправленным нам в answer SDP, иначе – на прием ожидаются пакеты RFC2833 с тем значением PT, которое SMG отправило в offer SDP;
– DTMF MIME Type – тип нагрузки, используемый для передачи DTMF в пакетах INFO протокола SIP:
– application/dtmf-relay – в пакетах INFO application/dtmf-relay протокола SIP (* и # передаются как символы * и #);
– application/dtmf – в пакетах INFO application/dtmf протокола SIP (* и # передаются как числа 10 и 11).
Параметры jitter-буфера.
– Режим – режим работы джиттер-буфера: фиксированный либо адаптивный;
– Минимальный размер, мс – размер фиксированного джиттер-буфера либо нижняя граница (минимальный размер) адаптивного джиттер-буфера. Диапазон допустимых значений от 0 до 200 мс;
– Начальный размер, мс – начальное значение адаптивного джиттер-буфера. Диапазон допустимых значений от 0 до 200 мс;
– Максимальный размер, мс – верхняя граница (максимальный размер) адаптивного джиттер-буфера в миллисекундах. Диапазон допустимых значений от «минимального размера» до 200 мс;
– Период адаптации, мс – время адаптации буфера к нижней границе при отсутствии нарушений в порядке следования пакетов;
– Режим удаления – режим адаптации буфера. Определяет, каким образом будут удаляться пакеты при адаптации буфера к нижней границе:
– Soft – используется интеллектуальная схема выбора пакетов для удаления, превысивших порог;
– Hard – пакеты, задержка которых превысила порог, немедленно удаляются;
– Порог удаления, мс – порог немедленного удаления пакетов в миллисекундах. При росте буфера и превышении задержки пакета свыше данной границы пакеты немедленно удаляются. Диапазон допустимых значений от максимального размера до 500 мс;
– Режим подстройки – выбор режима подстройки адаптивного джиттер-буфера при его увеличении (плавный/моментальный);
– Размер для VBD, мс – размер фиксированного джиттер-буфера, используемого при передаче данных в режиме VBD (модемной связи). Диапазон допустимых значений от 0 до 200 мс;
Кодеки.
В данном разделе можно выбрать кодеки для интерфейса и порядок, в котором они будут использоваться при установлении соединения. Кодек с наивысшим приоритетом необходимо установить в верхней позиции.
При нажатии левой кнопкой мыши строка с выбранным кодеком подсвечивается. Для изменения приоритета кодеков используются стрелки (вниз, вверх).
– Включить – при установленном флаге использовать кодек, указанный в поле напротив;
– Кодек – кодек, используемый для передачи голосовых данных. Поддерживаемые кодеки G.711A, G.711U, G.729A, G.729B, G.723.1, G.726-32.
При включенном VAD/CNG кодек G.729 работает как G.729B, иначе как G729A, а кодек G.723.1 работает c поддержкой annex А, иначе – без поддержки annex А.
– PType – тип нагрузки для кодека. Поле доступно для редактирования только при выборе кодека G.726 (разрешенные для использования значения – от 96 до 127, либо 2 для согласования с устройствами, не поддерживающими динамический тип нагрузки для данного кодека). Для остальных кодеков назначается автоматически;
– PTE – время пакетизации – количество миллисекунд (мс) речи, передаваемых в одном пакете.
Вкладка «Настройка факса и передача данных».
Передача данных:
– Использовать VBD – при установленном флаге создать канал VBD согласно рекомендации V.152 для передачи модема. При детектировании сигнала CED осуществляется переход в режим Voice band data. Снятие флага отключает детектирование тонов модема, но не запрещает передачу модема (не будет инициироваться переход на кодек модема, но данный переход может быть осуществлен встречным шлюзом);
– Кодек VBD – кодек, используемый для передачи данных в режиме VBD;
– Тип нагрузки VBD – тип нагрузки, используемый для передачи данных в режиме VBD:
– Static – использовать стандартное значение типа нагрузки для кодека (для кодека G.711A – тип нагрузки 8, для кодека G.711U – тип нагрузки 0);
– 96-127 – типы нагрузки из динамического диапазона.
Передача факса:
– Режим детектирования – определяет направление передачи, при котором детектируются тоны факса, после чего осуществляется переход на кодек факса:
– no detect fax – отключает детектирование тонов факса, но не запрещает передачу факса (переход на кодек факса инициироваться не будет, но данный переход может быть сделан встречным шлюзом);
– Caller and Callee – детектируются тоны как при передаче факса, так и при приеме. При передаче факса детектируется сигнал CNG FAX с абонентской линии. При приеме факса детектируется сигнал V.21 с абонентской линии;
– Caller – детектируются тоны только при передаче факса. При передаче факса детектируется сигнал CNG FAX с абонентской линии;
– Callee – детектируются тоны только при приеме факса. При приеме факса детектируется сигнал V.21 с абонентской линии;
Сигнал V.21 может быть задетектирован и от передающего факса.
– Режим передачи – выбор протокола для передачи факса;
– Максимальная скорость факса, передаваемого по протоколу Т.38 – максимальная скорость факса, передаваемого по протоколу Т.38. Данная настройка влияет на возможности шлюза работать с высокоскоростными факсимильными аппаратами. Если факсимильные аппараты поддерживают передачу на скорости 14400, а на шлюзе настроено ограничение 9600, то максимальная скорость соединения между факсимильными аппаратами не сможет превысить 9600 бод. Если наоборот, факсимильные аппараты поддерживают передачу на скорости 9600, а на шлюзе настроено ограничение 14400, то данная настройка не окажет влияние на взаимодействие, максимальная скорость будет определяться возможностями факсимильных аппаратов;
– Метод обработки тренировочной последовательности TCF:
– local TCF – метод требует, чтобы подстроечный сигнал TCF генерировался приемным шлюзом локально. Обычно используется при передаче Т.38 по ТСР;
– transferred TCF – метод требует, чтобы подстрочный сигнал TCF передавался с передающего устройства на приемное. Обычно используется при передаче Т.38 по UDP;
– Удаления и вставки битов заполнения для данных Т.38 – удаления и вставки битов заполнения для данных, не связанных с ЕСМ (режимом коррекции ошибок);
– Величина избыточности в пакетах данных Т.38 – величина избыточности в пакетах данных Т.38 (количество предыдущих пакетов в последующем пакете Т.38). Введение избыточности позволяет восстановить переданную последовательность данных на приеме в случае, если были потери среди переданных пакетов;
– Время пакетизации для протокола Т.38 – определяет частоту формирования пакетов Т.38 в миллисекундах (мс). Данная настройка позволяет регулировать размер передаваемого пакета. Если взаимодействующий шлюз может принимать дейтаграммы с максимальным размером в 72 байта (maxdatagrammSize: 72), то на SMG время пакетизации необходимо установить минимальным;