Voice: VoIP, SIP, ALG заметки

• Много инфы ниже взято из подкаста про телефонию/QoS Linkmeup от спикера Сергея Глушко (voxlink.ru) – один из лучших подкастов!
• Работа с Wireshark/sngrep в контексте VoIP подробнее описана в отдельной статье
• Законодательство зачастую «против» ИТ технологий и телефонии – создается де-факто/де-юре противоречие
  • Питерский номер находясь в Мск нельзя использовать
  • облачные АТС формально не могут выполнять свою деятельность т.к. весь транспорт должен принадлежать одной организации; поэтому провайдеры БЦ, зная это, могут специально резать sip чтобы клиенты покупали у них голосовые услуги (тут их отфутболить можно бумажно жалобой в РКН, что режется корпоративный голосовой трафик / или технический способ vpn/изменение портов)
• Зачастую не нужно менять классические стационарные телефоны для использования VoIP: они легко подключаются к voip шлюзу типо eltex tau – использовали такие в Билайне, норм. По отзывам и со стороны voxlink тоже вариант отличный. Такая схема позволяет очень сильно экономить в занимаемом пространстве – вместо помещения (телефонная станция) оборудование для подключения 3к сотрудников занимает стойку. Так же относительно популярны (напр. на заводах) методы интеграции между старыми телефонными станциями и VoIP серверами – когда не всем сотрудникам нужен VoIP, но все сотрудники должны иметь возможность дозвониться до всех.

За

• SIP (udp 5060) – служебный протокол для согласования кодека и адресации (IP/ports) между абонентом и сервером или двумя абонентами для будущего RTP потока, сам SIP голос не передает.
• Взлом серверов VOIP (не важно asterisk или другого, главное взломать – чаще всего сервер торчащий наружу с белым ip и открытым для всех sip 5060) и исходящие звонки хакерами на левые номера с автоответчиками чтобы получить денег от владельцев платных номеров – частая история. Есть даже специальные биржи, которые позволяют связать между собой хакеров и владельцев, под хакеров специально заводятся номера/экстеншены, на которые осуществляется прозвон. Но еще хуже – взлом и «закладка» бомбы (была уязвимость avaya). На asterisk достаточно много настроек, которые позволяют подкручивать его безопасность – fail2ban и проч.
• Помимо взломов возможен DoS SIP invite публичного сервера

• Вообще неоходимость указания в SDP (Session Description Protocol) адресации изначально имеет логику – подразумевалось что сервер телефонии нужен для последующего соединения клиентов напрямую (минуя сервер телефонит). По факту прямое соединения это скорее исключение и работа обычно ведется через сервер телевонии (напр. иначе запись с разговоров при потребности реализовать сложнее).
• SIP и H.323 – это по сути два протокола, которые решают одну задачу (передача голоса поверх IP сети), но выпущены с разными подходами в уме. H.323 с точки зрения поддержки технологий телефонии, которые были всегда – раньше H.323 был более популярен, сейчас уже более популярен SIP (особенно у конечных абонентов), H.323 в основном используется только в между операторами связи, внутри одного оператора, любители Panasonic :)относительно недавно только разрешили SIP на меж-операторских стыках – ранее только H.323. При этом и SIP в какой о мере сохранил некоторую legacy конструкцию (в данном случае коммутацию каналов) – не один сокет выделяется на сервере под клиентов, а на каждого клиента создается свой сокет.
• Сервера OpenSouce: Kamailio, FreeSwitch, Kazoo, ASTERISK

asterisk

• (Voip, mikrotik, qos) Парни активно используют QoS для решений клиентов на базе VoIP Asterisk, первоначально ставили cisco (было много б/у), потом переехали на Mikrotik и рады – более 200 инсталляций для soho/medium бизнеса; по рекомендации Cisco (да и из логики) для голоса лучше всего подходит Low Latency Queue (LLQ) (Linkmeup)
• Настраивали иностранному заказчику «закладку» в виде повышения/повышения тембра голоса каждого 20-го звонка и если заказчик закроет доступ к инфре и не оплатит деплой в течении Х дней активируется этот конфиг (Linkmeup)
• Реализация шифрования голоса чаще всего реализуется наложенным vpn, но в целом asterisk поддерживает шифрование tls sip и srtp, но тут проблема, что телефоны легально в РФ не поддерживают эти протоколы (если специально не перепрошивать)
• У asterisk нет нативной/встроенной в ПО сервера кластеризации, поэтому она если необходима решается наложенными средствами – линуксовыми утилитами (drdb, heartbeat, portinc). Voxlink в целом считает такое решение спорным, хотя и готовы его при необходимости деплоить – спорным т.к. наложенные средства, реализующие отказоустойчивость, усложняют систему, а это уменьшает характеристики стабильности/закладывает возможные доп. проблемы (принцип KIIS). По их практике лучше иметь холодный резерв в виде бекапного сервера (hardware/vm) с синхронизацией с какой то периодичностью с основным, который вручную активируется при проблемах с основным. Тоже считаю это нормальная идея, а при жестком sla по времени я бы посмотрел в сторону автоматизации – использования скриптов на сервере мониторинга/сетевом оборудовании, которые автоматически поднимают бекап ноду при отказе основной.

cucm

Cisco Unified Communications Manager Express (CUCM/CME), всю инфраструктуру поднять можно в GNS3 на базе роутера Cisco 3725 как сервера с софтфонами как клиентами, взаимодействие по skinny protocol (SCCP). 

CALLER ID

Обычно SIP оператор проверяет (и зачастую жестко подменяет) то, что подключающийся передает в caller id (исходящий номер), иначе через SIP сервер будут звонить в МЧС, фродить от лица сбербанка и проч подставляя в src что угодно.

Односторонняя слышимость, работа voip через Nat, sip alg

Разговор в VoIP состоит из двух unicast RTP (Real-Time Transport Protocol) потоков – один от src до dst, второй от dst до src. Это видно и в Wireshark (там можно посмотреть в том числе дампы).

Причина односторонней слышимости – один из потоков (туда/обратно) не проходит до получателя, связь unidirectional. Траблшутим прохождение (firewall, nat, routing).

Траблы при односторонней слышимости обычно связаны с включенными костылями для NAT типо SIP ALG которые работают не так, как надо. SIP зачастую прекрасно работает через NAT без сторонних костылей.

NAT зачастую ломает SIP (основной симптом – односторонняя слышимость) из-за того, что RTP поток должен как то попасть к устройству за NAT. Если говорить про работу через NAT (чего лучше по максимуму избегать в пользу VPN – это самый простой/правильный способ решения проблем с NAT), то наиболее логично использовать следующие методы 

• • в ACL можно в сторону телефонов/сервера прописать статически port forwarding (для каждого телефона сделать свой порт) для разрешения SIP трафика
  • в ACL можно прописать разрешение диапазона портов для RTP трафика
  • между Asterisk можно настроить IAX2 (Inter-Asterisk eXchange protocol) протокол от создателей самого Asterisk (на телефонах достаточно редко поддерживается), чтобы сигнализация и данных передавались в рамках одного соединения + в бинарном виде, в итоге этот протокол легко решает проблемы с NAT. Нормальной схемой обхода NAT, когда абонентов более 3-5, установка локального Asterisk (виртуалка) для этого сегмента и использование IAX2 между локальным Asterisk и Asterisk в HQ. Так же кроме IAX2 на Asterisk может быть настроен внешний IP статически (или с использованием stun + пробросом sip/rtp портов) для использования при передаче SDP в HQ + обычно в таком случае настраивается серый IP и диапазон адресов, при работе с которыми используется серый IP.
  • Кейс asterisk с белым IP, а телефоны за NAT (если в локалке одной это все безусловно не нужно): в Asterisk есть настройка игнорирования информации в sip пакете (comedia), в таком случае Asterisk отправляет трафик RTP только клиенту в ответ; в таком случае нужно так же настроить
    • keepalive/qualify пакеты для передачи между сервером и клиентами (с обеих сторон) для уменьшения вероятности/влияния проблем с истечением сессий/перезагрузки firewall
    • уменьшить интервал повторной регистрации клиентом на сервере с «раз в час» на «раз в 5 минут»
      
      

stun

STUN (Session Traversal Utilities for NAT) – мертворожденная по большому счету технология по аналогии с SIP ALG и ей у них не обучают (voxlink). Смысл – это по сути клиент узнает свой внешний IP (аналогия myip.ru) и может его подставить в SDP, но при этом SIP/RTP каналы к клиенту она никак не открывает в NAT девайсе (т.е. все равно нужно пробрасывать порты). Кроме того STUN далеко не на всех телефонах реализован. Применение технологии норм только когда за NAT находится сервер Asterisk – в с случае с динамическим IP он сможет его обновлять.

Sip ALG

Хорошая презентация о SIP ALG от MikroTik. Особенно последний слайд – не используйте ALG, используйте VPN 🙂

SIP ALG (и анализ протоколов типо DPI) на практике для этой задачи ALG стараются избегать по максимуму – от ALG чаще больше проблем (причем в виде многих часов на траблшутинг), чем пользы.

Кодеки

Преобразуют (кодируют) аналоговый (звуковой) сигнал в цифровой формат для передачи и декодируют при приеме.

• G.711 default Asterisk codec (грубо ~100 кбит/с на звонок = 64 кбит/с кодек и 16 кбит/с overhead) – no compression (MOS 4.1), с двумя схемами (алгоритмами) кодирования (оба примера payload есть в статье Wireshark):
  • a-law – используется в Европе и компаниями оттуда
  • u-law – используется в USA и компаниями из USA (Cisco)
• G.721/723/729/gsm – compression по уровню, вместо грубо ~100 кбит/с получаем звонок в 24 кбит/с (G.729 = 8 кбит/с кодек + 16 кбит/с overhead) или даже 
  • GSM считается не лучшим кодеком по качеству сжатия/качеству голоса (MOS 3.7)
  • G.729 формально закрыт патентом и на некоторые версии asterisk его нужно ставить отдельно (MOS 3.9)
• iLBC кодек – (internet Low Bitrate Codec) – крутой кодек, по качеству лучше G.729, лучше реагирует на потери (меньшее влияние на качаство звука при потерях), редко реализован на конечных девайсах и даже на asterisk его надо зачастую добавлять.
• G.722.2 / HD Voice (широкополосный звук) — аудиотехнология, используемая в телефонии. Для улучшения качества звука используется аудиокодек Adaptive Multi-Rate Wideband (AMR-WB), стандарт G.722.2. Это адаптивный кодек, который подстраивает кодирование под фактическую полосу.

VOICE MOS (mean opinion score)

• примеры оценки MOS типовых кодеков выше

Absolute Category Rating Rating Label
5 Excellent
4 Good
3 Fair
2 Poor
1 Bad

«О качестве голосовой сотовой связи», «О качестве мобильного доступа в сеть интернет».
https://www.mos.ru/upload/documents/oiv/random_120628033432_phpapp01.docx
https://www.2test.ru/solutions/seti-peredachi-dannykh/resheniya-dlya-drayv-testov-i-benchmarkinga/apparatno-programmnyy-kompleks-dlya-kontrolya-raboty-radiointerfeysa-ascom-tems-investigation.html
- Оценка 3,2 и ниже может характеризовать появление дискомфорта и ухудшения качества речи во время разговора.
- Оценка 2,6 и ниже характеризует низкое качество связи с искажениями в голосе, пропадание речи, постоянные «переспросы» абонентов и т.д.
Измерения проводились с помощью специализированного программно-аппаратного комплекса Ascom TEMS Investigation, включающего в себя:
- 3 мобильных абонентских терминала поддерживающих стандарты 2G и 3G (по одному для каждого оператора сотовой связи);
- 3 внешние антенны GSM установленные на крыше автомобиля с разнесением 40 см друг от друга;
- модуль GPS для регистрации спутниковых координат и времени измерения;
- ноутбук с установленным программным обеспечением TEMS Investigation.


Spirent umetrix voice lm
By default, a call is classified as bad quality if it has a MOS of less than 2.20. 
 


ГОСТ Р 51061-97
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ НИЗКОСКОРОСТНОЙ ПЕРЕДАЧИ РЕЧИ ПО ЦИФРОВЫМ КАНАЛАМ

Баллы Характеристика качества речи
4,6-5,0 Естественность звучания речи. Высокая узнаваемость. Полное отсутствие помех и искажений
4,0-4,5 Естественность звучания речи. Высокая узнаваемость. Отдельные малозаметные искажения или помехи
3,5-3,9 Естественность звучания речи. Высокая узнаваемость. Слабое постоянное присутствие отдельных видов искажений или помех
3,0-3,4 Незначительное нарушение естественности и узнаваемости. Заметное присутствие отдельных искажений или помех
2,5-2,9 Заметное нарушение естественности и ухудшение узнаваемости, присутствие нескольких видов искажений (картавость, гнусавость и др.) или помех
1,7-2,4 Существенное искажение естественности и ухудшение узнаваемости. Постоянное присутствие искажений типа картавость, гнусавость и др. или помех
<1,7 Сильные искажения типа картавость, гнусавость и др. Механический голос. Наблюдается потеря естественности и узнаваемости

MOS historically originates from subjective measurements where listeners would sit in a "quiet room" and score a telephone call quality as they perceived it. This kind of test methodology had been in use in the telephony industry for decades and was standardized in ITU-T recommendation P.800.

MOS is a commonly used measure for video, audio, and audiovisual quality evaluation, but not restricted to those modalities. ITU-T has defined several ways of referring to a MOS in Recommendation P.800.1, depending on whether the score was obtained from audiovisual, conversational, listening, talking, or video quality tests. The MOS is expressed as a single rational number, typically in the range 1–5, where 1 is lowest perceived quality, and 5 is the highest perceived quality.

https://en.wikipedia.org/wiki/Mean_opinion_score

https://en.wikipedia.org/wiki/Absolute_Category_Rating

The Absolute Category Rating scale is very commonly used, which maps ratings between Bad and Excellent to numbers between 1 and 5, as seen in below table.

it is not meaningful to directly compare MOS values produced from separate experiments, unless those experiments were explicitly designed to be compared, and even then the data should be statistically analysed to ensure that such a comparison is valid.

ТЕЛЕФОНЫ

avaya

факсы

• Факсов все меньше – он перестал быть более юридически значимым документом в сравнении с условной электронной почтой
• Телефонисты fax пишут как fux, некоторый намек
• Asterisk работает с факс девайсами – с какими то лучше, с каким то хуже; многое зависит от провайдера, выбранного метода взаимодействия с ним (e1 ok, аналоговые каналы ок, voip каналы вопросы/проблемы)
• Для взаимодействия между сервером и провайдером поверх voip может использоваться протокол T.38, который специально под эту задачу был разработан, но по факту зачастую лучше его отключить и передавать факсы по кодеку G711 (важно чтобы канал был без задержек/потерь)! Потому что T.38 реализован по разному на разных девайсах, тяжел для траблшутинга и даже операторы его поддерживающие по факту его могут уже не поддерживать 🙂