Возможности SIP сервис провайдера в проблеме NAT traversal.
Ниже показана схема осуществления p2p соединения двух клиентов находящихся за NAT через правильного SIP оператора. При работе по такой схеме от абонентов требуется, отключить какие либо настройки NAT traversal на своих клиентах. Все делается на операторской стороне. Схема работает даже через Symmetric NAT , поскольку всегда запрос от серверов провайдера будет идти на тот же хост:порт, откуда клиент уже посылал пакет. Мало того такая схема успешно справляется с многократным NAT, в отличие от алгоритмов NAT traversal на стороне клиента.
Как это работает. Цвета в тексте соответствуют цветам процедуры на рисунке.
- Клиент А регистрируется на 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 в некоторых аппаратных маршрутизаторах. Перечислять список не буду из политкорректных соображений, хотя очень бы хотелось, поскольку это уже фатально.
Июнь 21st, 2009 | 21:12
С точки зрения оператора, без подробностей :-)))
Операторское решение (на сегодня) имеет два варианта:
1) Так называемый STUN сервер. Это отдельно «висящий» сервер, обрабатывающий прохождение пакетов из-за NAT.
2) Правильный! У «правильного» оператора перед SIP PROXY есть замечательный SBC (сешн бордер контроллер) который принимает на себя всю сигнализацию (а иногда и RTP), залазит в пакет и достаёт всю необходимую информацию, а так же позволяет мониторить саму SIP сессию. Но! Стоит SBC довольно дорого и есть полноценный далеко не у всех
P.S. Во втором случае, вы как клиент вообще не заморачиваетесь по поводу NAT и иже с ним Просто скачиваете X-Lite ставите на комп и звоните
Июнь 22nd, 2009 | 09:10
Пообщался месяц назад с инженерами одного огромного оператора установившего офигенно крутой SBC.
No thanks !!!. Я лучше буду крутить мозги и править баги живым и голодным разработчикам kamalio, чем буду платить big buxes зажравшимся менаджерам коммерческого SBC, за то, что те, будут с моей помощю пинать таких же зажравшихся программеров, чтобы те правили баги у себя в коммерческом продукте.
Из личного опыта достучатся до вменяемого программиста в open source проекте обычно занимает до нескольких дней. Truble fix на коммерческом продукте при проходе через все tier занимает от двух недель до полугода.
Июнь 23rd, 2009 | 10:40
ЭЭэээ… ну я как бы вроде и не пытался обсудить что лучше — коммерческий SBC или наколеночный т.к. в итоге почти все SBC (ну кроме мега крупных) это те же самые некоммерческие продукты чуть переделанные «своими» программерами
У нас «достучатся до разработчиков» занимает меньше суток, исправление — от одного дня до месяца, просто потому, что если вы покупаете «дорогой» SBC, то лучше взять сразу и тех.поддержку
А возвращаясь в тему поста — решений то в любом случае всего два
Июнь 23rd, 2009 | 10:46
P.S. в догонку — правильный SBC, дабы не потерять сессию NAT, после INVITE должен посылать ре-регистрацию, в подтверждение начала сессии + есть такие пакетики типа keep alive, rstp подтверждающие, что абонент всё ещё есть, а не выключился.
Июнь 24th, 2009 | 00:01
По поводу PS. Статью почитайте, там это есть то что синеньким цветом нарисовано и написано
BTW, не после INVITE а всегда, иначе входящий звонок не пройдет.
Так вот? это не панацея. Панацея, на сегодня, насколько мне известно, нормально реализована только в последней VOIP карточке от Панасоника, где можно обрубить
все попытки обмануть NAT, но оставить keep-alive со стороны клиента,
в этом случае вероятность потери UDP пакета уже нулевая.
Январь 20th, 2010 | 13:57
aoz молодчик, очень наглядная схема. Про SBC я опять же с ним согласен, помимо кучи бабла есть еще дополнительно пару миносовок, около года общения с BroadSoft/Genband SBC (солярка с самописным кривоватым софтом и бета-тестирование на партнерах). Точно не вспомню детали, но при попытке скрестить японскую АТС и этот SBC через пару FXO (тестов ради) — в какой-то момент этот SBC тупо не мог форварднуть UAC-у АCK…Сейчас мы вообще используем NATPass-ы, вроде как полностью устраивают, правда предел нагрузки уже близок
Февраль 17th, 2010 | 19:20
Добрый день. Мы занимаемся поставками телекомм. оборудования операторам связи. Естественно, есть операторы, работающие по 1 варианту, имея при этом массу проблем с подключением VoIP-устройств за NATом. Есть так же операторы, подключающие SIP-устройства поверх VPN-соединения, например шлюз AudioCodes MP-20x поддерживает SIP внутри VPN-тоннеля (PPTP), качество не плохое даже используя wi-fi канал. Как Вы относитесь к данному типу включения? Еще вопрос: если есть клиент, который истинно желает работать по 2 варианту, но не в силу финансовых ограничений не может себе этого позволить, какой Open SBC посоветуете и сможете-ли вы оказывать услуги на коммурческой основе (удаленно по инету) по поддержке Open SBC?
Заранее благодарен, Шарапов Антон. +7 912 28 22210
Февраль 27th, 2010 | 12:42
День добрый.
Насколько я смог понять из описания продуктов Cisco, в Cisco 7206vxr есть SBC? Как вы можете охарактеризовать использование данного продукта? Например, в случае Cisco 7206vxr для шлюза VoIP. То есть, клиенты за NAT (своим), а кошка как сервер VoIP у нас на площадке с раздачей реальных телефонных номеров клиентам, которые соединяются по IP.
К сожалению, я сейчас только погружаюсь в тему VoIP, поэтому некоторые вещи могу говорить неправильно.
Февраль 27th, 2010 | 21:29
1. 72 циска ни в коем случае не есть SBC.
2. Как VOIP шлюз или H323 Gatekeper она использоваться может, но не более.
3. Я не рекомендую использовать вышеназванный функционал на 72xx цисках и с точки зрения бюджета и с точки зрения устойчивости голосового софта. Потом очень долго будете искать почему она в ребут уходит.
Январь 11th, 2014 | 11:25
Добрый день!
В вашем примере (синим цветом), недостаточно, чтобы keep-alive посылала клиентская сторона, чтобы не заставлять сервер заниматься удержанием правил трансляции NAT?