Комментарии 63
Линейкой по рукам таким разработчикам, и RFC 3261 пусть курят до просветления. Зачем тащить xml/json в SIP??? Что еще за дикие идеи?
На эту и подобные темы, не зря, Международным союзом электросвязи (ITU-T) для передачи мультимедиа-данных был рекомендован протокол H323. Народ выбрал то, что намного проще — SIP. Если вы будете раздувать SIP — Вас не очень поймут. На то он и призван быть простым, чтобы пакет мог легко выполнить 70 дефолтных переходов (Max-Forwards), в случае надобности.
По сему 3 варианта:
1)Фрагментировать самим.
2)Настраивать оборудование.
3)Последовать рекомендациям ITU-T.
path mtu discovery? Его сейчас реально ктото делает из популярных операционок? Винда там, андроид, вот эти все ребята? О_О
PMTU делают по моему все, одако проблем он не решает. Path MTU discovery работает (для TCP, don't fragment flag is set) следующим образом: пакет дропается а источнику отправляется соответствующий ICMP. Это imho крайне неудачный механизм, по сути negative ACK, старательно избегаемый в базовой версии TCP. На практике все сетевые устройства ограничивают генерацию ICMP и в ситуации подобной примеру (10000 клиентов одновременно посылают пакет > MTU) большинство из них впадет в экспоненциальный ретрансмит и зависнет навсегда.
Для достаточно умных промежуточных устройств есть еще альтернативный механизм с редактированием заголовка TCP...
Не слышал, а чем это поможет? Если пакет не пролазит в MTU следующего сегмента, его по любому придется либо сегментировать, либо дропнуть.
Пакет SYN, идущий без данных, в MTU пролезет всегда. А дальше — обе стороны уже будут знать PMTU и не будут посылать больших пакетов. Если, конечно, маршрут внезапно не сменится.
Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.
Так же, как маршрутизаторы узнают о необходимости фрагментировать пакет.
Не читайте эту статью — она вас плохому научит.
во время SIP сессии — различают две части.
Сигнальную и голосовую.
Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.
А вот голосовая идёт по RTP поверх UDP или TCP.
И здесь проблем с фрагментацией не наблюдается. Потому как проблема ровно обратная — overhead. Голосовые пакеты настолько маленькие, что overhead даже через UDP может достичать 100%. Т.е. длина заголовка UDP ~ равна полезной нагрузке. (у разных кодеков по разному)
Размер пакета у кодека G.729 — 20 байт. У G711 — 160 байт. Поэтому до фрагментации там как пешком до луны
Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.
Я просто скажу, что это не так. Ок? :)
Проблема SIP ( сигнализации ) и длины пакета в большинтстве своем не видна, так как в общем и целом пакеты с самом SIP не большие. Нет там такого огромного количества информации чтобы дойти до ограничений. Даже с описанием видео сессии. Много данных гоняется через websockets но там TCP, так что паника надумана как по мне.
Вы тогда у и пишите что, мол, при таких-то и таких-то случаях данная проблема возникает. А так под одну гребенку все. Зачем?
Напишу так.
При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)
Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.
А на стенде много чего можно накрутить.
В нормально настроенном оборудовании IMHO, нужно всего 3 кодека, какой либо HD, G.711 и сильно сжимающий (типа G.729). А при зональном делении и того меньше.
А пихать 15 кодеков, это как иметь 3 антивируса на компьютере.
Не-а. Может, это специфика клиентов моей прошлой работы, но такого было валом. Ну пусть не 15 кодеков, но по 10 пытались выставлять, и параметры вписывались чуть менее, чем все. Я мерял — INVITE толще граничных 1300 байт были регулярно.
> В нормально настроенном оборудовании IMHO, нужно всего 3 кодека
Судя по тому, что в типичной железяке, с которой мы работали, были G.711, G.723 в двух профилях, G.729 в двух профилях, GSM, Speex — с Вами мало кто согласен :) Обычно предпочитают выставить побольше, лишь бы связаться хоть как-то. Очень не любят ситуацию, когда звонок не устанавливается потому, что не нашли общего кодека.
А так как до сих пор есть два слабопересекающихся мира с проприетарными и со свободными кодеками, где на пересечении только G.711, который зарезан потому, что слишком большая полоса (а некоторые клиенты из крупных азиатских стран реализовывали свой менталитет зарезанием всего, что толще ~8Kbit/s) — то такое несогласование происходило постоянно. Если удавалось уговорить обе стороны в таком варианте на GSM — это уже была маленькая победа.
«Сутя по тысячам терминалам и сотням станций разных вендоров которыя я настраивал» таки у вас нетипичные клиенты.
Если кто-то пытается сделать бизнес и на бесплатных кодеках — это лишь его частные проблемы.
Вообще — есть два типа проблем:
Проблемы из-за преминяемых технологий.
Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.
Вот вытащил из архива совершенно типовой 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
Это уже 1105 байт. Пара хопов больше — ещё по ~90 байт на каждый — уже к границе 1300 подобрались вплотную.
И это, заметьте, без отдельных бесплатных кодеков — как раз на ITU.T наборе (G.711/723/726/729). С ними переход произошёл бы ещё быстрее.
Если Вы считаете, что такие клиенты нетипичны — скажите, какие, по-Вашему, типичны.
> Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.
Ну я тоже могу обвинить Cisco (в лице Linksys) в кривых руках, но меня вряд ли поймут ;)
Для чего все эти кодеки???
Зачем G.711Mu мы что в штатах?
Для чего вам 4 шт. G726 ?? Да при наличии G.729 и в локальное сети ???
Железку просто не настраивали.
Или настраивали по принципу — включаем всё, может заработает.
P.S. — настройки по умолчанию в сегменте SOHO в ~90% случаем кривые/неоптимальные.
G.711A
G.729A
, и как замена G.729 — один из вариантов G.726
Я читал — одна лицензия на G.729 на оба порта устройства, соответственно, не более одного разговора одновременно.
Остальное все верно.
Цитирую 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. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
Вы б таки ещё за роутинг аттачей спросили…
при первой возможности переключайте на TCP!
вы всерьёз призываете к нарушению RFC? UA должен использовать UDP и переключаться на TCP в случае проблем. M$ с их Lync (SfB) просто забили на стандарт (обычное дело, часть EEE).
в современных Астерисках есть PJSIP, с которым нет проблем совместимости
зато во все времена есть проблема со «специалистами», которые не понимают значения слова «стандарт», и здесь не важно, Астериск они настраивают или что-то другое
«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 байт противоречит стандарту.
Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.
> наконец-то стабилизировалась в виде HTTP/2
Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.
Я кстати даже забыл что SIP может по UDP идти :) в мобильных сетях почти все пакеты больше МТУ выходят из-за кучи хмл-мусора
с появлением коробочных решений вроде FreePBX большинство настроек, включая протокол будут стоять такие, какие указали по дефолту создатели дистрибутива, а большинство проблем, о которых вы писали будет решаться по советам установить VPN и забыть о проблеме «сетвевиков-специалистов» с форумов.
И даже если у вас есть огромное желание самостоятельно полностью разобраться в проблеме и устройстве работы телефонии, то вам придется столкнутся с ужасным зоопарком разных протоколов, стандартов и технологий, которые в совокупности называются SIP, и мало кто столкнувшись с плохим звуком осилит это все. Действительно проще поставить VPN. Пока в SIP будет беспорядок со стандартами — будут рождаться подобные проблемы, и эффективные решения проблем тоже будут вот такие вот дубовые и «в лоб».
Глупо спорить с тем, что реалии современного интернета и топология интранет сетей довольно сильно отличаются от тогдашних.
Поэтому вопрос, который пытается раскрыть автор, на самом деле лежит гораздо глубже, чем адаптация SIP для современных сетей костылями типа нового вида keep alive, разного вида STUN, прикручиванием UPnP NAT…
Как я понимаю этот процесс последние годы зашевелился (некоторые кодеки стали действительно работающими), а что касается самого SIP протокола — даже во многих реализациях клиентов и серверов наблюдаются несовсестимости вплоть до простейших функций типа трансфера вызова или голосовой почты.
Шел 2017 год. Где UDP фрагментация?