Комментарии: Возможности SIP сервис провайдера в проблеме NAT traversal.

Автор: aoz

aoz — Sat, 27 Feb 2010 19:29:45 +0000

1. 72 циска ни в коем случае не есть SBC.
2. Как VOIP шлюз или H323 Gatekeper она использоваться может, но не более.
3. Я не рекомендую использовать вышеназванный функционал на 72xx цисках и с точки зрения бюджета и с точки зрения устойчивости голосового софта. Потом очень долго будете искать почему она в ребут уходит.

Автор: Иван

Иван — Sat, 27 Feb 2010 10:42:32 +0000

День добрый.

Насколько я смог понять из описания продуктов Cisco, в Cisco 7206vxr есть SBC? Как вы можете охарактеризовать использование данного продукта? Например, в случае Cisco 7206vxr для шлюза VoIP. То есть, клиенты за NAT (своим), а кошка как сервер VoIP у нас на площадке с раздачей реальных телефонных номеров клиентам, которые соединяются по IP.

К сожалению, я сейчас только погружаюсь в тему VoIP, поэтому некоторые вещи могу говорить неправильно.

Автор: Anthony

Anthony — Wed, 17 Feb 2010 17:20:19 +0000

Добрый день. Мы занимаемся поставками телекомм. оборудования операторам связи. Естественно, есть операторы, работающие по 1 варианту, имея при этом массу проблем с подключением VoIP-устройств за NATом. Есть так же операторы, подключающие SIP-устройства поверх VPN-соединения, например шлюз AudioCodes MP-20x поддерживает SIP внутри VPN-тоннеля (PPTP), качество не плохое даже используя wi-fi канал. Как Вы относитесь к данному типу включения? Еще вопрос: если есть клиент, который истинно желает работать по 2 варианту, но не в силу финансовых ограничений не может себе этого позволить, какой Open SBC посоветуете и сможете-ли вы оказывать услуги на коммурческой основе (удаленно по инету) по поддержке Open SBC?
Заранее благодарен, Шарапов Антон. +7 912 28 22210

Автор: alexzerg

alexzerg — Wed, 20 Jan 2010 11:57:12 +0000

aoz молодчик, очень наглядная схема. Про SBC я опять же с ним согласен, помимо кучи бабла есть еще дополнительно пару миносовок, около года общения с BroadSoft/Genband SBC (солярка с самописным кривоватым софтом и бета-тестирование на партнерах). Точно не вспомню детали, но при попытке скрестить японскую АТС и этот SBC через пару FXO (тестов ради) – в какой-то момент этот SBC тупо не мог форварднуть UAC-у АCK…Сейчас мы вообще используем NATPass-ы, вроде как полностью устраивают, правда предел нагрузки уже близок

Автор: aoz

aoz — Tue, 23 Jun 2009 22:01:57 +0000

По поводу PS. Статью почитайте, там это есть то что синеньким цветом нарисовано и написано
BTW, не после INVITE а всегда, иначе входящий звонок не пройдет.

Так вот? это не панацея. Панацея, на сегодня, насколько мне известно, нормально реализована только в последней VOIP карточке от Панасоника, где можно обрубить
все попытки обмануть NAT, но оставить keep-alive со стороны клиента,
в этом случае вероятность потери UDP пакета уже нулевая.

Автор: maxi_funy

maxi_funy — Tue, 23 Jun 2009 08:46:58 +0000

P.S. в догонку – правильный SBC, дабы не потерять сессию NAT, после INVITE должен посылать ре-регистрацию, в подтверждение начала сессии + есть такие пакетики типа keep alive, rstp подтверждающие, что абонент всё ещё есть, а не выключился.

Автор: maxi_funy

maxi_funy — Tue, 23 Jun 2009 08:40:38 +0000

ЭЭэээ… ну я как бы вроде и не пытался обсудить что лучше – коммерческий SBC или наколеночный т.к. в итоге почти все SBC (ну кроме мега крупных) это те же самые некоммерческие продукты чуть переделанные «своими» программерами
У нас «достучатся до разработчиков» занимает меньше суток, исправление – от одного дня до месяца, просто потому, что если вы покупаете «дорогой» SBC, то лучше взять сразу и тех.поддержку

А возвращаясь в тему поста – решений то в любом случае всего два

Автор: aoz

aoz — Mon, 22 Jun 2009 07:10:09 +0000

Пообщался месяц назад с инженерами одного огромного оператора установившего офигенно крутой SBC.
No thanks !!!. Я лучше буду крутить мозги и править баги живым и голодным разработчикам kamalio, чем буду платить big buxes зажравшимся менаджерам коммерческого SBC, за то, что те, будут с моей помощю пинать таких же зажравшихся программеров, чтобы те правили баги у себя в коммерческом продукте.
Из личного опыта достучатся до вменяемого программиста в open source проекте обычно занимает до нескольких дней. Truble fix на коммерческом продукте при проходе через все tier занимает от двух недель до полугода.

Автор: maxi_funy

maxi_funy — Sun, 21 Jun 2009 19:12:04 +0000

С точки зрения оператора, без подробностей ))

Операторское решение (на сегодня) имеет два варианта:
1) Так называемый STUN сервер. Это отдельно «висящий» сервер, обрабатывающий прохождение пакетов из-за NAT.

2) Правильный! У «правильного» оператора перед SIP PROXY есть замечательный SBC (сешн бордер контроллер) который принимает на себя всю сигнализацию (а иногда и RTP), залазит в пакет и достаёт всю необходимую информацию, а так же позволяет мониторить саму SIP сессию. Но! Стоит SBC довольно дорого и есть полноценный далеко не у всех

P.S. Во втором случае, вы как клиент вообще не заморачиваетесь по поводу NAT и иже с ним Просто скачиваете X-Lite ставите на комп и звоните