Дерево страниц
Перейти к концу метаданных
Переход к началу метаданных

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

Может быть создано до 256 направлений.

Для создания, редактирования и удаления интерфейсов используется меню «Объекты» «Добавить объект», «Объекты» - «Редактировать объект» и «Объекты» «Удалить объект», а также кнопки:

  • «Добавить»;
  • «Редактировать»;
  • «Удалить».


Параметры направления:

  • Имя – произвольное имя для идентификации (удобное для оператора);
  • SIP Транспорт – транспорт, который будет использоваться для приёма вызовов на направление и отправки вызовов с направления.
  • Remote Address – адрес удалённого узла, который связан с данным направлением. Вызовы на направление с IP-адреса, отличного от указанного в этом поле, будут отвергнуты. Вызовы с направления будут отправляться на адрес, указанный в этом поле.
  • Rule set – применить для входящей сигнализации набор правил, созданный в меню «Rule set» (подробнее в разделе "Rule set").
  • Транспортный протокол выбор протокола транспортного уровня, используемого для приема и передачи сообщений SIP:
    • TCP-prefer – прием по UDP и TCP. Отправка по TCP. В случае если не удалось установить соединение по TCP, отправка производится по UDP;
    • UDP –prefer – прием по UDP и TCP. Отправка пакетов более 1300 байт по TCP, менее 1300 байт – по UDP;
    • UDP-only – использовать только UDP протокол;
    • TCP-only – использовать только ТСP протокол;
  • Формат заголовков SIP – определяет, в каком формате передавать заголовки SIP:
    • full – использовать обычный (длинный) формат заголовков;
    • compact – использовать короткий формат заголовков;
  • Адаптация настройка предназначена для адаптации взаимодействия через SBC шлюзов различных производителей с программным коммутатором CSS-17:
    • HUAWEI-EchoLife – данная адаптация позволяет принять сигнал Flash от шлюза методом re- INVITE и передать его в сторону программного коммутатора методом SIP INFO;
    • Iskratel SI3000 при использовании данной адаптации SBC не подменяет поле contact в запросах, передаваемых в сторону программного коммутатора. При вызове на абонента в Request-URI URI-parameters не анализируются, анализируются только номер абонента и его адрес;
    • HUAWEI-SoftX3000 при использовании данной адаптации SBC не подменяет поле contact в запросах, передаваемых в сторону программного коммутатора. В ответе 200ОК на запрос REGISTER считается, что URI, содержащий дефолтный порт 5060, равен URI, не содержащему его;
    • ZTE Softswitch — при использовании данной адаптации SBC не подменяет поле «contact» в запросах, передаваемых в сторону программного коммутатора. При вызове на абонента в Request-URI URI-parameters не анализируются, анализируются только номер абонента и его адрес. Также игнорируются нарушения последовательности origin version в SDP;
    • Nortel при использовании данной адаптации SBC игнорирует нарушения последовательности origin version в SDP.
    • MTA M-200 — при использовании данной адаптации SBC при поступлении входящих вызовов не проверяет порт, указанный в Request URI.
  • Передавать контакт без изменения при использовании данной опции SBC не подменяет поле contact в запросах, передаваемых на второе плечо;
  • Таймаут ожидания RTP-пакетов функция контроля состояния разговорного тракта по наличию RTP- трафика от взаимодействующего устройства. Диапазон допустимых значений от 10 до 300 секунд. При снятом флаге контроль RTP выключен, при установленном – включен. Контроль осуществляется следующим образом: если в течение данного таймаута от встречного устройства не поступает ни одного RTP-пакета и последний пакет не был пакетом подавления пауз, то вызов отбивается;
  • Таймаут ожидания RTP-пакетов после получения Silence-Suppression (множитель) таймаут ожидания RTP-пакетов при использовании опции подавления пауз. Диапазон допустимых значений от 1 до 30. Коэффициент является множителем и определяет, во сколько раз значение данного таймаута больше, чем «Таймаут ожидания RTP-пакетов». Контроль осуществляется следующим образом: если в течение данного времени от встречного устройства не поступает ни одного RTP пакета и последний пакет был пакетом подавления пауз, то вызов отбивается;
  • Таймаут ожидания RTP-пакетов в режиме удержания вызова (множитель) таймаут ожидания RTP- пакетов от взаимодействующего с данным SIP-сервером SBC в режимах, когда разговорный канал работает только на передачу либо неактивен. Диапазон допустимых значений от 1 до 30. Коэффициент является множителем и определяет, во сколько раз значение данного таймаута больше, чем «Таймаут ожидания RTP-пакетов». Контроль осуществляется следующим образом: если в течение данного времени от встречного устройства не поступает ни одного RTP пакета и разговорный канал работает только на передачу либо неактивен, то вызов отбивается;
  • Таймаут ожидания RTCP пакетов – функция контроля состояния разговорного тракта, принимает значения из диапазона 10-300 c. Время, в течение которого ожидаются пакеты протокола RTCP со встречной стороны. При отсутствии пакетов в заданном периоде времени, в случае, если встречной стороной ранее был отправлен хотя бы один RTCP пакет, установленное соединение разрушается;
  • Контроль IP:Port источника RTP - при включении опции, SBC следит, чтобы прохождение медиа- потока от встречной стороны осуществлялось именно с тех IP и порта, которые указаны в SDP. Медиа- поток, пришедший не с указанного IP или порта, будет отброшен;
  • Запрашиваемый период контроля сессии (Session Expires, RFC 4028), c при установленном флаге поддерживаются таймеры SIP-сессий (RFC 4028). Обновление сессии поддерживается путем передачи запросов re-INVITE в течение сессии. Данный параметр определяет период времени в секундах, по истечении которого произойдет принудительное завершение сессии, в случае если сессия не будет во время обновлена (от 90 до 64800 с, рекомендуемое значение - 1800 с);

 Контроль ожидания RTP, RTCP пакетов, а также использование RFC 4028 предназначено для того, чтобы исключить зависание разговорных сессий, установленных через SBC, в случае возникновения проблем с прохождением пакетов на сети оператора. Все неактивные сессии через соответствующие таймауты будут закрыты.

  • Период проверки рабочего сервера, c (после завершения предыдущей транзакции OPTIONS) – интервал времени, через который контрольный запрос OPTIONS будет отправлен на SIP-сервер в случае, если на предыдущий запрос OPTIONS было получено подтверждение;
  • Период проверки нерабочего сервера, c (после завершения предыдущей транзакции OPTIONS) интервал времени, через который контрольный запрос OPTIONS будет отправлен на SIP-сервер в случае, если на предыдущий запрос OPTIONS не было получено подтверждение;


Аутентификация SBC

  • Логин – логин для аутентификации на вышестоящем SIP-сервере;
  • Пароль – пароль для аутентификации на вышестоящем SIP-сервере. Данные аутентификации используются только для авторизации запросов, формируемых самим SBC, например, это могут быть запросы re-INVITE, формируемые SBC при использовании функции timer RFC 4028, аутентификация на взаимодействующем сервере, регистрация на взаимодействующем сервере (при типе регистрации UAC), аутентификации запросов от взаимодействующего сервера (при типе регистрации UAS).



Регистрация SIP trunk

  • Тип регистрации – данная настройка задает направление регистрации:
  • UAC в данном случае SBC по транку будет регистрироваться на взаимодействующем сервере регистрации. При этом при отсутствии регистрации направление будет считаться недоступным, и в него не будут отправляться вызовы (но приниматься будут всегда);
  • UAS в данном случае взаимодействующее по транку устройство будет регистрироваться на SBC при условии, что будет получено подтверждение регистрации от выбранного по Rule set сервера. Также SBC будет аутентифицировать все запросы от взаимодействующего сервера. Настройка в поле Remote Address при этом не применяется, используется адрес, полученный в контакте при регистрации.



 При отсутствии регистрации в любом режиме направление будет считаться недоступным, и с него не будут отправляться вызовы (но приниматься будут всегда);

  • Период регистрации, c – период обновления регистрации на сервере (используется при типе регистрации UAC);
  • Имя пользователя/Номер – имя/номер, с которым транк SBC регистрируется на сервере регистрации (при типе регистрации UAC);
  • SIP-домен – доменное имя, с которым транк SBC регистрируется на сервере регистрации (при типе регистрации UAC), либо доменное имя, с которым встречное устройство аутентифи-цируется на SBC через транк (при типе регистрации UAS);


Ограничение числа одновременных сессий

  • Без ограничения количество сессий не ограничено;
  • Полностью запретить полный запрет сессий;
  • Максимум N сессий, где N – количество одновременных сессий.


Опции

  • Конвертировать RFC2833 Flash в SIP INFO преобразовывает сигнал Flash, принятый методом RFC 2833, в запрос INFO application/hook-flash протокола SIP и передает его во взаимодействующий канал;
  • Разрешить перенаправление – разрешает обработку ответов 302. При отключенной настройке при получении со стороны Б ответа 302 SBC завершит вызов. При включении опции SBC будет обрабатывать ответы 302 следующим образом: получив контакт абонента C, SBC попытается отправить вызов ему, уведомив сторону А о перенаправлении вызова ответом 181. Если же в контакте содержится адрес самого SBC, то он прозрачно пробросит сообщение 302 на сторону А, указав в поле Contact адрес стороны А;

 При активации настройки для обеспечения корректности работы перенаправлений будут отключены встроенные правила firewall для SIP transport, привязанного к SIP destination, на котором включается опция! Если транспорт используется на других SIP destination, то для них встроенные правила Firewall них тоже будут отключены. Рекомендуется выделять отдельный SIP transport для тех SIP destination, с которых разрешена обработка перенаправлений, либо, при необходимости, ограничить доступ вручную (подробнее в разделе "Статический брандмауэр").

  • Не учитывать порт-источник при входящих вызовах не проверять для входящих вызовов адрес порта, с которого пришёл запрос. Если опция не активна, то для входящих вызовов строго проверяется, что вызов пришёл с адреса и порта, указанных в настройке remote address. Если опция активна, то поиск и выбор SIP Destination производится сначала по тем destination, где опции нет, а затем будет выбираться один из тех, где опция активирована и которые проходят по параметра IP/hostname в настройке remote address.


Пример:

На SBC сконфигурировано четыре SIP Destination с такими параметрами remote address:

Имя

remote address

Состояние опции

Dest1

192.0.2.1:5060

отключена

Dest2

192.0.2.1:5061

отключена

Dest3

192.0.2.1:5062

включена

Запросы с адресов 192.0.2.1:5060…192.0.2.1:5062 будут обработаны в destination Dest1..Dest3 соответственно своим адресам, поскольку они точно совпадают с тем, что настроено в remote address.

Запрос с адреса 192.0.2.1:5090 попадёт в Dest3, поскольку запрос не подходят ни под одну настройку remote address, но на Dest3 игнорируется порт. Аналогично все запросы с портов, не входящих в 5060..5062 попадут также в Dest3.

Не рекомендуется создавать несколько SIP Destination с одинаковыми IP- адресами и активированными настройками игнорирования порта, т.к. нельзя предсказать, в каком из них будет в итоге обработан запрос.


Расширенные настройки протокола SIP

В поле находятся расширенные настройки протокола SIP. При помощи данных настроек можно корректировать поля сообщений SIP по заданным правилам.


Формат заполнения поля:

[sipheader:ИМЯ_ЗАГОЛОВКА=операция],[sipheader:...],...

 Где: 

  • Операции disable, insert или правило модификации;
  • ИМЯ_ЗАГОЛОВКА регистронезависимый параметр, например Accept = accept = ACCEPT. В иных параметрах регистр имеет значение.



Правила модификации

Правила модификации описываются символами:

$ – оставить последующий текст;

! – удалить оставшийся текст;

+(АБВ) добавить указанный текст;

-(АБВ) – удалить указанный текст.


Примеры реализации правил операции приведены в таблице ниже.

Таблица – Примеры реализации правил операции.

Операция

Исходный заголовок

Правило

Результат

Не отправлять заголовок

Accept: application/SDP

[sipheader:accept=disable]

 

Передать без изменений заголовок из первого плеча

Дополнительные заголовки на первом плече:


P-Asserted-Identity: username@domain


Subject: Test call

[sipheader:[СПИСОК_СООБЩЕНИЙ]: [МАСКА_ЗАГОЛОВКА]=transit]


[sipheader:[МАСКА_ЗАГОЛОВКА]=trans it]


В сообщениях INVITE и 200: [sipheader:INVITE,200:Subject=transit]


В любых сообщениях: [sipheader:Subject=transit]

На втором плече появится заданный заголовок:


Subject: Test call

Передать без изменений группу заголовков из первого плеча

Дополнительные заголовки на первом плече:


P-Asserted-Identity: sip:username@domain


P-Called-Party-ID: sip:username@domain

Privacy: id Subject: Test call

[sipheader:P-*=transit]


Обратите внимание, что такое правило:

[sipheader:*=transit]

работать не будет, поскольку символ

* может заменять только часть имени.

На втором плече появятся заданные заголовки:


P-Asserted-Identity: sip:username@domain


P-Called-Party-ID: sip:username@domain

Вставить заготовок

 

[sipheader:insert[СПИСОК_ЗАГОЛОВКО В]: RemoteIp=+(ТЕКСТ)]

Во всех запросах: [sipheader:insert:RemoteIp=+(example.SBC)]

Только в запросе INVITE: [sipheader:insert,INVITE:RemoteIp=+( example.SBC)]

Только в указанные запросы (например INVITE и ACK): [sipheader:insert,INVITE,ACK:RemoteIp=

+( example.SBC)]

RemoteIp:example.SBC

Добавить текст в начало

Accept: application/SDP

[sipheader:accept=+(application/ISUP,)$

]

Accept: application/ISUP,application/S DP

Добавить текст в конец

Accept: application/SDP

[sipheader:accept=$+(,application/ISUP)

]

Accept: application/SDP,application/IS UP

Удалить текст

Accept: application/SDP,applicatio n/ISUP

[sipheader:accept=-(application/SDP,)$]

Accept: application/ISUP

Удалить, начиная с указанного текста

Accept: application/SDP,text/plain

[sipheader:accept=-(,text)!]

Accept: application/SDP

Заменить текст полностью

Accept: application/SDP

[sipheader:accept=+(application/ISUP)!]

Accept: application/ISUP

Заменить текст

Accept: application/SDP,text/plain

[sipheader:accept=-(SDP)+(ISUP)$]

Accept: application/ISUP,text/plain

Заменить текст, отбросив данные в конце

Accept: application/SDP,text/plain

[sipheader:accept=-(SDP)+(ISUP)!]

Accept: application/ISUP

Пример комплексной модификации

From:

<sip:who@host>;tag=aBc

[sipheader:from=+(DISPLAY )- (who)+(12345)-

(>)+(;user=phone>)$+(;line=abc)]

From: DISPLAY

<sip:12345@host;user=phone

>;tag=aBc;line=abc

Пример: 

[sipheader:Accept=disable],[sipheader:user-agent=disable]

 В данном примере все сообщения SIP, отправляемые устройством через данный SIP- интерфейс, будут следовать без полей Accept и user-agent.

Список обязательных полей сообщений SIP, которые не могут быть модифицированы: via, from, to, call-id, cseq, contact, content-type, content-length.





  • Нет меток
Написать комментарий...