что такое sip uri
RFC SIP
Тем, кто соберётся делать собственную реализацию протокола SIP, пригодится список RFC, описывающих протокол и его дополнения:
SIP- запросы
Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:
Адресация SIP
SIP- адреса бывают четырех типов:
В начале SIP- адреса ставится слово «sip:», указывающее, что это именно SIP- адрес. Примеры SIP- адресов:
В SIP поддерживает функции messaging и presence. Первая обеспечивает обмен в реальном времени короткими сообщениями (как ICQ на ПК или SMS в сетях GSM), вторая позволяет определять состояние абонента, т. е. на месте ли он, не занят ли и т. д. (в ICQ тоже есть такая возможность). Благодаря этим двум функциям SIP позволяет реагировать на события, а также рассылать сообщения «по событию».
IP-интеграция
Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.
Поскольку все современные ERP-, CRM- и т. п. системы работают по протоколу IP, SIP без особых проблем интегрируется с ними (в отличие от H.323, которому его телефонная природа мешает взаимодействовать с большинством приложений).
Сценарий установления соединения
между пользователями
Первый пользователь снимает трубку и набирает номер, SIP-клиент генерирует сигнал INVITE (приглашение), у второго пользователя звонит телефон, его SIP-клиент выдает сообщение 180 (Ringing, звонок), затем пользователь берет трубку, SIP-клиент выдает сообщение 200 (OK), первый SIP-клиент посылает второму сигнал ACK (подтверждение) – и далее начинается передача голосового потока по протоколу RTP (Real-time Transport Protocol). Когда разговор окончен и один из пользователей вешает трубку, SIP-клиент посылает сигнал BYE. Вот и все.
в сети предприятия
Но такая схема абсолютно неэффективна, когда клиентов в сети не два, а два миллиарда. SIP-сетям с большим числом пользователей необходима инфраструктура, и ее создают различные серверы SIP. Сервер регистрации (registrar) занимается учетом и авторизацией пользователей, сервер локализации (allocation) ищет их и определяет их местонахождение, сервер переадресации (redirect) переводит звонки абонентам туда, где они фактически находятся в данный момент, – если меня, например, нет в Москве, потому что я уехал в Америку, сервер переведет звонок на мой американский номер. Наиболее сложные функции ложатся на прокси-сервер (SIP Proxy), обеспечивающий взаимодействие внутренней (например, учрежденческой) IP-телефонной сети с внешним миром, – именно он определяет все политики, правила общения и т. д. Существуют и другие серверы SIP (например, сервер конференций), но они менее важны. На рисунке показано, как может работать SIP в сети предприятия.
Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.
Аутентификация и авторизация SIP 2.0
Прохождение авторизации в SIP протоколе зависит от «Что такое realm sip?», различного для каждого защищаемого домена.
md5 алгоритм на входе принимает любую длину символов и на выходе выдать 128-битный отпечаток (finger-print) или профиль сообщения (message digest), которое было подано на вход алгоритма. Гипотетически считается, что два сообщения, которые имеют один и тот же профиль сообщения или выработаны любым сообщением, имеют определенный профиль сообщения.
Message digest — коротка цифровая строка фиксированной длины, формируется из более длинного сообщения с использованием специального алгоритма. Алгоритм md5 назначен для цифровой подписи (digital signature) приложений, где большие файлы должны быть «сжаты» в безопасный способ, до того как они будут закриптованы с помощью публичного или скрытого ключа с помощью криптосистемы с открытым ключом, например RSA. Digital signature — цифровая подпись, которая является уникальным электронным идентификатором, обеспечивающим проверку сообщения с установлением подлинности отправителя и гарантии то, что документ не был изменен с момента подписания.
Последовательность действий для авторизации клиентского оборудования на сервере.
На третьем этапе абонент высылает серверу строку в сообщении REGISTER
Взаимодействие клиентов SIP. Часть 2
В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Начало разговора
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
Конец разговора
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
SIP-регистрация
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Bonus для тех, кому интересно
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
Звонки с помощью SIP URI
Задача:Обеспечить возможность входящих звонков по протоколу SIP без авторизации, используя адресацию SIP URI. Звонки могут осуществлять softphone, которые могут звонить без регистрации (например: PhoneLite) или различные веб-сервисы. Что такое SIP URI? SIP URI – это схема адресации SIP, используемая для вызова абонента с помощью SIP. Другими словами, SIP URI является номером SIP-телефона пользователя. SIP URI […]
Задача:
Обеспечить возможность входящих звонков по протоколу SIP без авторизации, используя адресацию SIP URI. Звонки могут осуществлять softphone, которые могут звонить без регистрации (например: PhoneLite) или различные веб-сервисы.
Что такое SIP URI?
SIP URI – это схема адресации SIP, используемая для вызова абонента с помощью SIP. Другими словами, SIP URI является номером SIP-телефона пользователя. SIP URI похож на адрес электронной почты и записывается в следующем формате.
Запись SRV, заданная на сервере доменных имен (DNS), помогает соединиться с SIP пользователем, так же как MX запись помогает доставить электронную почту на сервер адресата. Когда вы отправляете почту на адрес «john@example.com», тогда MX запись для домена example.com может указать агенту, отвечающему за доставку почты, совсем другую машину, которая является почтовым сервером для этого домена, например, «zaphod.foobar.com». Подобным образом, когда вы хотите совершить вызов на SIP телефон: запись типа SRV, может сказать Вашему компьютеру, что для этого следует подключиться к хосту «galaxy.starsystem.tw».
Target — адрес вашего сервера
В Asterisk есть мощный механизм для хранения значений, который называется базой данных Asterisk (AstDB). AstDB обеспечивает простой способ хранения данных для использования в диалплане. AstDB хранит данные в группах, которые называются семействами. Семейства определяются ключами. Например, у нас есть семейство cids, мы бы могли хранить только одно значение с ключом tamik. Каждое хранящееся значение должно быть соотносимо с каким-то семейством.
Заходим в консоль asterisk
tamik – key, имя сотрудника на которое будут звонить
102 — значение, внутренний номер сотрудника.
database show cids
В файле /etc/asterisk/sip.conf добавим строки:
Context = outcolling — контекст в котором будут обрабатываться неавторизованные пользователи
Allowguest = yes — разрешение гостевых вызовов
В файле /etc/asterisk/extensions.conf пропишем следующие:
[outcolling] — название контекста
exten => tamik,1,GoSub(sub-name,s,1($
exten => s,1,NoOp($
same => n,NoOp($
same => n,GotoIf($[«$
same => n,Dial(SIP/$
same => n,Hangup() — а тут мы сбрасываем вызов.
Сохраняем все и снова заходим в консоль астериска и перезагружаем настройки:
sip reload — перезагружает настройки sip
dialplan reload — перезагружает настройки диалплана из файла extensions.conf
Вывод: Мы поняли что такое sip uri, настроили сервер Asterisk на принятие вызовов по sip uri, научились работать с AstDB.
Интерфейсы 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 время пакетизации необходимо установить минимальным;