Comments 63
Насколько я понимаю 1500 байт может быть не везде. Максимальный безопасный размер пакета 508 байт.
Может быть не везде, VPN и MPLS любят добавлять в пакеты свою техническую информацию. Да и поменять MTU на машине никто не мешает.
А может не надо тащить в SIP привычные JSON и XML пайлоады? В аналог же не тащите…
Так привычки же. Я — не тащу. А вот более молодые разработчики… Ну вы понимаете :)
Линейкой по рукам таким разработчикам, и RFC 3261 пусть курят до просветления. Зачем тащить xml/json в SIP??? Что еще за дикие идеи?
В таком случае, советуйте молодым разработчикам фрагментировать данные перед отправкой. UDP для SIP абсолютно на всех устройствах выбран по-умолчанию. Своим юзерам говорить, что работает у нас SIP only TCP — непросто, проще даже настроенное оборудование поставлять.
На эту и подобные темы, не зря, Международным союзом электросвязи (ITU-T) для передачи мультимедиа-данных был рекомендован протокол H323. Народ выбрал то, что намного проще — SIP. Если вы будете раздувать SIP — Вас не очень поймут. На то он и призван быть простым, чтобы пакет мог легко выполнить 70 дефолтных переходов (Max-Forwards), в случае надобности.
По сему 3 варианта:
1)Фрагментировать самим.
2)Настраивать оборудование.
3)Последовать рекомендациям ITU-T.
На эту и подобные темы, не зря, Международным союзом электросвязи (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 следующего сегмента, его по любому придется либо сегментировать, либо дропнуть.
> с редактированием заголовка TCP.
Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.
Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.
Так же, как маршрутизаторы узнают о необходимости фрагментировать пакет.
SIP по TCP ничем не лучше чем SIP по UDP, хотя бы по тому, что стандартом де-факт является UDP-вариант, а TCP все поддерживают чтобы было, очень часто из-за этого проблем там еще больше по факту.
Для передачи звука/видео и прочего, требующего реального времени, UDP больше подходит: ТСР сильно сужает полосу при возрастании потерь, так что на мобильном интернете плохо работает. ТСР будет слать уже неактуальные данные, пока не дошлёт. Но у ТСР несколько лучше дела обстоят с файрволами. UDP часто закрыт, особенно в корпоративных сетях. UDP-flood способен намертво повесить сервер из-за огромного количества прерываний, если трафик лить на открытый UDP-порт, даже объединение нескольких пакетов в одно прерывание не помогает.
На смартфонах SIP по UDP вдобавок намного быстрее пожирает батарейку.
«Смешались в кучу кони люди»
Не читайте эту статью — она вас плохому научит.
во время SIP сессии — различают две части.
Сигнальную и голосовую.
Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.
А вот голосовая идёт по RTP поверх UDP или TCP.
И здесь проблем с фрагментацией не наблюдается. Потому как проблема ровно обратная — overhead. Голосовые пакеты настолько маленькие, что overhead даже через UDP может достичать 100%. Т.е. длина заголовка UDP ~ равна полезной нагрузке. (у разных кодеков по разному)
Размер пакета у кодека G.729 — 20 байт. У G711 — 160 байт. Поэтому до фрагментации там как пешком до луны
Не читайте эту статью — она вас плохому научит.
во время 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, так что паника надумана как по мне.
Тоже не вижу проблем, один раз за всю свою практику сталкивался с этим, когда размер INVITE`а переваливал 1500 и… не работало) Начинаешь смотреть, что не так и, внезапно, в этом INVITE`е в SDP перечислено 100500 ненужных кодеков и левых хидеров. Снимаем дамп и настраиваем правильно)
Так вот, за последние пару лет все поменялось. Особенно с видеоконференциями. Прогресс, вот это всё.
Ну, хорошо.
Напишу так.
При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)
Напишу так.
При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)
> При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.
Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.
Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?
А на стенде много чего можно накрутить.
В нормально настроенном оборудовании IMHO, нужно всего 3 кодека, какой либо HD, G.711 и сильно сжимающий (типа G.729). А при зональном делении и того меньше.
А пихать 15 кодеков, это как иметь 3 антивируса на компьютере.
А на стенде много чего можно накрутить.
В нормально настроенном оборудовании 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 — это уже была маленькая победа.
Не-а. Может, это специфика клиентов моей прошлой работы, но такого было валом. Ну пусть не 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 сохранён.
Это уже 1105 байт. Пара хопов больше — ещё по ~90 байт на каждый — уже к границе 1300 подобрались вплотную.
И это, заметьте, без отдельных бесплатных кодеков — как раз на ITU.T наборе (G.711/723/726/729). С ними переход произошёл бы ещё быстрее.
Если Вы считаете, что такие клиенты нетипичны — скажите, какие, по-Вашему, типичны.
> Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.
Ну я тоже могу обвинить Cisco (в лице Linksys) в кривых руках, но меня вряд ли поймут ;)
Вот вытащил из архива совершенно типовой 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.711Mu мы что в штатах?
Для чего вам 4 шт. G726 ?? Да при наличии G.729 и в локальное сети ???
Железку просто не настраивали.
Или настраивали по принципу — включаем всё, может заработает.
P.S. — настройки по умолчанию в сегменте SOHO в ~90% случаем кривые/неоптимальные.
Про G.726 я отвечу из своего опыта — ранние SPA-шки от Linksys, двухпортовые, не осиляли 2 одновременных разговора на G.729-м, по-видимому, из-за CPU. Выходом был как раз G.726.
Вот мы плавно и подошли к тому что( как я и писал ранее) достаточно 3 кодеков
G.711A
G.729A
, и как замена G.729 — один из вариантов G.726
G.711A
G.729A
, и как замена G.729 — один из вариантов G.726
> не осиляли 2 одновременных разговора на G.729-м, по-видимому, из-за CPU
Я читал — одна лицензия на G.729 на оба порта устройства, соответственно, не более одного разговора одновременно.
Я читал — одна лицензия на G.729 на оба порта устройства, соответственно, не более одного разговора одновременно.
По умолчанию везде SIP использует UDP транспорт. TCP вы настраиваете сами.
Остальное все верно.
Остальное все верно.
> По умолчанию везде 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. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
Цитирую 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. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
Вы б таки ещё за роутинг аттачей спросили…
Прошу прощения за оффтоп. Уважаемые камрады, не силен в протоколах IP-сигнализации. Есть сервер телефонии под Windows Server 2003, оператор Ростелеком говорит, цитирую: «Но от вас сигнализация идёт по UDP, а не TCP. Соответственно, нужно либо сигнализацию слать по TCP, либо keepalive включать под UDP. Временной интервал 15-30 секунд».Вот что то я и задумался как это реализовать в винде, с Linux было бы чуть проще.
Взять софт, который телефонию обеспечивает, и переключить SIP с UDP на TCP :) Все как в статье.
при первой возможности переключайте на TCP!
вы всерьёз призываете к нарушению RFC? UA должен использовать UDP и переключаться на TCP в случае проблем. M$ с их Lync (SfB) просто забили на стандарт (обычное дело, часть EEE).
в современных Астерисках есть PJSIP, с которым нет проблем совместимости
зато во все времена есть проблема со «специалистами», которые не понимают значения слова «стандарт», и здесь не важно, Астериск они настраивают или что-то другое
У MS вообще есть msSIP и msRTP, просто так, к слову :)
Я ссылку на англоязычную статью оставил, посмотрите — там много референсов. Вот это вам будет интересно: «The SIP standard, RFC 3261 mandates that TCP should be used to prevent fragmented SIP. „
извините, не интересно
будет ли происходить фрагментация в 100% случаев? — нет
чем руководствоваться чтобы понять, будет ли происходить фрагментация?
частью 18.1.1 документа:
перевод части абзаца выше:
вместе с тем часть 19.1.2 документа однозначно нам сообщает:
перевод предложения выше:
Таким образом в общем случае использование TCP для запросов меньше 1300 байт противоречит стандарту.
«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 байт противоречит стандарту.
> увидите SIP и UDP в одном месте — будьте осторожны
Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.
> наконец-то стабилизировалась в виде HTTP/2
Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.
Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.
> наконец-то стабилизировалась в виде HTTP/2
Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.
Я прям-таки вижу сцену: вечер, я в окружении наших сиповиков-телекомщиков пишу статью, Юра с Олегом и Ваней хором — «Да, да! Вот так! Вводи их в заблуждение! И про RTCP не забудь запутать!» :)
Статья про VoIP и фрагментацию UDP. UDP в воипе в основном для RTP, а сигнализация может идти по разному (SIP/TCP, H323 и тд). Так вот, проблема фрагментации только SIP'a что ли (1-3% UDP для ВоИП) или всего остального тоже?.. В SIPe нормально прописано что делать в случае больших пакетов, точно так же как и в DNS — в случае больших пакетов надо посылать по TCP.
Я кстати даже забыл что SIP может по UDP идти :) в мобильных сетях почти все пакеты больше МТУ выходят из-за кучи хмл-мусора
Я кстати даже забыл что SIP может по UDP идти :) в мобильных сетях почти все пакеты больше МТУ выходят из-за кучи хмл-мусора
По поводу «при первой возможности переключайте в TCP» не совсем согласен:
с появлением коробочных решений вроде FreePBX большинство настроек, включая протокол будут стоять такие, какие указали по дефолту создатели дистрибутива, а большинство проблем, о которых вы писали будет решаться по советам установить VPN и забыть о проблеме «сетвевиков-специалистов» с форумов.
И даже если у вас есть огромное желание самостоятельно полностью разобраться в проблеме и устройстве работы телефонии, то вам придется столкнутся с ужасным зоопарком разных протоколов, стандартов и технологий, которые в совокупности называются SIP, и мало кто столкнувшись с плохим звуком осилит это все. Действительно проще поставить VPN. Пока в SIP будет беспорядок со стандартами — будут рождаться подобные проблемы, и эффективные решения проблем тоже будут вот такие вот дубовые и «в лоб».
с появлением коробочных решений вроде FreePBX большинство настроек, включая протокол будут стоять такие, какие указали по дефолту создатели дистрибутива, а большинство проблем, о которых вы писали будет решаться по советам установить VPN и забыть о проблеме «сетвевиков-специалистов» с форумов.
И даже если у вас есть огромное желание самостоятельно полностью разобраться в проблеме и устройстве работы телефонии, то вам придется столкнутся с ужасным зоопарком разных протоколов, стандартов и технологий, которые в совокупности называются SIP, и мало кто столкнувшись с плохим звуком осилит это все. Действительно проще поставить VPN. Пока в SIP будет беспорядок со стандартами — будут рождаться подобные проблемы, и эффективные решения проблем тоже будут вот такие вот дубовые и «в лоб».
Добавлю, что многие базисные элементы спецификации SIP придуманы в лохматом (привет олдфагам) 90х годах и используются до сих пор (!!!!).
Глупо спорить с тем, что реалии современного интернета и топология интранет сетей довольно сильно отличаются от тогдашних.
Поэтому вопрос, который пытается раскрыть автор, на самом деле лежит гораздо глубже, чем адаптация SIP для современных сетей костылями типа нового вида keep alive, разного вида STUN, прикручиванием UPnP NAT…
Как я понимаю этот процесс последние годы зашевелился (некоторые кодеки стали действительно работающими), а что касается самого SIP протокола — даже во многих реализациях клиентов и серверов наблюдаются несовсестимости вплоть до простейших функций типа трансфера вызова или голосовой почты.
Глупо спорить с тем, что реалии современного интернета и топология интранет сетей довольно сильно отличаются от тогдашних.
Поэтому вопрос, который пытается раскрыть автор, на самом деле лежит гораздо глубже, чем адаптация SIP для современных сетей костылями типа нового вида keep alive, разного вида STUN, прикручиванием UPnP NAT…
Как я понимаю этот процесс последние годы зашевелился (некоторые кодеки стали действительно работающими), а что касается самого SIP протокола — даже во многих реализациях клиентов и серверов наблюдаются несовсестимости вплоть до простейших функций типа трансфера вызова или голосовой почты.
Sign up to leave a comment.
Шел 2017 год. Где UDP фрагментация?