Шел 2017 год. Где UDP фрагментация?

    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

    А картинка для привлечения внимания — вот отсюда
    Voximplant 179,00
    Облачная телеком-платформа
    Поделиться публикацией
    Комментарии 63
    • +2
      Насколько я понимаю 1500 байт может быть не везде. Максимальный безопасный размер пакета 508 байт.
      • 0
        Может быть не везде, VPN и MPLS любят добавлять в пакеты свою техническую информацию. Да и поменять MTU на машине никто не мешает.
        • 0
          А на всех устройствах между?
          • 0
            Тут в моих знаниях провал. Что будет, если где-то посередине маршрута VPN/MPLS/WTF, который хочет понизить MTU и начинает фрагментировать… А если пакеты с флагами don't fragment? Не знаю что будет. Возможно, кто-то из более опытных по инфраструктуре Хабравчан подскажет.
            • +2

              Дропы пакетов будут. Именно потому "приличные" протоколы включают способ автоматического определения MTU вдоль маршрута.

      • +4
        А может не надо тащить в SIP привычные JSON и XML пайлоады? В аналог же не тащите…
        • +2
          Так привычки же. Я — не тащу. А вот более молодые разработчики… Ну вы понимаете :)
          • 0

            Линейкой по рукам таким разработчикам, и RFC 3261 пусть курят до просветления. Зачем тащить xml/json в SIP??? Что еще за дикие идеи?

            • 0
              Потому что они устроили митап в коворгинге на гироскутерах, попили смузи, покрутили спиннеры и вот пожалуйста.
            • +3
              В таком случае, советуйте молодым разработчикам фрагментировать данные перед отправкой. UDP для SIP абсолютно на всех устройствах выбран по-умолчанию. Своим юзерам говорить, что работает у нас SIP only TCP — непросто, проще даже настроенное оборудование поставлять.
              На эту и подобные темы, не зря, Международным союзом электросвязи (ITU-T) для передачи мультимедиа-данных был рекомендован протокол H323. Народ выбрал то, что намного проще — SIP. Если вы будете раздувать SIP — Вас не очень поймут. На то он и призван быть простым, чтобы пакет мог легко выполнить 70 дефолтных переходов (Max-Forwards), в случае надобности.
              По сему 3 варианта:
              1)Фрагментировать самим.
              2)Настраивать оборудование.
              3)Последовать рекомендациям ITU-T.
          • 0

            path mtu discovery? Его сейчас реально ктото делает из популярных операционок? Винда там, андроид, вот эти все ребята? О_О

            • 0

              PMTU делают по моему все, одако проблем он не решает. Path MTU discovery работает (для TCP, don't fragment flag is set) следующим образом: пакет дропается а источнику отправляется соответствующий ICMP. Это imho крайне неудачный механизм, по сути negative ACK, старательно избегаемый в базовой версии TCP. На практике все сетевые устройства ограничивают генерацию ICMP и в ситуации подобной примеру (10000 клиентов одновременно посылают пакет > MTU) большинство из них впадет в экспоненциальный ретрансмит и зависнет навсегда.

              • 0

                Для достаточно умных промежуточных устройств есть еще альтернативный механизм с редактированием заголовка TCP...

                • 0

                  Не слышал, а чем это поможет? Если пакет не пролазит в MTU следующего сегмента, его по любому придется либо сегментировать, либо дропнуть.

                  • 0

                    Пакет SYN, идущий без данных, в MTU пролезет всегда. А дальше — обе стороны уже будут знать PMTU и не будут посылать больших пакетов. Если, конечно, маршрут внезапно не сменится.

                    • 0

                      Вы хотите сказать что все промежуточные устройства редактируют TCP header обновляя поле MTU? Логично, однако это работает только для статических маршрутов с известными узлами. Более того, оконечные устройства все равно должны быть готовы обрабатывать фрагменты.

                  • 0
                    > с редактированием заголовка TCP.

                    Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.
                    • 0

                      Так же, как маршрутизаторы узнают о необходимости фрагментировать пакет.

                      • 0
                        Нет, так как раз не получится. Раутер послал свой needfrag и забыл. Он не будет ставить у себя память «вот для этих спецправило — ставить MSS». Такое спасение утопающих — только их дело, в лучшем случае, ближайшего своего шлюза.
                        • 0

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

                          • 0
                            Так таких «достаточно умных» днём с огнём не напасёшься.
              • +2
                SIP по TCP ничем не лучше чем SIP по UDP, хотя бы по тому, что стандартом де-факт является UDP-вариант, а TCP все поддерживают чтобы было, очень часто из-за этого проблем там еще больше по факту.
                • +1
                  Для передачи звука/видео и прочего, требующего реального времени, UDP больше подходит: ТСР сильно сужает полосу при возрастании потерь, так что на мобильном интернете плохо работает. ТСР будет слать уже неактуальные данные, пока не дошлёт. Но у ТСР несколько лучше дела обстоят с файрволами. UDP часто закрыт, особенно в корпоративных сетях. UDP-flood способен намертво повесить сервер из-за огромного количества прерываний, если трафик лить на открытый UDP-порт, даже объединение нескольких пакетов в одно прерывание не помогает.
                  • 0
                    DoS он везде одинаковый, что по TCP, что по UDP, большой разницы нет. Как будто TCP-flood нельзя организовать
                    • +2
                      по UDP можно трафик лить с одного хоста через подмену адреса отправителя и маршрутизаторы этот трафик не блокируют (на моей практике). SYN-flood с некорректным адресом отправителя неплохо режется
                • –2
                  На смартфонах SIP по UDP вдобавок намного быстрее пожирает батарейку.
                  • +3

                    А расскажите, почему? Чем tcp с пингами лучше?

                    • +1
                      Для TCP маршрутизаторы устанавливают больший таймаут записей NAT, чем для UDP (обычно 15 минут против 30 секунд), поэтому пинговать можно реже.
                  • –2
                    «Смешались в кучу кони люди»

                    Не читайте эту статью — она вас плохому научит.
                    во время SIP сессии — различают две части.

                    Сигнальную и голосовую.
                    Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.

                    А вот голосовая идёт по RTP поверх UDP или TCP.
                    И здесь проблем с фрагментацией не наблюдается. Потому как проблема ровно обратная — overhead. Голосовые пакеты настолько маленькие, что overhead даже через UDP может достичать 100%. Т.е. длина заголовка UDP ~ равна полезной нагрузке. (у разных кодеков по разному)

                    Размер пакета у кодека G.729 — 20 байт. У G711 — 160 байт. Поэтому до фрагментации там как пешком до луны

                    • +6
                      Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.


                      Я просто скажу, что это не так. Ок? :)
                      • –3

                        Проблема SIP ( сигнализации ) и длины пакета в большинтстве своем не видна, так как в общем и целом пакеты с самом SIP не большие. Нет там такого огромного количества информации чтобы дойти до ограничений. Даже с описанием видео сессии. Много данных гоняется через websockets но там TCP, так что паника надумана как по мне.

                        • 0
                          Тоже не вижу проблем, один раз за всю свою практику сталкивался с этим, когда размер INVITE`а переваливал 1500 и… не работало) Начинаешь смотреть, что не так и, внезапно, в этом INVITE`е в SDP перечислено 100500 ненужных кодеков и левых хидеров. Снимаем дамп и настраиваем правильно)
                          • –2
                            Так вот, за последние пару лет все поменялось. Особенно с видеоконференциями. Прогресс, вот это всё.
                            • +2
                              С видео конференциями — понятно, там банально информации больше гоняется, а то, о чем вы пишите, касается всего SIP. Из пушки по воробьям палите.
                              Вы тогда у и пишите что, мол, при таких-то и таких-то случаях данная проблема возникает. А так под одну гребенку все. Зачем?

                              • 0
                                Интересная и слабоосвещенная тема. Плюс английская статья про то же самое хорошо зашла, https://200ok.info/2017/03/31/sip-and-fragments/ — я же слежу за индустрией. Так что рассказать на Хабре, судя по просмотрам и плюсам, было здравой идеей. Ну а что тема спорная — в том и интерес.
                        • –3
                          Ну, хорошо.
                          Напишу так.

                          При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
                          Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
                          И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)
                          • +2
                            > При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.

                            Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.
                            • –2
                              Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?

                              А на стенде много чего можно накрутить.

                              В нормально настроенном оборудовании IMHO, нужно всего 3 кодека, какой либо HD, G.711 и сильно сжимающий (типа G.729). А при зональном делении и того меньше.

                              А пихать 15 кодеков, это как иметь 3 антивируса на компьютере.
                              • +1
                                > Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?

                                Не-а. Может, это специфика клиентов моей прошлой работы, но такого было валом. Ну пусть не 15 кодеков, но по 10 пытались выставлять, и параметры вписывались чуть менее, чем все. Я мерял — INVITE толще граничных 1300 байт были регулярно.

                                > В нормально настроенном оборудовании IMHO, нужно всего 3 кодека

                                Судя по тому, что в типичной железяке, с которой мы работали, были G.711, G.723 в двух профилях, G.729 в двух профилях, GSM, Speex — с Вами мало кто согласен :) Обычно предпочитают выставить побольше, лишь бы связаться хоть как-то. Очень не любят ситуацию, когда звонок не устанавливается потому, что не нашли общего кодека.
                                А так как до сих пор есть два слабопересекающихся мира с проприетарными и со свободными кодеками, где на пересечении только G.711, который зарезан потому, что слишком большая полоса (а некоторые клиенты из крупных азиатских стран реализовывали свой менталитет зарезанием всего, что толще ~8Kbit/s) — то такое несогласование происходило постоянно. Если удавалось уговорить обе стороны в таком варианте на GSM — это уже была маленькая победа.
                                • –1
                                  Отвечу в аналогичном стале
                                  «Сутя по тысячам терминалам и сотням станций разных вендоров которыя я настраивал» таки у вас нетипичные клиенты.

                                  Если кто-то пытается сделать бизнес и на бесплатных кодеках — это лишь его частные проблемы.

                                  Вообще — есть два типа проблем:

                                  Проблемы из-за преминяемых технологий.
                                  Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.

                                  • +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



                                    Это уже 1105 байт. Пара хопов больше — ещё по ~90 байт на каждый — уже к границе 1300 подобрались вплотную.

                                    И это, заметьте, без отдельных бесплатных кодеков — как раз на ITU.T наборе (G.711/723/726/729). С ними переход произошёл бы ещё быстрее.

                                    Если Вы считаете, что такие клиенты нетипичны — скажите, какие, по-Вашему, типичны.

                                    > Проблемы кривой настройки. Пихать десяток кодеков из соображений — «может что подойдёт», это лишь показатель кривизны рук.

                                    Ну я тоже могу обвинить Cisco (в лице Linksys) в кривых руках, но меня вряд ли поймут ;)
                                    • –1
                                      И?
                                      Для чего все эти кодеки???
                                      Зачем G.711Mu мы что в штатах?
                                      Для чего вам 4 шт. G726 ?? Да при наличии G.729 и в локальное сети ???

                                      Железку просто не настраивали.
                                      Или настраивали по принципу — включаем всё, может заработает.

                                      P.S. — настройки по умолчанию в сегменте SOHO в ~90% случаем кривые/неоптимальные.
                                      • 0
                                        Про G.726 я отвечу из своего опыта — ранние SPA-шки от Linksys, двухпортовые, не осиляли 2 одновременных разговора на G.729-м, по-видимому, из-за CPU. Выходом был как раз G.726.
                                        • –1
                                          Вот мы плавно и подошли к тому что( как я и писал ранее) достаточно 3 кодеков

                                          G.711A
                                          G.729A
                                          , и как замена G.729 — один из вариантов G.726

                                          • 0
                                            > не осиляли 2 одновременных разговора на G.729-м, по-видимому, из-за CPU

                                            Я читал — одна лицензия на G.729 на оба порта устройства, соответственно, не более одного разговора одновременно.
                                            • 0
                                              А, так вот в чем дело было. Понятно, спасибо :)
                          • +1
                            По умолчанию везде SIP использует UDP транспорт. TCP вы настраиваете сами.
                            Остальное все верно.
                            • 0
                              > По умолчанию везде 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. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
                          • +5

                            Вы б таки ещё за роутинг аттачей спросили…

                            • 0
                              Прошу прощения за оффтоп. Уважаемые камрады, не силен в протоколах IP-сигнализации. Есть сервер телефонии под Windows Server 2003, оператор Ростелеком говорит, цитирую: «Но от вас сигнализация идёт по UDP, а не TCP. Соответственно, нужно либо сигнализацию слать по TCP, либо keepalive включать под UDP. Временной интервал 15-30 секунд».Вот что то я и задумался как это реализовать в винде, с Linux было бы чуть проще.
                              • +2
                                Взять софт, который телефонию обеспечивает, и переключить SIP с UDP на TCP :) Все как в статье.
                                • 0
                                  Да все бы хорошо, софт называется infratel call center,4 версия. Документации никакой по софту нет, производитель софта открещивается от этой версии (закончилась поддержка). Два выхода: обновление на новую версию (платно и очень затратно), обращение в саппорт ничего не даст (саппорт платный тоже)
                                  • 0
                                    Беда-печалька. Если софт менять совсем не вариант, то надо ставить простенький proxy между ним и телеком оператором. И единственное, что будет делать прокси — это добавлять keep alive :) Довольно долго настраивать придется :(
                                    • +2
                                      Григорий скромно не предложил перейти на Voximplant :)
                                • +1
                                  при первой возможности переключайте на TCP!

                                  вы всерьёз призываете к нарушению RFC? UA должен использовать UDP и переключаться на TCP в случае проблем. M$ с их Lync (SfB) просто забили на стандарт (обычное дело, часть EEE).
                                  в современных Астерисках есть PJSIP, с которым нет проблем совместимости
                                  зато во все времена есть проблема со «специалистами», которые не понимают значения слова «стандарт», и здесь не важно, Астериск они настраивают или что-то другое
                                  • +2
                                    У MS вообще есть msSIP и msRTP, просто так, к слову :)
                                    • –1
                                      Я ссылку на англоязычную статью оставил, посмотрите — там много референсов. Вот это вам будет интересно: «The SIP standard, RFC 3261 mandates that TCP should be used to prevent fragmented SIP. „
                                      • 0
                                        извините, не интересно
                                        «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 байт противоречит стандарту.
                                    • 0
                                      > увидите SIP и UDP в одном месте — будьте осторожны

                                      Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.

                                      > наконец-то стабилизировалась в виде HTTP/2

                                      Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.
                                      • 0
                                        Я прям-таки вижу сцену: вечер, я в окружении наших сиповиков-телекомщиков пишу статью, Юра с Олегом и Ваней хором — «Да, да! Вот так! Вводи их в заблуждение! И про RTCP не забудь запутать!» :)
                                        • +1
                                          Статья про VoIP и фрагментацию UDP. UDP в воипе в основном для RTP, а сигнализация может идти по разному (SIP/TCP, H323 и тд). Так вот, проблема фрагментации только SIP'a что ли (1-3% UDP для ВоИП) или всего остального тоже?.. В SIPe нормально прописано что делать в случае больших пакетов, точно так же как и в DNS — в случае больших пакетов надо посылать по TCP.
                                          Я кстати даже забыл что SIP может по UDP идти :) в мобильных сетях почти все пакеты больше МТУ выходят из-за кучи хмл-мусора
                                      • 0
                                        По поводу «при первой возможности переключайте в TCP» не совсем согласен:

                                        с появлением коробочных решений вроде FreePBX большинство настроек, включая протокол будут стоять такие, какие указали по дефолту создатели дистрибутива, а большинство проблем, о которых вы писали будет решаться по советам установить VPN и забыть о проблеме «сетвевиков-специалистов» с форумов.
                                        И даже если у вас есть огромное желание самостоятельно полностью разобраться в проблеме и устройстве работы телефонии, то вам придется столкнутся с ужасным зоопарком разных протоколов, стандартов и технологий, которые в совокупности называются SIP, и мало кто столкнувшись с плохим звуком осилит это все. Действительно проще поставить VPN. Пока в SIP будет беспорядок со стандартами — будут рождаться подобные проблемы, и эффективные решения проблем тоже будут вот такие вот дубовые и «в лоб».
                                        • 0
                                          Добавлю, что многие базисные элементы спецификации SIP придуманы в лохматом (привет олдфагам) 90х годах и используются до сих пор (!!!!).
                                          Глупо спорить с тем, что реалии современного интернета и топология интранет сетей довольно сильно отличаются от тогдашних.
                                          Поэтому вопрос, который пытается раскрыть автор, на самом деле лежит гораздо глубже, чем адаптация SIP для современных сетей костылями типа нового вида keep alive, разного вида STUN, прикручиванием UPnP NAT…
                                          Как я понимаю этот процесс последние годы зашевелился (некоторые кодеки стали действительно работающими), а что касается самого SIP протокола — даже во многих реализациях клиентов и серверов наблюдаются несовсестимости вплоть до простейших функций типа трансфера вызова или голосовой почты.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое