• фоновое изображение
• шрифт и цвет
• иконки
• язык
• мелодии звонков
• назначение клавиш
• и многое другое

1. Изменение цветовой гаммы
2. Изменение шрифтов
3. Загрузка фонового изображения
4. Примеры тем

Во 2й части нашей статьи (которая скоро выйдет) мы поговорим об остальных возможностях кастомизции. Так-что не переключайтесь.

1. Изменение цветовой гаммы

2. Изменение шрифтов

tar -cvf fonts.tar fontfile.ttf

<?xml version="1.0" encoding="utf-8" ?><settings> <uploads>  <file url="http://personeltest.ru/away/192.168.23.54:8080/fonts.tar" type="font" /> </uploads></settings>

3. Загрузка фонового изображения

4. Пример конфигурации тем

<?xml version="1.0" encoding="utf-8"?><settings><phone-settings>  <!-- When the background image is set, it automatically applies alpha changes to all elements.   Therefore it has to be listed at the beginning, so that all styles afterwards correctly apply-->  <custom_bg_image_url perm=""></custom_bg_image_url>  <!-- Background color is set to be not transparent because no background image is configured -->  <background_color perm="">43 49 56 255</background_color>  <titlebar_text_color perm="">242 242 242 255</titlebar_text_color>  <titlebar_background_color perm="">43 49 56 255</titlebar_background_color>  <text_color perm="">242 242 242 255</text_color>  <subtext_color perm="">224 224 224 255</subtext_color>  <extratext_color perm="">158 158 158 255</extratext_color>  <extratext2_color perm="">158 158 158 255</extratext2_color>  <fkey_background_color perm="">43 49 56 255</fkey_background_color>  <fkey_pressed_background_color perm="">61 133 198 255</fkey_pressed_background_color>  <fkey_separator_color perm="">70 90 120 255</fkey_separator_color>  <fkey_label_color perm="">224 224 224 255</fkey_label_color>  <fkey_pressed_label_color perm="">242 242 242 255</fkey_pressed_label_color>  <line_background_color perm="">242 242 242 0</line_background_color>  <selected_line_background_color perm="">50 60 80 255</selected_line_background_color>  <selected_line_indicator_color perm="">61 133 198 255</selected_line_indicator_color>  <selected_line_text_color perm="">61 133 198 255</selected_line_text_color>  <line_separator_color perm="">70 90 120 255</line_separator_color>  <scrollbar_color perm="">70 90 120 255</scrollbar_color>  <cursor_color perm="">61 133 198 255</cursor_color>  <status_msgs_background_color perm="">43 49 56 255</status_msgs_background_color>  <status_msgs_border_color perm="">70 90 120 255</status_msgs_border_color>  <!-- Settings for SmartLabel -->  <smartlabel_background_color perm="">43 49 56 255</smartlabel_background_color>  <smartlabel_pressed_background_color perm="">61 133 198 255</smartlabel_pressed_background_color>  <smartlabel_separator_color perm="">70 90 120 255</smartlabel_separator_color>  <smartlabel_label_color perm="">224 224 224 255</smartlabel_label_color>  <smartlabel_pressed_label_color perm="">242 242 242 255</smartlabel_pressed_label_color></phone-settings></settings>

<?xml version="1.0" encoding="utf-8"?><settings><phone-settings>  <!-- When the background image is set, it automatically applies alpha changes to all elements.  Therefore it has to be configured at the beginning so that all styles afterwards correctly apply-->  <custom_bg_image_url perm="">http://192.168.0.1/background.png</custom_bg_image_url>  <!-- Background color has to be transparent because a background image is configured -->  <background_color perm="">0 0 0 0</background_color>  <titlebar_text_color perm="">242 242 242 255</titlebar_text_color>  <titlebar_background_color perm="">43 49 56 40</titlebar_background_color>  <text_color perm="">242 242 242 255</text_color>  <subtext_color perm="">224 224 224 255</subtext_color>  <extratext_color perm="">224 224 224 255</extratext_color>  <extratext2_color perm="">224 224 224 255</extratext2_color>  <fkey_background_color perm="">43 49 56 40</fkey_background_color>  <fkey_pressed_background_color perm="">43 49 56 140</fkey_pressed_background_color>  <fkey_separator_color perm="">0 0 0 0</fkey_separator_color>  <fkey_label_color perm="">224 224 224 255</fkey_label_color>  <fkey_pressed_label_color perm="">224 224 224 255</fkey_pressed_label_color>  <line_background_color perm="">0 0 0 0</line_background_color>  <selected_line_background_color perm="">43 49 56 40</selected_line_background_color>  <selected_line_indicator_color perm="">61 133 198 255</selected_line_indicator_color>  <selected_line_text_color perm="">61 133 198 255</selected_line_text_color>  <line_separator_color perm="">0 0 0 0</line_separator_color>  <scrollbar_color perm="">61 133 198 255</scrollbar_color>  <cursor_color perm="">61 133 198 255</cursor_color>  <status_msgs_background_color perm="">61 133 198 255</status_msgs_background_color>  <status_msgs_border_color perm="">61 133 198 255</status_msgs_border_color>  <!-- Settings for SmartLabel -->  <smartlabel_background_color perm="">43 49 56 40</smartlabel_background_color>  <smartlabel_pressed_background_color perm="">43 49 56 140</smartlabel_pressed_background_color>  <smartlabel_separator_color perm="">0 0 0 0</smartlabel_separator_color>  <smartlabel_label_color perm="">242 242 242 255</smartlabel_label_color>  <smartlabel_pressed_label_color perm="">242 242 242 255</smartlabel_pressed_label_color></phone-settings></settings>

Распаковка и комплектация

• Телефонный аппарат
• Краткое руководство пользователя
• Подставку
• Ethernet-кабель категории 5E
• Трубку и витой шнур для ее подключения

Дизайн

Программное обеспечение и настройка

Функционал и эксплуатация

Аксессуары

Подведем итог

Распаковка и комплектация

• Телефонный аппарат
• Краткое руководство пользователя
• Подставку
• Ethernet-кабель категории 5E
• Трубку и витой шнур для ее подключения

Дизайн

Программное обеспечение и настройка

Функционал и эксплуатация

Аксессуары

Подведем итог

Распаковка и комплектация

• Телефонный аппарат
• Краткое руководство пользователя
• Подставку
• Ethernet-кабель категории 5E
• Трубку и витой шнур для ее подключения

Дизайн

Программное обеспечение и настройка

Функционал и эксплуатация

Подведем итог

• Гарантированная мобильность в рамках определённых помещений
• Управление такими аспектами как: перевод, запись звонков и т.д.
• Защита используемого оборудования от различных повреждений
• Работоспособность оборудования в сложных условиях окружающей среды
• Уведомление необходимой службы об экстренной ситуации у сотрудника
• Определение местоположения оборудования

Интересно? Тогда усаживайтесь поудобней, статья получится объёмной.

Почему DECT?

Определение DECT

• Цифровые Усовершенствованные Беспроводные Телекоммуникации (DECT, первоначально Digital European Cordless Telephony) это международный стандарт для телекоммуникаций, использующих радио технологии для беспроводных телефонов.
• DECT является торговой маркой Европейского института телекоммуникационных стандартов (ETSI) с обширными спецификациями.

Области применения

• В зданиях, можно достичь дальности или радиуса сигнала до 50 метров (приблизительно).
• Дальность передачи сигнала на открытом пространстве до 300 метров. Максимально допустимая выходная мощность составляет 250 мВт.
• Применяется повсеместно, где есть необходимость обеспечить мобильную связь сотрудника. К примеру: на складах, на производстве и тд.

Радиопередача и частоты

• DECT использует диапазоны частот ниже 2,45 ГГц, отличные от WLAN, Bluetooth и т. д., и поэтому не создает помех этим сетям.
• В Европе он работает в диапазоне частот от 1880 МГц до 1900 МГц, в котором определены 10 каналов с шириной полосы 1728 кГц каждый.
• ETSI также определяет полосы расширения в диапазонах 19001980 МГц, 20102025 МГц и 24002480 МГц.
• DECT обеспечивает динамический выбор и назначение каналов. Для этой цели все устройства DECT ведут список RSSI (Received Signal Strength Indication Индикация Уровня Принятого Сигнала).
• С регулярными интервалами (минимум каждые 30 секунд) все свободные каналы сканируются и заносятся в список
• Если требуется новый канал, мобильное устройство или базовая станция выбирает канал с наименьшими помехами на основе списка RSSI.

Безопасность

• DECT защищает от несанкционированного использования и прослушивания тремя способами, два из которых являются обязательными:
• Вход: мобильный абонент уведомляет базовую станцию, что он готов к приему.
• Идентификация: каждый раз, когда устанавливается вызов, мобильное устройство должно идентифицировать себя для базовой станции с помощью секретного ключа.
• Существует также третий, необязательный метод шифрование.

Что такое Микросота?

Наиболее часто используемые компоненты Микросоты

Что может предложить Snom?

• Масштабируемость от 1й до 4000 Базовых Станций в одной инсталляции
• Поддержка до 16000 трубок, в одной инсталляции
• Поддержка до 30 трубок на одну базу
• 8 одновременных звонков в узкополосном режиме
• 4 одновременных звонков в широкополосном режиме
• Поддержка широкого спектра различных кодеков, включая OPUS
• Питание PoE или от адаптера
• DECT и LAN синхронизация
• Возможность подключения к каждой Базовой Станции до 3х Ретрансляторов Snom M5
• Каждая Базовая Станция работает одновременно в режиме Базовой Станции и DECT менеджера
• В случае отказа управляющей базы, следующая Базовая Станция автоматически станет новой управляющей базой, что позволит системе продолжить работу
• Отсутствие какого либо лицензирования. Масштабируйте систему до указанных выше пределов приобретая лишь необходимое количество Базовых Станций и Трубок
• Транслирует оповещение тревожных событий полученных с трубки
• Отправляет PUSH сообщения на трубку
• Определяет место расположение трубки

• Цветные экраны высокого разрешения
• Поддержка Bluetooth для соединения с беспроводными гарнитурами
• Поддержка стандарта Bluetooth LE и технологии Beacon
• Аудио разъёма для подключения проводных гарнитур
• Клипса/зажим для крепления на ремень
• Тревожная кнопка для уведомления необходимой службы экстренной помощи
• Встроенный гироскоп для определения падения или трубки находящейся без движения (а вместе с нем возможно и человека) с последующим уведомлением необходимой службы экстренной помощи
• Принимают PUSH сообщения
• Прочная конструкция корпуса (MIL-STD-810g 516.6)
• Защита по стандарту IP65
• Большой диапазон температур (от -10 до 55c)
• Антибактериальное покрытие корпуса
• Виброзвонок и подсветка клавиатуры

• Сопряжение непосредственно с Микросотовой Базовой Станцией
• Поддержка роуминга
• Может быть использована как самостоятельное устройство для принятия звонков
• Может быть синхронизировано с телефоном DECT
• Время работы в режиме разговора 7ч, а так же в режиме ожидания 100ч
• Дальность передачи сигнала (до Микросотовой Базы) в помещение 50м, на открытом пространстве 300м

• Поддержка одно-сотовых и микро-сотовых Базовых Станции
• Поддержка широкополосного звука
• До 5 одновременных вызовов
• Последовательное соединение

Будем рады ответить на ваши вопросы.
Оставьте комментарий, пожалуйста, если вам понравилась наша статья. Пишем мы для вас и нам важно понимать, движемся ли мы в правильном направление. Спасибо!

Распаковка и комплектация

• Телефонный аппарат
• Краткое руководство пользователя
• Подставка
• Ethernet-кабель категории 5E
• Трубка и витой шнур для ее подключения

Дизайн

Программное обеспечение и настройка

Функционал и эксплуатация

Аксессуары

Подведем итог

Стандарт DECT

• Стандарт DECT изначально предназначен именно для передачи голоса и используется только с этой целью. Это означает что нет необходимости думать о приоритизации трафика или загруженности частотного диапазона, его будут занимать исключительно устройства для передачи голоса.
• Дальность действия. Дальность действия устройств, работающих по данному протоколу, ограничена в первую очередь мощностью передатчика. Максимальная мощность по данному стандарту ограничена 10 мВт, что дает возможность разнесения приемного и передающего устройства до 300 м в прямой видимости и до 50 метров в помещениях. Переключения между источниками сигнала при этом осуществляются быстрее чем в том же Wi-Fi, не позволяя пользователю услышать, что переключение произошло. Говоря о дальности действия нельзя сказать, что она принципиально больше, чем у конкурирующих технологий, но радиус действия источника сигнала DECT достаточно большой, чтобы обеспечить пользователю свободу перемещений или построить сеть на основе множества источников сигнала, покрыв значительную площадь.
• Количество каналов. А значит и количество одновременно работающих устройств. Стандарт DECT подразумевает наличие 10 частотных радиоканалов, казалось бы, немного. Но каждый из частотных каналов подразделяется на 12 временных каналов, давая в сумме больше сотни каналов для передачи голоса.

Распаковка и комплектация

• Кабель USB-Mini USB для подключения к ПК
• Кабель RJ9-RJ9 для передачи аудио между телефоном и гарнитурой
• Специализированный кабель EHS для подключения к телефонам Snom
• Кабель EHS для подключения к стандартизированному разъему

Дизайн

Функционал и эксплуатация

Подведем итог

Комплектация

Дизайн

Функционал и эксплуатация

• ACPJ
• ACUSB
• ACPJ25

Итог

Доброго времени суток, дорогие читатели!

Микросотовая DECT-система и принципы её работы.

Дизайн.

Функционал системы.

Итог

Здравствуйте, уважаемые читатели!

Микросотовая DECT-система. Синхронизация.

• Достаточный уровень сигнала между базами
• Настроенная синхронизация между ними же

Snom M85

Snom M65

Snom M25

Итог

Здравствуйте, меня зовут Валентин, и я задолбался. Нет-нет, вы всё ещё на Хабре.

Все технологии телефонии ужасны.
Большинство технологий разработки IETF ужасны. Может, не ужасны-ужасны, как ISO
Когда они смешиваются ну вы в курсе. Или ещё нет? Получается SIP.

Это пост ворчания, техническая суть которого может быть полезна паре сотен человек. Но, to grumble is human.

Начнём с синтаксиса

HTTP заголовок видели все. Ну, большинство. Кто не видел может посмотреть на заголовок почтового письма (email). Принципы взяты оттуда, НО...

Я буду брать примеры из стандартных RFC, чтобы не влияла местная специфика. Типичное сообщение выглядит в таком стиле:

INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
a=sendrecv
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Параметры, параметры и параметры

У нас есть address parameters, URI parameters и user parameters. Не то чтобы это был необходимый набор для работы, но если начал, становится трудно остановиться Все три отделяются точками с запятой, ограничения на синтаксис у всех немного разные. Смотрите не перепутайте. Кстати, чем отличается адрес от URI, тоже не каждому сразу получится объяснить. Адрес (определение формально не встречается в спеках, но постоянно используется на практике) это содержимое всяких From/To/Contact/Route (один элемент, где их несколько), URI с параметрами и (возможно) именем Ну поехали:

To: sip:bob@example.com
тут всё просто схема, домен и юзер.

To: sip:bob@example.com;xyz=123
xyz=123 параметр адреса. Но: если URI должен присутствовать сам по себе, как в первой строке запроса:

INVITE sip:bob@example.com;xyz=123
то xyz=123 будет уже параметром URI.

To: <sip:bob@example.com>;xyz=123
To: "Bob" <sip:bob@example.com>;xyz=123
xyz=123 параметр адреса.

To: <sip:bob@example.com;xyz=123>;xyz=456
xyz=123 параметр URI.
xyz=456 параметр адреса.

To: sip:bob;rn=alice@example.com;xyz=987
Так нельзя. Странно, да? Хотя если URI там, где нужен именно URI (в request line), то можно:
INVITE sip:bob;rn=alice@example.com;xyz=987 SIP/2.0

Надо заключить в угловые скобки:

To: <sip:bob;rn=alice@example.com;xyz=987>;xyz=123
rn=alice параметр юзера.
xyz=987 параметр URI.
xyz=123 параметр адреса.

Кстати, во всех допускаются символы за пределами очевидного набора типа [A-Za-z0-9] и ещё некоторого набора неожиданно допущенных, но по-разному. В user и в URI надо квотить недопустимое их кодами через %XX, а в адресе через quoted string, и никак иначе. Поэтому параметр со значением a%\b будет передан:

В спеке на синтаксис, обобщение для параметра URI зовётся other-param, а параметра адреса generic-param. Смотрите не перепутайте, правила для них заметно разные. Кстати, user parameters это другая спека (точнее, произведение двух RFC4694 + RFC3398).

Что может быть значением параметра URI? Что угодно, только надо его единообразно заквотить (через %XX), дальше это набор октетов (UTF-8, если в SIP). Примеры были выше.

Что может быть значением параметра адреса? token, quoted string или host. Кстати, token это не token в смысле грамматического разбора. Это особый token, которого лично зовут token. Но при этом с маленькой буквы, потому что он самый скромный token.

127.0.0.1 это host или token? Допустимы оба. Должен ли я считать, что это host?

To: <sip:bob@example.com>;xyz=[fe80::1]
To: <sip:bob@example.com>;xyz="[fe80::1]"

Значения одинаковы. Но в первом случае это host подтипа IPv6reference,
во втором quoted string. Если я прокси и передаю параметр через себя, я должен сохранить, чем он был восстановление по содержимому не поможет.

Кстати, к предыдущему примеру:

это не host и не token. Но если объекту типа address скажут назначить параметр со значением "127.0.0.1" какой тип выбрать? Ах ну да, такая установка уже должна указывать тип...

Вместе с тем, что если это token, то регистр букв не имеет значение, а если quoted-string, то имеет; а если host, то снова не имеет для адекватности одновременно обработки и сохранения исходного значения (про регистр подробнее ниже) я должен хранить:

1) Исходную форму как октетную или unicode строку для точного воспроизведения;
2) Приведённую форму для сравнения;
3) Признак, какого типа был параметр на входе (насколько это вообще восстановимо, не зная по названию параметра, чем он должен быть хотя годится обобщение типа любой host кроме IPv6reference может храниться как token там ещё есть несколько подобных тонкостей).

Но в To допускается только один адрес. А в Contact несколько. Есть некоторые другие поля заголовка, где тоже можно, но пока пусть например будет слонёнок Contact:

Contact: sip:alice@example.com, sip:bob@example.com

Да, можно.

Тоже можно.

Нельзя. URL с запятой должен быть заключён в <>. Распарситься не должно: после запятой нет схемы URL.

Уже можно. Хотя это надо минимум три синяка от граблей, чтобы сразу видеть, что alice уже не юзер, а домен.

Нельзя. URL с запятой внутри поля заголовка конструкции адрес должен быть заключён в <>.

Уже можно. При этом второй адрес заключать не обязательно.

Хорошо, а это что тогда?

Это два адреса в контактах: sip:alice (alice это хост, user отсутствует целиком) и sip:bob@example.com. Но:

Это один адрес с user=alice,sip и паролем bob. Да-да, запятая в user возможна и её можно не квотить.

Это я ещё не вспоминал, что впереди может быть display-name, а позади адресные параметры:

И снова здравствуйте, меня зовут Валентин. (Здравствуй, Валентин ответил нестройный хор.) Я сделал реализацию разбора SIP регулярными выражениями, и нет, я не стыжусь этого. У меня нет проблем, которые нельзя так решить: в грамматике нет рекурсии (максимум есть списки), и, к счастью, это единственное, что там хорошее. Если бы была рекурсия разбор был бы ужасен-ужасен. А так, он просто ужасен:

Нет, мне не страшно. Потому что эти выражения формируются из отдельных частей:

и на каждом этапе я могу проверить качество каждого выражения и соответствие правилам комбинирования. Кстати, некоторые мелочи, которые никогда за почти 20 лет существования продуктового стека не понадобились (типа возможности absoluteURI), тут не реализованы. С ними было бы ещё в полтора раза больше, наверно.

Но почему таки регулярные выражения? спросит отдельный робкий голос. Ответ: а потому что Python.

Я сравниваю один и тот же разбор URI на Python через regexps, Java через regexps и Java через пропуск по классам символов. Сравнение эффективности на одной и той же железке (Ryzen5):

CPython + regexps        - 14K/secPyPy    + regexps        - 130K/secJava    + regexps        - 270K/secJava    + symbol classes - 1800K/secPyPy    + symbol classes - 3K/sec

Всё потому, что в Python движок регулярных выражений написан на C, а обходить его означает выходить на уровень интерпретатора, который страшно медленный. Предкомпилированные (на этапе загрузки модулей парсинга) выражения превращаются в аккуратные таблички в памяти это хуже, чем выхлоп какого-нибудь re2c, но по ним бегает неплохо оптимизированный код матчинга. В Java вроде JIT, но движок регулярных выражений написан на самой Java, и JIT ему не очень помогает, когда логика состоит из сплошных переходов с лукапами по табличкам, которые этим JITом не перерабатываются. На чём-то напрямую компилируемом цифры могут быть ещё вкуснее нет, я не буду впадать в этот флейм. PyPy заметно помогает, но есть порог, за которым кончается и его умение (а цифры говорят, что >90% накладных расходов CPython это работа со структурами Python, а не собственно управление памятью, парсинг и т.п.)

Что такое лукап по классам символов это в таком духе:

        while (pos < limit && (b = source[pos]) >= 0 &&                SipSyntax.userinfo_allowed[b] != 0)        {            ++pos;        }

табличка userinfo_allowed тщательно выверена руками и подкреплена юнит-тестом.

(Меня удивила цифра PyPy, но, может, это я оказался такой криворукий. Но на CPython я даже не пытаюсь это делать страашно. Ладно, может, попробуем, как сады зацветут.)

А ещё есть проблема '#'. По RFC, такое не разрешено:

но не только лишь все (tm), начиная с Cisco, это игнорируют. Поэтому почти сколько существует наш продукт, почти столько и существует параметр получателя url_hash_safe, который говорит рисовать #, а не %23 (а %23 многие из них не понимают). Но некоторые наоборот, не понимают, если ставить '#'. Поэтому нужна регуляция по конкретному ремотному участнику определять, кому таторы, а кому ляторы. Последний раз я подсказывал техподдержке включить этот параметр прошлой осенью. Наверно, эта проблема будет жить вечно. Ах да, '*' ещё один частый символ в этих последовательностях разрешён явно и проблемы не вызывает. Неаккуратненько-с.

В RFC3261 есть роскошное примечание:

The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.

Спасибо, дорогая партия, за наше счастливое детство. У меня вопрос: а зачем вообще было разрешать вариант без угловых скобок? Ах да, забыл: в Route и Record-Route угловые скобки обязательны. В From, To, Contact нет. Картина Репина.

Почему не готовый движок парсинга?

Если упоминается Java, кто-то обязательно спросит почему не ANTLR?

Я пробовал применить ANTLR. Нет, конечно, это можно. Забитый молотком шуруп держится лучше, чем вкрученный отвёрткой гвоздь. В linphone его применяют. Но уже там видны недочёты.

Ему нельзя снаружи управлять контекстом для лексического анализатора, а это критично. Есть несколько разных стартовых контекстов: как минимум: первая строка сообщения, URI, адрес, ряд специфических заголовков со своими правилами (Call-Id, Authorization...)

Можно было бы справиться с semantic rules на месте, но:

• Каждый парсер стартует со своим лексером.
• Лексер не может получать указание по контексту от парсера, он должен определять это сам.
• Контекстов очень много.

Часто однозначного решения нет. Начало адреса может присутствовать или схема с ':' (включать ли двоеточие в токен лексера?), или display-name как последовательность token (это не тот токен, это другой токен, который token в грамматике SIP). После схемы в SIP-URI или хост, или username, и различить их можно только по тому, что раньше встретится после него (может, заметно после него) '@', ';', '?' или EOI. Не так предсказал откат назад на другую гипотезу.

Начальных контекстов как минимум: начало адреса (одиночного или множественного поля заголовка типа From, To, Contact, Route, Record-Route...); начало URI (например, в первой строке SIP запроса). Есть ещё несколько специфических контекстов для авторизационных заголовков, например там целые URI могут находиться в кавычках. В результате, получается сплошное дублирование. Грамматики лексеров не могут включать другие грамматики лексеров (почему?) В результате чтобы избежать копипастинга надо генерировать грамматики отдельным макропроцессором. Ну спасибо...

Альтернативно, можно было бы на уровне лексера определить каждый символ, а выше собирать их уже в грамматические конструкции. Исключение даётся только для quoted-string (и то за пределами авторизационных заголовков). Но производительность падает на порядки, реализация на Java становится тормознее реализации на Python+regexps.

Поэтому доступные реализации невозможно читать без ящика водки. Виски не подойдёт: он для добавления положительных эмоций, а не гашения отрицательных. Если бы не требование менять контексты лексера из самого лексера, было бы ещё подъёмно (LL() превратился бы в цивилизованный PEG), но не как сейчас.

Вместо регулярных выражений можно использовать классы символов. И на компилируемом языке это быстрее (ускорение раз в 5 я получаю без оптимизационных ухищрений). Но не на Python: его движок регулярных выражений на C, а поиск по строке будет чудовищно дорог.

В целом, мир грамматики IETF выглядит сущностью, принципиально противоположной тому, что рекламируется, например, в Dragon Book. Возможно, для него нужна своя теория, которая будет заметно отличаться от знаменитых LL(k), LR(k) и прочих. Но я такого не видел.

И ложка мёда:

А знаете, что хорошо по сравнению с RFC822, например? Границы строк чётко определены. Кошмариков типа "\\\r\n", которое неверно разбирали 99% почтовых парсеров, уже нет. Поэтому я могу (и даже обязан) сначала опознать границы строк, по ним полей заголовка, и тогда каждый подавать на разбор уже по своему вкусу (а скорее всего вообще не подавать те, что не нужно).

За 17 лет (1982->1999) IETF кое-чему научился. Жаль, что это так медленно происходит.

Морфология

У нас в каждом сообщении нужно посылать From и To. На INVITE выше приходит ответ, например:

SIP/2.0 100 TryingVia: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9    ;received=192.0.2.101From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76slTo: Bob <sip:bob@biloxi.example.com>Call-ID: 3848276298220188511@atlanta.example.comCSeq: 1 INVITEContact: <sip:bob@client.biloxi.example.com;transport=tcp>Content-Length: 0

Реально они нужны только в одном виде сообщений в начальном для установления диалога (или в отдельной транзакции). Дальше их можно тупо выкидывать, от этого ничего не поменяется: на них ничего не завязывается и никто не парсит, хотя пропускать их запрещено. Матчинг ответов на транзакции происходит по h_Via.branch. Матчинг ответов внутри диалога происходит по тегам диалога. И снова, смотрите не перепутайте. Я сам путаюсь, когда через несколько месяцев не-общения с этим всем возвращаюсь к тематике.

Так зачем же нужны эти From и To? А затем, что там теги.

Ах да, я ж забыл упомянуть теги:

У нас есть call-id и есть два тега. Вместе они образуют полный идентификатор диалога (ассоциация между двумя конечными участниками). Сообщение внутри диалога (у него два тега) определяет модификацию установленного звонка, а вне диалога (только один тег) новый звонок. (Я упростил всё, что можно, но для первого описания пойдёт.)

Call-id имеет особые, ни на что остальное в SIP не похожие, правила допуска и сравнения. Он регистрозависим (в отличие от тегов диалога), но об этом ниже. У него свой набор допустимых символов. Call-id неуникален, его совпадение у соседних звонков норма и закономерность (при форкинге диалога, когда на один запрос отвечают несколько удалённых участников). В отличие от, теги диалога уникальны, требуется хотя бы 32 бита случайности при их генерации, больше лучше. На самом деле после генерации тегов call-id вообще не нужен, у него роль мнэээ в рамках стандартных использований по RFC у него роли вообще нет, кроме как путаться под ногами, всё работало бы и без него. А вот для B2BUA, как у нас, call-id начинает выполнять особую функцию связи между звонками на разных сторонах одного B2BUA. Но B2BUA не определён ни одним RFC даже в ранге informational; это такое странное понятие, на которое ссылаются в нескольких RFC, но определено в лучшем случае неформально.

Так почему теги не в отдельных полях заголовка? Вы не найдёте обоснованного ответа на этот вопрос: это уже закон жизни, который тайна веков. Но зато ради них приходится полностью парсить целые From и To, с учётом всех тонкостей по содержанию (см. выше про адресные поля).

Cинтаксис возвращается: регистр букв

По непонятной прихоти call-id регистрозависим, а теги нет. Точнее, так в книге написано (tm), что они регистронезависимы. Реально же:
1) Есть UA (user agents железные или программные телефоны), которые воспринимают посылки в диалоге только если буквы в теге в том же регистре, что они посылают (если это Abc, то и надо прислать им Abc).
2) Есть UA, которые переделывают теги под себя, и если им прислать abc они ответят ABC. Или наоборот, прислали ABC а они отвечают abc.

И с обоими надо работать. Отказывать просто потому, что они нарушают ну в основном нельзя. Потому что всё равно не исправят большинство из них железные, и авторы прошивки просто не поймут, чего от них хотят. Не знаю, зачем производители железных UA нанимают таукитян или сентинельцев? Сложно разобрать, но проверено, что планета у них какая-то другая.

Какой вариант работает в итоге? Тег надо хранить в двух вариантах: приведённый к конкретному регистру для сравнения, и неприведённый для посылки другому участнику. Где-то мы это уже слышали?

И то же оказалось привет, история в Git с transport параметром URI. Потому что мы добрые, и если чужой телефон или SBC настаивает, что должно быть transport=UDP, а не transport=udp, то легче согласиться, чем спорить. Это карма авторов чисто софтового продукта: легче адаптировать софт, чем даже прошивку железного аппарата (а тем более само железо).

Но это были цветочки, основной же вопрос зачем вообще эта регистронезависимость?

Стандартные аргументы в пользу регистронезависимости: облегчение человекочитаемости. Это миф: её путают с человекоозвучиваемостью. Регистр не должен быть важен, например, в имени человека (хотя и тут могут быть тонкости). Но я не знаю, в каком случае с экрана будет читаться что-то в шрифтах, которые не различают регистр. И совсем не понимаю, почему и зачем различие регистра считается важнее, чем 100500 других различий.

Этот тезис можно обсудить в применении, например, к файловым системам отдельно (почему такие FS различают foo.docx, foo.docx , foо.docx и foo.docx (кто увидит разницу?), но не различают foo.docx и Foo.docx?), и что будет в случае (см. Turkey test), но сейчас речь не о них, а о SIP на простом беспроблемном ASCII.

Вы можете написать:

<code>From: <sip:123@foobar>;tag=mamarama</code>

но вы можете также написать:

<code>fRoM      :  <sip:123@foobaR>;TaG=mamaRAMa</code>

Все воспринимающие должны понять это одинаково. Но чего этого стоит? Обратимся к коду одной из самых быстрых реализаций Kamailio, в девичестве Sip Express Router.

/*! \brief macros from parse_hname2.c */#define READ(val) \(*(val + 0) + (*(val + 1) << 8) + (*(val + 2) << 16) + (*(val + 3) << 24))#define LOWER_DWORD(d) ((d) | 0x20202020)...#define _cont_ 0x746e6f63......                                // например возьмём этот кусок                                if ((LOWER_DWORD(READ(c)) == _cont_) &&                                        (LOWER_DWORD(READ(c+4)) == _ent__) &&                                        (LOWER_DWORD(READ(c+8)) == _type_)                                ) {                                        /* Content-Type HF found */

Ну, это хорошо работает на C. (Clang умудрился свернуть READ в просто 32-битное чтение из памяти. GCC этого не сумел. Ну не так страшно.) Уже на Java надо финтить, но хотя бы есть ByteBuffer. На интерпретаторах вроде Python, и на Java на строках, это превращается в чудовищную затрату или времени, или памяти, или обоих сразу.

Но и этот детект помогает только в очень ограниченной роли быстрый поиск по первым четвёркам символов (а ещё есть альтернативные имена полей f вместо from, i вместо call-id; пробелы до и после ':' в неограниченном количестве; и так далее). А как только мы выходим за пределы средств с прямым изменением в буферах привет, копирование.

Возможно многие, кто по той или иной причине сталкивается VoIP, особенно с решениями с открытым исходным кодом, слышали такое выражение: "Kamailio SBC". В этой статье постараемся разобраться правильно ли приравнивать Kamailio к SBC (пограничный контроллер сессий) и можем ли мы вообще использовать Kamailio в этом качестве. Начнем с краткого обзора SIP протокола, основных функций SBC и первопричин возникновения этого устройства.

Протокол инициации сеансов (SIP), за последние 10 лет перешел от эксперимента исследователей и VoIP энтузиастов фактически в стандарт для IP телефонии. Прародителем SIP, как известно, является протокол HTTP, откуда и была унаследована клиент-серверная архитектура. Основными элементами SIP сети являются: клиент агента пользователя (UAC), сервер агента пользователя(UAS), прокси-сервер (proxy server), сервер переадресации (redirect server), сервер регистрации (registrar) и определения местоположения пользователей (location server). Все эти элементы и составляют SIP сеть, о них и способах их взаимодействия подробно описано в SIP спецификациях, однако в этих документах нет упоминания о SBC.

Термин SBC относительно неспецифичен, не стандартизирован и нигде официально не определен. Тем не менее широкой общественности он известен, во многом благодаря активному маркетингу со стороны компаний производителей, как "незаменимый" компонент VoIP сети.

С момента своего появления, SBC использовался для выполнения определенных задач, набор его функции постоянно рос и совершенствовался по мере роста набора требований.

Фактически же причиной возникновения таких устройств как SBC стали различные конструктивные недостатки протокола SIP.

Важно понимать, что, несмотря на все приложенные усилия, стандарт протокола не является идеальным и для этого существует множество причин.

Над стандартами работает много людей с различными мнениями и целями. В этой связи часто появляются обновления стандарта, различные расширения и дополнения. Весь процесс в некоторой степени похож на законодательство.

Вероятно, самой большой ошибкой в дизайне SIP было игнорирование существования NAT. Эта ошибка возникла из-за убеждения руководства IETF (инженерный совет интернета) в том, что пространство IP-адресов в скором времени будет исчерпано и потребуется глобальный переход на IPv6, который и устранит необходимость в NAT.

SIP предполагает, что NAT не существует, это предположение и оказалось неудачным. SIP просто не работает для большинства пользователей интернета, которые находятся за NAT. Это и послужило причиной появления устройства, которое начало решать данную проблему: преодоление NAT.

Многочисленные абстрактные понятия в SIP, привели к тому что разработчики ПО толковали их по-разному, хотя некоторые из этих понятий и были исправлены в более поздней версии SIP и его расширениях, но уже существующие к тому времени различные SIP устройства имели свои особенности работы. Это привело к необходимости нормализации SIP протокола.

Другая немаловажную проблема это безопасность и скрытие внутренней топологии сети от внешнего мира. Интернет далеко не дружелюбная среда, постоянные попытки взлома, сканеры, брутфорсеры все это является угрозой для организации.

Все эти и другие проблемы послужили причиной возникновения устройства, которое обыкновенно находится на границе между сетями двух операторов или между сетью оператора и предприятия, а также между предприятием и оконечными устройствами пользователей, предоставляя таким образом единую точку доступа. Это устройство не имеет ничего общего с файрволами, в то же время обладает необходимыми функциями для качественного обеспечения безопасности и бесперебойного предоставления услуг передачи голоса в IP сетях.

И так, что такое SBC?

SBC это пограничный контроллер сессий. Он бывает самых разных форм, может иметь огромное количество функции и использоваться операторами и предприятиями для разных целей. Одна и та же реализация SBC может действовать по-разному в зависимости от его конфигурации и варианта использования.

Таким образом, достаточно сложно дать точное определение SBC, которое будет применяться ко всем реализациям. Однако в целом можно определить некоторые функции, которые являются общими для большинства SBC. Например, большинство SBC реализовано как B2BUA. B2BUA это сервер, который разделяет транзакцию SIP на две части: на стороне пользователя UAC, он действует как сервер, a на другой стороне, он действует как клиент. Тем самым SBC фактически нарушает сквозную природу соединений SIP.

Существует два сценария использования SBC это peering и access.

В первом случае SBC установлено между сетями операторов, которые обмениваются трафиком. Оператор может использовать SBC, чтобы контролировать доступ к своей сети, защищать свои шлюзы от несанкционированного использования и различных атак (DoS/DDoS), для мониторинга сигнального и медиа трафика. SBC также упрощает менеджмент внутренней сети, являясь единой точкой доступа, с которой разрешен трафик для всех внутренних устройств.

В access сценарии SBC размещен на границе между сетью доступа (внешняя сеть) и сеть оператора / предприятия (внутренняя сеть). Основные функции это контроль доступа, защита компонентов сети (медиа серверов, серверов приложений, шлюзов и т.д.) от несанкционированного использования и DoS/DDoS атак. В отличие от peering, в access сценарии SBC должен уметь обрабатывать REGISTER запросы, изменяя их таким образом, что все последующие запросы для зарегистрированного AoR проходили через SBC. Кроме того, некоторые конечные точки могут быть за NAT-ом. В этом случае SBC должен уметь решать эту проблему (far-end NAT traversal).

К вопросу о Kamailio

Является ли Kamailio SBC? Нет. Конечно, Kamailio это не SBC, по своему первоначальному предназначению. Kamailio это SIP прокси сервер. А вот может ли Kamailio выполнять функции SBC? Это уже другой вопрос, который лучше привести к форме: можно ли реализовать SBC, взяв за основу Kamailio SIP прокси? Ответ на этот вопрос можно дать только после того, как точно известно, какие именно функции нам необходимы.

По своему опыту могу сказать, что большинство задач, связанных с реализацией Kamailio как SBC сводятся к конфигурации некоего SIP файрвола с функцией агрегации и балансировки трафика + медиа прокси и обход NAT для клиентов. В некоторых вариациях это может быть также WebRTC шлюз, может включать транскодирование, интеграции с различными биллинг решениями и многое другое.

Ниже я приведу описание некоторых возможностей, которые позволяют реализовать Kamailio в качестве пограничного контроллера сессий:

Безопасность (SIP FIREWALL, secfilter)

Обеспечение безопасности пользователей и бизнеса это задачи с повышенным приоритетом. В современном мире, особенно в мире VoIP, атаки случаются 24/7. Многие наверняка знакомы с ситуацией, когда на только что установленный sip сервер сразу же начинают поступать регистрации или инвайт запросы с различных адресов.

Очень важно иметь возможность для настройки и корректировки правил безопасности, иметь гибкий механизм для мониторинга и своевременного оповещения о возникновении угрозы. Иметь возможность оперативно добавлять новые правила в зависимости от ситуации.

С Kamailio можно решать следующие задачи:

отслеживать большой объем трафика с одного и того же адреса (DoS/DDoS), обнаруживать большое количество неудачных попыток аутентификации (bruteforce), разрешать трафик только из определенных регионов, ограничивать количество активных сессий от одного пользователя или для транка, отслеживать аномалии в продолжительности и количестве вызовов и ограничивать оные.

Кроме того Kamailio можно интегрировать с IM и получать оповещение, например в слак канал.

Скрытие топологии (TOPOLOGY HIDING)

Скрытие топологии необходимо по коммерческим причинам, например транзитные провайдеры не хотят раскрывать клиентам своих поставщиков, и конечно же и из соображений безопасности. Для того чтобы скрыть топологию сети необходим B2BUA.

Kamailio может притворятся B2BUA с помощью модулей topoh и topos, которые используют два разных подхода к сокрытию сетевых адресов.

Оба подхода вполне справляются со своей задачей, но так как все же Kamailio по своей природе это SIP прокси, то иногда могут возникнуть случаи, когда скрытие топологии работает не совсем так, как ожидалось. В этих случаях на помощь может прийти, незаслуженно недооцененный в VoIP сообществе SEMS с его модулем sbc, который отлично справляется с данной задачей.

Регистрация пользователей (REGISTRAR)

Kamailio превосходно выполняет функции регистратора. Если в архитектуре VoIP сети предполагается концентрация большого количества регистраций на одном централизованном узле, то Kamailio это отличный выбор.

В сценариях, когда большое количество мобильных клиентов регистрируются на одном устройстве, может понадобиться так называемый "промежуточный регистратор" (mid registrar), который может уменьшать нагрузку на основной регистратор путем "поглощения" частых перерегистрации клиентов и преобразования их в менее частые.

Надо сказать, что в OpenSIPs уже есть готовая реализация данной функциональности в модуле mid_registrar. В Kamailio эту логику, при необходимости, можно написать самостоятельно.

Маршрутизация и балансировка трафика (LCR, DROUTING, etc)

Это одна из основных функций SBC. Стоит отметить, что чем больше возможностей она предоставляет тем лучше. В Kamailio для решения этой задачи есть сразу несколько модулей, работающих из коробки: lcr, carrierroute, drouting, pdt, dispatcher, prefix_route. Очень часто в конфигурации используется комбинация из нескольких модулей, что дает возможности для гибкой настройки маршрутизации на основе IP адресов, А и Б номеров, доступности транков, времени суток, стоимости трафика, на основе местоположения (lost модуль) и так далее.

Манипуляция SIP заголовками (TEXTOPS)

Часто возникает необходимость добавить или изменить значение в SIP заголовке, добавить свой или же наоборот удалить (скрыть) лишние заголовки. Камаилио легко справляется с этой задачей. Также имеется возможность манипулировать SDP.

Конвертация протокола и разделение сетей

В сценариях, требующих маршрутизировать SIP трафик через несколько интерфейсов, Kamailio может выполнить мостовое соединение (бридж) между различными IP-сетями (внутренними и внешними, IPv4 и IPv6) или между различными транспортными протоколами для SIP (например, динамически конвертировать UDP в TCP или TLS).

Обеспечение работы клиентов за NAT (NAT TRAVERSAL)

Если SBC используется в access сценарии и на нем регистрируются абоненты, то в большинстве случаев они будут находиться в где-то в приватной сети, за роутером или wi-fi точкой доступа, в этом случае необходима реализация обхода NAT со стороны сервера (server-side NAT traversal). Нужно упомянуть также, что существуют еще и обход NAT со стороны клиента (client-side NAT traversal), в этом случае ответственность за определение своего внешнего адреса лежит на клиенте (STUN,ICE). В Kamailio обход NAT можно реализовать с помощью модуля nathelper, расширения rport (RFC3581) и rtpengine.

Медиа прокси (RTP RELAY)

Kamailio работает с SIP сигнальным протоколом и не знает ничего о RTP. Для реализации медиа прокси нужно использовать стороннее приложение. Есть несколько на выбор, все отлично справляются со своей задачей, но на одном стоит заострить внимание это rtpengine.

Компания Sipwise занимается разработкой rtpengine уже более 10 лет. Он отличается от других RTP прокси своим богатым функционалом. Rtpengine использует пересылку пакетов в привилегированном режиме (kernel mode), это позволяет добиться передачи RTP на скорости, близкой к скорости передачи данных. Кроме того у него есть множество функций: поддержка SRTP, ICE, возможность делать записи разговоров, транскодирование и даже возможность проигрывать звуковые файлы.

Также rtpngine можно легко масштабировать, достаточно добавить больше инстансов и объединить их в кластер. Есть поддержка репликации RTP сессий в режиме реального времени с использованием redis.

Репликация данных и отказоустойчивость

О построении отказоустойчивого кластера и катастрофоустойчивости можно написать отдельную статью, нюансов здесь достаточно. Репликация данных в Kamailio реализуется с помощью модуля dmq, который качестве транспортного протокола использует SIP, может мониторить и обнаруживать новые ноды в сети, автоматически синхронизироваться после сбоя. С помощью этого модуля возможно реплицировать динамические данные, такие как: состояние активных сессий, регистрации, данные хэш таблиц, статусы присутствия клиентов (presence).

Также для репликации можно использовать SQL, например модуль db_clusterer, который является своего рода "прослойкой" между модулями и базой данных.

В заключении хочу вернутся к тому с чего я начал статью: Kamailio это не SBC, но те функциональные возможности, которые он имеет, обширный набор модулей, поддержка REST, RPC, websockets, позволяют программисту, а для написания скрипта Kamailio Вам понадобится некоторый опыт разработки ПО, реализовывать практически любые сценарии и интеграции как на нативном языке, так и с помощью KEMI на таких языках как python, lua, javascript.