Ниже показана схема осуществления 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