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

При распозновании сигнала факса AS53XX пытается сделать reinvite.
причем шлет INVITE с uri sip:@xxx.xxx.xxx.xxx где xxx.xxx.xxx.xxx ip адрес openser.
Соответственно, такой вызов попадает в ветку loose route и требует специальной обработки. Мало того, Cisco IOS не обрабатывает запрос на Digest Authorisation. В процессе моего «гугления» найдено несколько десятков topic-ов по этой теме и как правило, задающий вопрос просто не мог докопаться до источника проблемы с reinvite.
А как результат получал не очень корректный ответ.

Мое решение не очень элегантное но надежное:
В процессе обработки loose route выставить флаг на соответствующий src_ip (циски или другого t38 шлюза )и по этому флагу обходить авторизацию.
Буду признателен, за более красивое решение, в случае 100% использования digest authorisation.

Поскольку часовое «гугление» красивого варианта не дало, привожу свое решение, с очень сильно подкорректированными скриптами найденными где-то на буржуйских сайтах. У меня хостинг стоит на Ubuntu. Для других реализаций Linux, возможно придется корректировать каталоги доступа к bind.

Идея в следующем: На машине с Plesk панелью находится скрипт,
который генерирует include файл с описанием secondary зон для secondary DNS. Скрипт привязывается к событиям Domain created и Domain deleted в Event manager панели администратора Plesk.
Этот скрипт помещает include файл в один из защищенных каталогов, какого либо из сайтов на хостинге.

На машине с secondary DNS в cron.hourly помещается второй скрипт.
Он через wget подружает файл с хостинга, сравнивает с уже существующим и в случае различий подменяет локальный файл на загруженный. После чего делает rndc reload.
Оказалось просто и надежно до безобразия.

Скрипты здесь:
gen-secondaries.sh
xfer-config.sh

В случае использования «Заводской версии» 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
:101563@xxx.com>;tag=66346232..To: <sip:2292694@xxx.com>;tag=as41f52f95..Call-ID: 1295544592-5060-4@192.168.2.24..C
Seq: 31 INVITE..User-Agent: XXXX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Suppor
ted: replaces..Contact: <sip:2292694@555.555.184.2>..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:101563@XXX.com>;tag=66346232..To: <sip:2292694@XXX.com>;tag=as41f52f95..Call-ID: 1295544592-5060-4@192.168.2.24..CSeq: 31 I
NVITE..User-Agent: xxx..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Supported: repl
aces..Contact: <sip:2292694@555.555.184.2>..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:101563@XXX.com>;tag=66346232..To: <sip:2292694@XXX.com>;tag=as41f52f95..C
all-ID: 1295544592-5060-4@192.168.2.24..CSeq: 31 INVITE..User-Agent: XXXXX..Allow: INVITE, ACK, CANCEL, OPTIO
NS, BYE, REFER, SUBSCRIBE, NOTIFY..Supported: replaces..Contact: <sip:2292694@555.555.184.2>..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, будет рассмотрен в другой статье.