Страничка VOIP Инженера

В случае использования «Заводской версии» Fedora 8 в качестве nat роутера имеем следующую проблему. Звонки на абонентов за NAT через SIP Proxy совмещенный с RTP proxy происходят без проблем.
В случае звонков на абонентов находящихся в интернете, как показано на рисунке:

trouble with iptables conntrack_sip

получается односторонняя слышимость. Абонент находящийся в интернете не слышит абонента за NAT.
После исследования выяснилось, что модуль conntrack_sip подменяет в SDP записи пакета «OK» , приходящего после снятия трубки дальней стороной ip адрес RTP потока. Для случая на рисунке с 555.555.184.2 на 555.555.184.13. То есть фактически делает reinvite не сообщая об этом абоненту в интернете.

Вот dump соответствующих пакетов снятых на маршрутизаторе с FC8

U 2009/03/05 21:00:11.899191 555.555.184.13:5060 -> 192.168.2.24:5060
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 555.555.184.13:5060;branch=z9hG4bK878912355;rport=1025..From: «212ua1″ <sip
:[email protected]>;tag=66346232..To: <sip:[email protected]>;tag=as41f52f95..Call-ID: [email protected]
Seq: 31 INVITE..User-Agent: XXXX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Suppor
ted: replaces..Contact: <sip:[email protected]>..Content-Type: application/sdp..Content-Length: 263….v=0..o=root 277
97 27797 IN IP4 555.555.184.2..s=session..c=IN IP4 555.555.184.2..t=0 0..m=audio 29444 RTP/AVP 18 101..a=rtpmap:18 G729/800
0..a=fmtp:18 annexb=no..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off — - — -..a=ptime:20..a=send
recv..
#

U 2009/03/05 21:00:18.573018 555.555.184.13:5060 -> 192.168.2.24:5060
SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 555.555.184.13:5060;branch=z9hG4bK878912355;rport=1025..From: «212ua1″ <sip:[email protected]>;tag=66346232..To: <sip:[email protected]>;tag=as41f52f95..Call-ID: [email protected]: 31 I
NVITE..User-Agent: xxx..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Supported: repl
aces..Contact: <sip:[email protected]>..Content-Length: 0….
#

U 2009/03/05 21:00:20.753646 555.555.184.13:5060 -> 192.168.2.24:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP 555.555.184.13:5060;branch=z9hG4bK878912355;rport=1025..Record-Route: <sip:555.555.184.13;
lr=on;ftag=66346232>..From: «212ua1″ <sip:[email protected]>;tag=66346232..To: <sip:[email protected]>;tag=as41f52f95..C
all-ID: [email protected]: 31 INVITE..User-Agent: XXXXX..Allow: INVITE, ACK, CANCEL, OPTIO
NS, BYE, REFER, SUBSCRIBE, NOTIFY..Supported: replaces..Contact: <sip:[email protected]>..Content-Type: application/sd
p..Content-Length: 265….v=0..o=root 27797 27798 IN IP4 555.555.184.13..s=session..c=IN IP4 555.555.184.13..t=0 0..m=audio
29444 RTP/AVP 18 101..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=
silenceSupp:off — - — -..a=ptime:20..a=sendrecv..
#

Пока жду реакции от developer-ов модуля conntract_sip. Но судя по всему, что удалось найти в интернете, никто особенно данной проблемой не занимается. Самое худшее то, что модуль conntract_sip для данного Liux дистрибутива вкомпилен в ядро и просто так отключить его, без пересборки ядра возможности нет.

Решение проблемы опубликовано здесь

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

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 в некоторых аппаратных маршрутизаторах. Перечислять список не буду из политкорректных соображений, хотя очень бы хотелось, поскольку это уже фатально.
  

В свое время, когда я пытался понять как работают различные типы 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

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 предварительно посылал пакет на этот внешний хост.

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

Symmetric NAT

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

Symmetric NAT

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

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

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

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

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

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

В такой же схеме Абонент 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 серверах и клиентах. Как сделать, чтобы они работали првильно, будет рассказано в дальнейших публикациях.

Надоело пользоваться пендосскими скриптами для 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/ будет выглядить следующим образом:

<a href="http://aoz.com.ua" target="_blank" title="Страничка VOIP инженера"><img src="http://aoz.com.ua/seo/pr.php?url=www.ipshka.com&color=DFDFDF&border=A8A8A8" alt="Page Rank"></a>


А в реалии:




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