Возможности SIP сервис провайдера в проблеме NAT traversal.

Ниже показана схема осуществления p2p соединения двух клиентов находящихся за NAT через правильного SIP оператора. При работе по такой схеме от абонентов требуется, отключить какие либо настройки NAT traversal на своих клиентах. Все делается на операторской стороне. Схема работает даже через Symmetric NAT , поскольку всегда запрос от серверов провайдера будет идти на тот же хост:порт, откуда клиент уже посылал пакет. Мало того такая схема успешно справляется с многократным NAT, в отличие от алгоритмов NAT traversal на стороне клиента.

p2p соединение 2х клиентов за NAT, через провайдерский SIP Proxy

p2p соединение 2х клиентов за NAT, через провайдерский SIP Proxy

Как это работает. Цвета в тексте соответствуют цветам процедуры на рисунке.

  • Клиент А регистрируется на SIP proxy оператора. Оператор исходя из содержания пакета REGISTER определят находится ли клиент за NAT или нет. Если клиент за NAT в базу данных записывается, кроме обычной регистрационной записи пара IPадрес:порт откуда пришел пакет.
  • Через определенные промежутки времени SIP Proxy посылает либо sip пакеты, либо просто короткие UDP пакеты на IPадреc:порт клиента. Это необходимо для того, чтобы NAT на клиентской стороне удерживал в памяти транслящию адреса клиента. Это единственное тонкое место в схеме. С одной стороны слишком частые пакеты вызывают нагрузку на сеть. С другой стороны, при большом интервале между пакетами возможна ситуация когда NAT клиентского маршрутизатора забудет о трансляции. Скажем по умолчанию, время удержания UDP трансляции для IP Tables 30 секунд.
  • Затем, при установлении соединения, задача SIP Proxy поменить значения адресов:портов из SDP протокола на значения адресов:портов cвоего собственного RTP proxy.
  • После прихода RTP пакетов с обоих клиентов на RTP proxy делает просто переправлят пакеты между двумя клиентами за NAT.

Возможные проблемы при такой схеме.

  • Как говорилось выше, это интервал NAT ping меньше времени удержания UDP трансляции в NAT устройстве. Также достаточно частым является потеря NAT ping пакетов на перегруженных каналах. Естественно в этом случае входящий звонок становится невозможным до следующего цикла пеперегистрации.
  • Клиент хочет свершать только исходящие звонки и не регистрируется на SIP Proxy. Соответственно нет регистрации нет NAT ping. в этом случае возможенен неприход к клиенту SIP сообщения СONNECT или что хуже, некорректная отработка сообщений BYE или CANCEL, что вызовет проблемы с рассоедиеннием после звонка. И возможной некорректной тарификацией (подвисанием звонка).
  • Попытка, с некорректным использованием средств NAT Traversal на стороне клиента, пройти NAT. В этом случае, SIP Proxy не всегда сможет определить, что клиент находится за NAT и не предпринимает никаких действий.
  • Некорректное поведеие модулей sip conntrack в некоторых аппаратных маршрутизаторах. Перечислять список не буду из политкорректных соображений, хотя очень бы хотелось, поскольку это уже фатально.
Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

9 Комментариев

Типы Network Address Translation (NAT)

В свое время, когда я пытался понять как работают различные типы NAT маршрутизаторов. С одной стороны количество статей на эту тему оказалось крайне мало. С другой стороны, исходя из того что было, понять их было крайне сложно. Попробую написать понятное объяснение с максимумом картинок и минимумом определений. Перевод оригинальной английской терминологии на русский язык резанул по ушам, поэтому решил ее оставить как есть.

Cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Любой пакет с внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210

Full cone nat

Full cone nat

Address-Restricted cone NAT или Restricted cone NAT.

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Пакет с любого порта внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210 только в случае, если 192.168.0.2:2210 предварительно посылал пакет на этот внешний хост.

Address-Restricted cone NAT

Port-Restricted cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Внешний хост (1.1.1.30:1234) модет послать пакет на 192.168.0.2:2210 через 1.1.1.2:8801 только в случае если ранее 192.168.0.2:2210 слал пакет на 1.1.1.30:1234

Port-Restricted cone NAT

Symmetric NAT

Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт. Соответственно, пакет с одного и того-же внутреннего адреса:порта, но посланный на другой внешний хост или порт после трансляции будет иметь другой внешний адрес-порт. Внешние хосты могут послать обратный пакет только на те хосты:порты откуда они получили пакеты.

Symmetric NAT

Symmetric NAT

Еще одна, часто встречающаяся особенность NAT, так называемый port preservation, такой гибрид Port-Restricted и Symmetric NAT, будет рассмотрен в другой статье.

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

12 Комментариев

IP телефония и NAT traversal для чайников

Список наиболее часто задаваемых вопоросов службе поддержки VOIP провайдера:

  1. Меня не слышат.
  2. Я не слышу.
  3. Мне не приходит входящий звонок.

Все они являются, в 90 процентах случаев результатами одной проблемы.

В данной статье не будут рассматриваться варианты как с этим бороться. Дело в том, что по разному, поэтому планируется написать целый ряд статей где будут рассмотренны разные варианты решения проблем. Здесь рассмотрим только вопрос почему?

Все нижесказанное относится к 3 наиболее популярным протоколам: SIP, H323, MGCP. С точки зрения NAT traversal, то-есть прохождения маршрутизатора с NAT проблемы одни и те же, только порты разные.

Исходящий звонок через симметричный NAT

Исходящий звонок через симметричный NAT

Простейший случай. Абонент офисной сети с IP адресом 192.168.0.1 c программой IP телефона. Офисная сеть подключена к интернету через Линукс роутер c iptables в качестве NAT без sip_conntrack. Со стороны интернета адрес Linux роутера 66.230.160.14. Как происходит звонок. Во сигнальной сессии абонент А через порт 5060 посылает команду softswitch соединить его с абонентом B, и при этом сообщает, что будет слушать RTP поток (голос) на своем локальном адресе-порте 192.168.0.1:16384. Хотя с точки зрения абонента B, а также softsich-а, он будет слушать на интернет адресе 66.230.160.163:5060. Ни proxy ни ip телефон абонента B об этом понятия не имеют и соответственно голос от абонента B к абоненту А не пройдет.

Входящий звонок через симметричный NAT

Входящий звонок через симметричный NAT

В такой же схеме Абонент B зарегестрировался на SIP регистаре и ожидает входящего звонка от абонента А. Здесь возможны варианты.

  • Или регистар берет обратный IP адрес, не из заголовка пакета c сообщением Register а из тела регистрационного запроса. То есть не 66.230.160.14 а 192.168.0.1. Естественно запрос на соединение (сообщение INVITE), будет послано вместо реального IP 66.230.160.14 адреса, на несуществующий в интернете 192.168.0.1.
  • Более неприятная ситуация, это время жизни трансляции в NAT таблицах. Дело в том, что NAT роутер осуществляет трансляцию локального адреса-порта в глобальный и наоборот при приходе пакета. Затем, эта информация некоторое время хранится в таблице трансляциий (в пределах нескольких секунд). Стандартое время удержания информации о клиенте на SIP регистарах, H323 gatekeepers и других устройствах, от минуты и выше. Так вот, если входящий звонок прийдет в этот период времени, он дойдет до абонента B. В противном случае, NAT роутер просто проигнорирует его и звонок не дойдет.

В качестве заключения. Все описанные выше проблемы обычно решены, тем либо образом на VOIP серверах и клиентах. Как сделать, чтобы они работали првильно, будет рассказано в дальнейших публикациях.

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

2 Комментариев

Скриптик page rank

Надоело пользоваться пендосскими скриптами для PR и поднимать им рейтинг. Задача стояла, максимально удобно видеть PR от Google, ТИЦ от Yandex, , ну и Alexa рейтинг без подручных средств. Кроме всего прочего, в их скриптах отсутствует Яндекс как таковой. За вечерок сел и написал нечто на PHP, что меня вполне устраивало. Будет время, напишу на базе этого plugin для Wordpress и добавлю графики. Пока, как говорится, as is:

URL скрипта находится на:

http://aoz.com.ua/seo/pr.php

Рисует стандартный банер 88×31.

Параметры передаются через GET.
url - url главной страницы без http://. Обязательный параметр.
[color] 16-ричное значение цвета фона без # или H
[border] 16-ричное значение цвета фона без # или H

для сайта http://www.ipshka.com/ будет выглядить следующим образом:


А в реалии:

Page Rank

Хотите пользуйтесь. Единственная просьба, иметь уважение к автору. Не вырезайте ссылку на этот blog из кода банера.

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

Комментировать

Качество голоса при использовании VOIP через публичный интернет

Самая главная проблема IP телефонии, это потеря IP пакетов при передаче в сети. В данной публикации я хотел бы проанализировать наиболее часто встречающиеся случаи. Ниже приведена схема тракта передачи голоса в идеальных условиях.

VOIP тракт без потерь

VOIP тракт без потерь

По большому счету, задача оборудования на передающей стороне превратить аналоговый сигнал голоса, либо видео в пронумерованные кирпичики на рисунке, а в реалии это UDP пакеты с временными метками или так называемый RTP поток. Задача приемного тракта, собрать эти кирпичики в соответствии с временными метками и воссоздать с помощью Цифро-аналогового преобразователя (ЦАП) в копию сигнала передающей стороны.

VOIP тракт с потерей пакетов

VOIP тракт с потерей пакетов

В случае потери пакетов, теряется часть медийной информации, что вызывает разрывы голоса или характерные одноцветные квадратики на изображении, в случае передачи видео контента. Скорость доставки RTP пакетов в IP сетях постоянно меняется в зависимости от загрузки IP тракта. Это называется jitter. Для компенсации неравномерной скорости поступления пакетов на приемной стороне создают временное хранилище пакетов, или так называемый jitter buffer. Его задача, собрать поступающие пакеты в правильном порядке в соответствии с временными метками и выдать их кодеку с правильными интервалами и правильном порядке.

jitter

Работа jitter буфера

Размер буфера приемное VOIP устройство рассчитывает в процессе работы, либо принудительно задается в настройках. С одной стороны он не может быть слишком большой, чтобы не увеличивать транспортную задержку. С другой стороны, маленький размер буфера вызывает потери пакетов при изменениях времени задержки в IP сети. Отсюда и происходит одно из главных противоречий, между интернет провайдерами и пользователями IP телефонии. С точки зрения провайдера все пакеты доставлены абоненту, то есть, потерь нет. А с точки зрения VOIP устройства, разница во времени между приходом пакетов значительно превышает jitter буфер. Поэтому фактически потери есть. Из практики потеря более 1% вызывает определенные неприятные ощущения. Больше 2% разговор затруднен. При значениях больше 4% разговор уже практически невозможен.

Для того чтобы показать возможные причины потерь пакетов в реальной интернет сети, рассмотрим схему звонка с софтфона на стационарный телефон через VOIP оператора.

Схема звонка в IP телефонии

Схема звонка в IP телефонии

От абонента, до локального интернет провайдера

Наиболее частая причина это недостаточная емкость соединительной линии между провайдером и абонентом. Наличие параллельных загрузок файлов, даже на предельно маленькой скорости, могут вызвать очень серьезные проблемы, особенно при емкости абонентской линии меньше 700Kb/s. Дело в том, что размер стандартного пакета при закачке файла с http или ftp приблизительно равен 1500 байт. Для прохождения этого пакета через канал емкостью, скажем 128Kbit/s требуется приблизительно 95 mc. Здесь ситуацию можно сравнить со спортивной машиной, пытающейся обогнать грузовик на участке с движением в один ряд. То есть, даже при наличии приоритетных очередей для голоса на модемах либо маршрутизаторах с обеих сторон, возможен серьезный degrade качества.

Еще одна причина, неоднократно замеченная автором при внедрении разного рода call-manager-ов, центров обработки звонков, IP-АТС. Это Switch-и и маршрутизаторы типа «мыльница» или ethernet кабели непонятного качества. А также использование встроенных маршрутизаторов ATA шлюзов, для маршрутизации VOIP трафика других ATA шлюзов. Дело в том, что реальная производительность разного рода сетевых устройств измеряется не в мегабитах, килобитах, гигабитах в секунду, а в пакетах в секунду. По своей природе любой ip телефон генерирует количество пакетов, читай, создает нагрузку на сетевое оборудование, на порядок больше чем загрузка любимого сериала через bittorent. Соответственно, либо сетевое оборудование уже не в состояние исправлять ошибки, возникающие в некачественной СКС, либо свичи или маршрутизаторы просто не справляются с нагрузкой.

Последняя причина наиболее редкая сегодня, это недостаточная производительность процессора компьютера. Работа двух ACELP кодеков (прием-передача), загружала на 100% процессор Pentium 200Мгц. При сегодняшних машинах перегрузка процессора, разве что возможна на кодировании видео.

Проблемы в интернете

Их, как правило, две:

Первая, это жадность локальных провайдеров своевременно не увеличивающих емкость соединений с магистральными провайдерами. Мало того, у маленьких интернет провайдеров существует практика создания двух или более очередей трафика. В одну более приоритетную, как правило, попадают игры, web трафик и icmp пакеты. В менее приоритетную очередь попадают, как правило, voip, torent и все остальное. То есть с точки зрения неискушенного абонента вроде у них все хорошо, а на самом деле внешние каналы перегружены. Кстати, по той же причине утилиты ping и traceroute не является удачным средством для оценки качества голоса между серверами в интернете.

Вторая достаточно тривиальная причина это пиринговые войны. Это, как правило, разборки между серьезными магистральными операторами, обрывающие взаимный интерконнект, регулярно возникающие в связи с вопросом кто кому должен платить за трафик. Если кому интересно ищите Укртелеком vs UA-IX, Golden Telecom vs RTCom, Cogent vs Level 3. Такого рода проблемы, как правило, продолжаются от нескольких месяцев до многих лет и вызывают серьезные проблемы у VOIP клиентов.

Провайдер интернет телефонии.

В провайдерской практике существуют две схемы включения абонентов с полным проксированием и с сигнальным проксированием. В схеме с полным проксированием RTP поток идет через RTP прокси сервер провайдера, а там возможен тот же набор проблем, что и на стороне абонента. Как правило, это перегрузки на RTP прокси сервере и маршрутизаторах. Очень часто встречаются проблемы у маленьких интернет провайдеров, пытающихся начать IP телефонный бизнес. Они, как правило, связанны с отсутствием отдельных приоритетных очередей для голоса, либо их некорректной настройкой. В схеме с сигнальным проксированием, через сервера провайдера идет только сигнализация, что никоим образом не сказывается на качестве голоса, а RTP поток идет непосредственно от абонента к абоненту. Надо заметить, что в случае если один из абонентов находится за NAT, в этом случае схема сигнального проксирования перестает работать и в обязательном случае применяется полное проксирование.

IP шлюз у телефонного оператора.

Как правило, у лицензированных операторов запасы канальной емкости и запасы емкостей маршрутизаторов настолько велики, что перегрузки практически невозможны. Здесь возможны следующие проблемы. Во многих странах существуют достаточно серьезные коррупционно-бюрократические препоны против попадания VOIP трафика в телефонную сеть. Соответственно, согласно рыночным законам, цена на белый легальный трафик и трафик, генерируемый по черно-серым схемам значительно разнятся. Провайдер IP телефонии при выборе партнера, далеко не всегда имеет возможность или желание провести аудит качества и в большинстве случаев выбирает предложение с наименьшей ценой. Оператор, терминирующий трафик по черной схеме не заботится об установке качественного оборудования из-за риска конфискации и не имеет большого выбора интернет канала. Поскольку, как правило, время жизни такого оператора исчисляется днями, или в лучшем случае месяцами никто особенно не заботится о потерях пакетов, приоритетных очередях итд.

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

4 Комментариев