VoIP — это термин-зонтик. Набор технологий, протоколов и просто buzzword'ов, которые относятся к передаче голоса (и видео!) по компьютерным сетям (локальным или интернет) вместо телефонных. И да, большая часть телеком-провайдеров всё ещё использует для передачи голоса собственные сети вместо интернет. С недешевыми коробочками, куда втыкаются T1 и E1 провода.Чаще всего, для айтишников, не работающих в телекоме, VoIP – это связка RTP/RTCP для передачи голоса/видео плюс SIP – для договориться, кому и как передавать. Именно это связка позволяет подключить офисные «SIP телефоны» к Bitrix24 или Asterisk. Оба протокола могут работать как по TCP, так и по UDP. С передачей голоса по RTP вопросов нет: за редчайшим исключением используется UDP протокол, а кодеки компенсируют потерянные пакеты, так что собеседник почти не «квакает» даже не на самом лучшем канале связи. А вот с SIP история более печальная.
Вообще, SIP — это такой HTTP для телефонии. Про него на Хабре есть замечательный двухсерийный пост. Если кто интересуется, очень рекомендую. Ключевое отличие от HTTP, что SIP должен работать в обе стороны всегда. Задача «отправить сообщение с сервера на клиент» решалась в HTTP очень много лет, пережила AJAX, WebSockets, и сейчас наконец-то стабилизировалась в виде HTTP/2. А в SIP эту задачу нужно было решать сразу: не только телефонный аппарат отправлял запрос «вот он я, готов принимать звонки», но и сервер должен был иметь возможность в любой момент сообщить клиенте «а вот тебе и звонок, принимать будешь?».
А у TCP, при всех его достоинствах, есть и недостатки. Например, соединения могут «протухать». Если не поставить маленький keep-alive (а SIP был создан в 1996-м году) и постоянно не отсылать пинги, то «подключение» может оборваться с одной стороны, а вторая сторона этого не заметит. Хорошо, если оборвалось со стороны клиента — он это заметил и переподключился. А если оборвалось со стороны сервера? Нужно ждать, пока у клиента случится keep alive или какой-нибудь другой таймаут и он переподключится. А в это время клиенту звонок.
А еще 20 лет назад, когда это всё создавалось, был очень печальный вопрос переподключения. Для UDP версии SIP клиентам достаточно время от времени (раз в час) посылать пакеты REGISTER, говоря «вот он я, готов принимать звонки». В случае перезагрузки или выключения сервера другой сервер за тем же IP-адресом может работать со всеми этими клиентам. А вот в случае TCP клиентам нужно будет переподключаться. Десять тысяч телефонов здания (обычная ситуация) пошли переподключаться и убили сервер…В общем, все ждали, что SIP будет по TCP. А он стал по UDP. Сейчас, 20 лет спустя, все больше компаний переключаются на «только по tcp». Тем не менее, огромный парк устройств, клиентов и инфраструктуры ходили по UDP, ходят по UDP и ближайшие несколько лет ходить будут.
А в комбинации «SIP и UDP» есть беда. Собственно, этот пост про нее. Беда называется «фрагментация». Сама по себе фрагментация сетевых пакетов почти безвредна: есть настроенный для сетевой карты MTU, максимальный размер передаваемого за раз пакета. В большинстве случаев это 1500 байт. Для TCP и подавляющего большинства UDP протоколов это никак не влияет: они просто никогда не шлют пакеты больше MTU и используют внутренние механики, чтобы передавать большие объемы данных по кусочкам, терять эти кусочки и пересылать их повторно, если надо.А SIP — он как HTTP. Текстовый. И в последние годы к простым командам вроде «я тут» и «тебе звонок» добавилась куча дополнительных полей и всяких XML/JSON в пайлоадах. Размер получающихся пакетов стал регулярно выходить за пределы MTU. Начиная с этого момента история становится совсем печальной.
Современный интернет — он, на самом деле, не очень хорошо приспособлен к фрагментированным сетевым пакетам. Производители оборудования и авторы софта резонно полагают, что большинству софта такие пакеты слать не нужно. TCP фрагментирует сам, UDP — это realtime команды, видео и звук. Им не нужно быть больше MTU. Если потеряются, ничего страшного не произойдет. И не очень заморачиваются, насколько хорошо их решения поддерживают фрагментированные пакеты. Свичи могут крешится. «Корпоративные» железки, делающие свои надстройки поверх ethernet/ip, не могут фрагментацию и молча игнорируют пакеты. А у некоторых железок буфер на сборку фрагментированных пакетов — на целых 200 штук. Переполняется он на удивление легко.
Все это мы видим в техподдержке, когда «звонки то работают, а то не работают». Хорошо, когда есть команда инженеров, которые могут запросить у телеком оператора SIP-логи, вдумчиво почитать и ткнуть пальцем в «проблемный» участок. Намного хуже, когда в компании один Asterisk и админ-удаленщик, его обслуживающий. В таком случае «просто магия, иногда звонки не доходят».
Сейчас все стараются использовать SIP по TCP, но проблема отставания инфраструктуры за последние несколько лет встала очень остро. Все больше видео и голосовых звонков совершаются через браузеры (чего стоит только недавно вышедший «Skype для веб»). С какой скоростью развивается веб, мы с вами прекрасно знаем: набежавшие разработчики принесли с собой привычные JSON и XML пайлоады, а видеоконференции на 20-30 человек перестали быть уделом крупных компаний, где бородатые админы могли неделями настраивать циски, «чтобы работало».
Вывод: увидите SIP и UDP в одном месте — будьте осторожны. И при первой возможности переключайте на TCP!
Ссылки позаимствованы вот из этой статьи, которая рассматривает проблему гораздо глубже и тоже рекомендует по возможности использвать TCP
А картинка для привлечения внимания — вот отсюда
Комментарии (57)
manchelsi
19.06.2017 15:06+4А может не надо тащить в SIP привычные JSON и XML пайлоады? В аналог же не тащите…
eyeofhell
19.06.2017 15:06+2Так привычки же. Я — не тащу. А вот более молодые разработчики… Ну вы понимаете :)
JC_IIB
19.06.2017 15:22Линейкой по рукам таким разработчикам, и RFC 3261 пусть курят до просветления. Зачем тащить xml/json в SIP??? Что еще за дикие идеи?
manchelsi
19.06.2017 15:37+3В таком случае, советуйте молодым разработчикам фрагментировать данные перед отправкой. UDP для SIP абсолютно на всех устройствах выбран по-умолчанию. Своим юзерам говорить, что работает у нас SIP only TCP — непросто, проще даже настроенное оборудование поставлять.
На эту и подобные темы, не зря, Международным союзом электросвязи (ITU-T) для передачи мультимедиа-данных был рекомендован протокол H323. Народ выбрал то, что намного проще — SIP. Если вы будете раздувать SIP — Вас не очень поймут. На то он и призван быть простым, чтобы пакет мог легко выполнить 70 дефолтных переходов (Max-Forwards), в случае надобности.
По сему 3 варианта:
1)Фрагментировать самим.
2)Настраивать оборудование.
3)Последовать рекомендациям ITU-T.
eyeofhell
19.06.2017 15:25path mtu discovery? Его сейчас реально ктото делает из популярных операционок? Винда там, андроид, вот эти все ребята? О_О
degs
19.06.2017 17:59PMTU делают по моему все, одако проблем он не решает. Path MTU discovery работает (для TCP, don't fragment flag is set) следующим образом: пакет дропается а источнику отправляется соответствующий ICMP. Это imho крайне неудачный механизм, по сути negative ACK, старательно избегаемый в базовой версии TCP. На практике все сетевые устройства ограничивают генерацию ICMP и в ситуации подобной примеру (10000 клиентов одновременно посылают пакет > MTU) большинство из них впадет в экспоненциальный ретрансмит и зависнет навсегда.
mayorovp
20.06.2017 08:54Для достаточно умных промежуточных устройств есть еще альтернативный механизм с редактированием заголовка TCP...
degs
20.06.2017 15:56Не слышал, а чем это поможет? Если пакет не пролазит в MTU следующего сегмента, его по любому придется либо сегментировать, либо дропнуть.
mayorovp
20.06.2017 16:03Пакет SYN, идущий без данных, в MTU пролезет всегда. А дальше — обе стороны уже будут знать PMTU и не будут посылать больших пакетов. Если, конечно, маршрут внезапно не сменится.
degs
20.06.2017 16:43Вы хотите сказать что все промежуточные устройства редактируют TCP header обновляя поле MTU? Логично, однако это работает только для статических маршрутов с известными узлами. Более того, оконечные устройства все равно должны быть готовы обрабатывать фрагменты.
netch80
21.06.2017 07:57> с редактированием заголовка TCP.
Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.mayorovp
21.06.2017 11:24Так же, как маршрутизаторы узнают о необходимости фрагментировать пакет.
netch80
21.06.2017 16:27Нет, так как раз не получится. Раутер послал свой needfrag и забыл. Он не будет ставить у себя память «вот для этих спецправило — ставить MSS». Такое спасение утопающих — только их дело, в лучшем случае, ближайшего своего шлюза.
aylarov
19.06.2017 15:26+2SIP по TCP ничем не лучше чем SIP по UDP, хотя бы по тому, что стандартом де-факт является UDP-вариант, а TCP все поддерживают чтобы было, очень часто из-за этого проблем там еще больше по факту.
graphican
20.06.2017 07:51+1Для передачи звука/видео и прочего, требующего реального времени, UDP больше подходит: ТСР сильно сужает полосу при возрастании потерь, так что на мобильном интернете плохо работает. ТСР будет слать уже неактуальные данные, пока не дошлёт. Но у ТСР несколько лучше дела обстоят с файрволами. UDP часто закрыт, особенно в корпоративных сетях. UDP-flood способен намертво повесить сервер из-за огромного количества прерываний, если трафик лить на открытый UDP-порт, даже объединение нескольких пакетов в одно прерывание не помогает.
aylarov
20.06.2017 08:26DoS он везде одинаковый, что по TCP, что по UDP, большой разницы нет. Как будто TCP-flood нельзя организовать
graphican
20.06.2017 10:22+2по UDP можно трафик лить с одного хоста через подмену адреса отправителя и маршрутизаторы этот трафик не блокируют (на моей практике). SYN-flood с некорректным адресом отправителя неплохо режется
AndrKV
20.06.2017 07:51-2«Смешались в кучу кони люди»
Не читайте эту статью — она вас плохому научит.
во время SIP сессии — различают две части.
Сигнальную и голосовую.
Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.
А вот голосовая идёт по RTP поверх UDP или TCP.
И здесь проблем с фрагментацией не наблюдается. Потому как проблема ровно обратная — overhead. Голосовые пакеты настолько маленькие, что overhead даже через UDP может достичать 100%. Т.е. длина заголовка UDP ~ равна полезной нагрузке. (у разных кодеков по разному)
Размер пакета у кодека G.729 — 20 байт. У G711 — 160 байт. Поэтому до фрагментации там как пешком до луны
eyeofhell
20.06.2017 07:52+6Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.
Я просто скажу, что это не так. Ок? :)
Ovoshlook
20.06.2017 10:27-3Проблема SIP ( сигнализации ) и длины пакета в большинтстве своем не видна, так как в общем и целом пакеты с самом SIP не большие. Нет там такого огромного количества информации чтобы дойти до ограничений. Даже с описанием видео сессии. Много данных гоняется через websockets но там TCP, так что паника надумана как по мне.
eltel
20.06.2017 10:48Тоже не вижу проблем, один раз за всю свою практику сталкивался с этим, когда размер INVITE`а переваливал 1500 и… не работало) Начинаешь смотреть, что не так и, внезапно, в этом INVITE`е в SDP перечислено 100500 ненужных кодеков и левых хидеров. Снимаем дамп и настраиваем правильно)
eyeofhell
20.06.2017 10:48-2Так вот, за последние пару лет все поменялось. Особенно с видеоконференциями. Прогресс, вот это всё.
Ovoshlook
20.06.2017 10:58+2С видео конференциями — понятно, там банально информации больше гоняется, а то, о чем вы пишите, касается всего SIP. Из пушки по воробьям палите.
Вы тогда у и пишите что, мол, при таких-то и таких-то случаях данная проблема возникает. А так под одну гребенку все. Зачем?
eyeofhell
20.06.2017 11:31Интересная и слабоосвещенная тема. Плюс английская статья про то же самое хорошо зашла, https://200ok.info/2017/03/31/sip-and-fragments/ — я же слежу за индустрией. Так что рассказать на Хабре, судя по просмотрам и плюсам, было здравой идеей. Ну а что тема спорная — в том и интерес.
AndrKV
20.06.2017 14:55-3Ну, хорошо.
Напишу так.
При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)netch80
21.06.2017 07:48+2> При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.AndrKV
21.06.2017 12:09-2Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?
А на стенде много чего можно накрутить.
В нормально настроенном оборудовании IMHO, нужно всего 3 кодека, какой либо HD, G.711 и сильно сжимающий (типа G.729). А при зональном делении и того меньше.
А пихать 15 кодеков, это как иметь 3 антивируса на компьютере.netch80
21.06.2017 16:24+1> Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?
Не-а. Может, это специфика клиентов моей прошлой работы, но такого было валом. Ну пусть не 15 кодеков, но по 10 пытались выставлять, и параметры вписывались чуть менее, чем все. Я мерял — INVITE толще граничных 1300 байт были регулярно.
> В нормально настроенном оборудовании IMHO, нужно всего 3 кодека
Судя по тому, что в типичной железяке, с которой мы работали, были G.711, G.723 в двух профилях, G.729 в двух профилях, GSM, Speex — с Вами мало кто согласен :) Обычно предпочитают выставить побольше, лишь бы связаться хоть как-то. Очень не любят ситуацию, когда звонок не устанавливается потому, что не нашли общего кодека.
А так как до сих пор есть два слабопересекающихся мира с проприетарными и со свободными кодеками, где на пересечении только G.711, который зарезан потому, что слишком большая полоса (а некоторые клиенты из крупных азиатских стран реализовывали свой менталитет зарезанием всего, что толще ~8Kbit/s) — то такое несогласование происходило постоянно. Если удавалось уговорить обе стороны в таком варианте на GSM — это уже была маленькая победа.AndrKV
23.06.2017 15:09-1Отвечу в аналогичном стале
«Сутя по тысячам терминалам и сотням станций разных вендоров которыя я настраивал» таки у вас нетипичные клиенты.
Если кто-то пытается сделать бизнес и на бесплатных кодеках — это лишь его частные проблемы.
Вообще — есть два типа проблем:
Проблемы из-за преминяемых технологий.
Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.
netch80
27.06.2017 09:53+1> «Сутя по тысячам терминалам и сотням станций разных вендоров которыя я настраивал» таки у вас нетипичные клиенты.
Вот вытащил из архива совершенно типовой INVITE от железяки системы SPA2000 (Sipura, потом Linksys). Её наследники напложены в десятках миллионов штук. Тут участвовал наш B2BUA, но состав полей в SDP сохранён.
Скрытый текстINVITE sip:000999529@192.168.0.77:5060 SIP/2.0
Record-Route: <sip:10.0.87.41;ftag=e9345eee27d4d78154172d5c75a97e80;lr>
Via: SIP/2.0/UDP 10.0.87.41;branch=z9hG4bKa868.5d6d0a34bfee705e16121b68c7228f10.0
Via: SIP/2.0/UDP 10.0.87.41:5061;branch=z9hG4bKa0a9c8877cfaf254628c2413433968f3;rport=5061
Max-Forwards: 16
From: 000999528 <sip:000999528@10.0.87.41>;tag=e9345eee27d4d78154172d5c75a97e80
To: <sip:000999529@10.0.87.41>
Call-ID: d591387e-aaf46616@192.168.0.60
CSeq: 200 INVITE
Contact: Anonymous <sip:10.0.87.41:5061>
Expires: 300
User-Agent: Sippy
Content-disposition: session
Content-Length: 464
Content-Type: application/sdp
v=0
o=Sippy 137702988 0 IN IP4 10.0.87.41
s=-
t=0 0
m=audio 35000 RTP/AVP 0 2 4 8 18 96 97 98 100 101
c=IN IP4 10.0.87.40
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv
a=direction:active
AndrKV
27.06.2017 11:04-1И?
Для чего все эти кодеки???
Зачем G.711Mu мы что в штатах?
Для чего вам 4 шт. G726 ?? Да при наличии G.729 и в локальное сети ???
Железку просто не настраивали.
Или настраивали по принципу — включаем всё, может заработает.
P.S. — настройки по умолчанию в сегменте SOHO в ~90% случаем кривые/неоптимальные.JC_IIB
27.06.2017 16:39Про G.726 я отвечу из своего опыта — ранние SPA-шки от Linksys, двухпортовые, не осиляли 2 одновременных разговора на G.729-м, по-видимому, из-за CPU. Выходом был как раз G.726.
silverjoe
20.06.2017 16:40+1По умолчанию везде SIP использует UDP транспорт. TCP вы настраиваете сами.
Остальное все верно.netch80
21.06.2017 07:50> По умолчанию везде SIP использует UDP транспорт.
Цитирую RFC3261:
>> If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP.
Тут даже не SHOULD, тут MUST. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
vanek6666
20.06.2017 12:38Прошу прощения за оффтоп. Уважаемые камрады, не силен в протоколах IP-сигнализации. Есть сервер телефонии под Windows Server 2003, оператор Ростелеком говорит, цитирую: «Но от вас сигнализация идёт по UDP, а не TCP. Соответственно, нужно либо сигнализацию слать по TCP, либо keepalive включать под UDP. Временной интервал 15-30 секунд».Вот что то я и задумался как это реализовать в винде, с Linux было бы чуть проще.
eyeofhell
20.06.2017 12:39+2Взять софт, который телефонию обеспечивает, и переключить SIP с UDP на TCP :) Все как в статье.
vanek6666
20.06.2017 12:55Да все бы хорошо, софт называется infratel call center,4 версия. Документации никакой по софту нет, производитель софта открещивается от этой версии (закончилась поддержка). Два выхода: обновление на новую версию (платно и очень затратно), обращение в саппорт ничего не даст (саппорт платный тоже)
eyeofhell
20.06.2017 13:05Беда-печалька. Если софт менять совсем не вариант, то надо ставить простенький proxy между ним и телеком оператором. И единственное, что будет делать прокси — это добавлять keep alive :) Довольно долго настраивать придется :(
mrobespierre
20.06.2017 13:42+1при первой возможности переключайте на TCP!
вы всерьёз призываете к нарушению RFC? UA должен использовать UDP и переключаться на TCP в случае проблем. M$ с их Lync (SfB) просто забили на стандарт (обычное дело, часть EEE).
в современных Астерисках есть PJSIP, с которым нет проблем совместимости
зато во все времена есть проблема со «специалистами», которые не понимают значения слова «стандарт», и здесь не важно, Астериск они настраивают или что-то другоеeyeofhell
20.06.2017 14:24-1Я ссылку на англоязычную статью оставил, посмотрите — там много референсов. Вот это вам будет интересно: «The SIP standard, RFC 3261 mandates that TCP should be used to prevent fragmented SIP. „
mrobespierre
20.06.2017 15:03извините, не интересно
«RFC 3261 обязывает использовать TCP для предотвращения фрагментации»
т.е. не какие-то другие костыли городить, а использовать TCP.
будет ли происходить фрагментация в 100% случаев? — нет
чем руководствоваться чтобы понять, будет ли происходить фрагментация?
частью 18.1.1 документа:
If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown… 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU
перевод части абзаца выше:
Если разница между размером запроса и размером MTU 200 байт или меньше, или если запрос больше 1300 байт, а MTU не известен…
вместе с тем часть 19.1.2 документа однозначно нам сообщает:
The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP.
перевод предложения выше:
Транспорт по-умолчанию зависит от схемы (URL). Для адресов sip: это UDP, для sips: это TCP.
Таким образом в общем случае использование TCP для запросов меньше 1300 байт противоречит стандарту.
dumbo101
23.06.2017 13:26> увидите SIP и UDP в одном месте — будьте осторожны
Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.
> наконец-то стабилизировалась в виде HTTP/2
Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.eyeofhell
23.06.2017 13:29Я прям-таки вижу сцену: вечер, я в окружении наших сиповиков-телекомщиков пишу статью, Юра с Олегом и Ваней хором — «Да, да! Вот так! Вводи их в заблуждение! И про RTCP не забудь запутать!» :)
dumbo101
26.06.2017 11:24+1Статья про VoIP и фрагментацию UDP. UDP в воипе в основном для RTP, а сигнализация может идти по разному (SIP/TCP, H323 и тд). Так вот, проблема фрагментации только SIP'a что ли (1-3% UDP для ВоИП) или всего остального тоже?.. В SIPe нормально прописано что делать в случае больших пакетов, точно так же как и в DNS — в случае больших пакетов надо посылать по TCP.
Я кстати даже забыл что SIP может по UDP идти :) в мобильных сетях почти все пакеты больше МТУ выходят из-за кучи хмл-мусора
ice2heart
Насколько я понимаю 1500 байт может быть не везде. Максимальный безопасный размер пакета 508 байт.
eyeofhell
Может быть не везде, VPN и MPLS любят добавлять в пакеты свою техническую информацию. Да и поменять MTU на машине никто не мешает.
ice2heart
А на всех устройствах между?
eyeofhell
Тут в моих знаниях провал. Что будет, если где-то посередине маршрута VPN/MPLS/WTF, который хочет понизить MTU и начинает фрагментировать… А если пакеты с флагами don't fragment? Не знаю что будет. Возможно, кто-то из более опытных по инфраструктуре Хабравчан подскажет.
mayorovp
Дропы пакетов будут. Именно потому "приличные" протоколы включают способ автоматического определения MTU вдоль маршрута.