Возможности sip сервис провайдера в проблеме nat trave

  1. Написал:
    Июнь 21st, 2009 | 21:12

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

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

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

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

  2. Написал:
    Июнь 22nd, 2009 | 09:10

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

  3. Написал:
    Июнь 23rd, 2009 | 10:40

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

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

  4. Написал:
    Июнь 23rd, 2009 | 10:46

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

  5. Написал:
    Июнь 24th, 2009 | 00:01

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

  6. Написал:
    Январь 20th, 2010 | 13:57

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

  7. Написал:
    Февраль 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

  8. Написал:
    Февраль 27th, 2010 | 12:42

    День добрый.

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

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

  9. Написал:
    Февраль 27th, 2010 | 21:29

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

Оставить Ответ

Бесплатный хостинг uCoz