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

Особенность работы Сisco IOS при звонке из телефонной сети в SIP сеть.

При данной схеме Cisco использует для передачи и приема разные UDP порты. Так называемая ассиметричная сигнализация. Пакеты отправляются обычно с очень высокого порта, а слушает на стандартном 5060 или том, что указан в параметре sip-server.

U 2009/07/31 15:01:21.567483 192.168.1.21:51883 -> 192.168.1.13:5060
INVITE sip:0000100@192.168.1.13:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.1.21:5060..

Причем каждый следующий пакет начинает следующую Seqence и посылается с другого порта

U 2009/07/31 15:01:21.653034 192.168.1.21:51416 -> 192.168.1.13:5060
PRACK sip:192.168.1.13:5060;lr=on;ftag=137D6378-B73 SIP/2.0..Via: SIP/2.0/UDP 192.168.1.21:5060

Интелектуальные SIP proxy (SER, Openser, Kamalio) сравнивают реальный порт передачи и значение порта в верхнем Via. На основании этого они принимают решение находится ли данный SIP клиент за NAT. И в дальнейшем посылают ответные SIP пакеты не на порт из верхнего VIA либо из поля Contact, а на порт откуда пришел последний пакет. А свою очередь Cisco закрывает порт передачи по только ей известному алгоритму. Отсюда огромное количество trouble в интернете по потере BYE пакета из SIP сети в сторону PSTN шлюза на Сisco.

Рекомендации по клонам SER, осторожно использовать 16 параметр в функции nat_uac_test, означающий принятие решения о нахождении UAC за NAT

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