[AEro]

Задача:

Есть одна LAN1, в ней живет softswitch, внутренние VoIP клиенты, которые могут как говорить между собой, так и звонить и получать входящие звонки с ТФОП через имеющийся в softswitch сигнальный и медиа gateway. Из Public Inet, естественно ничего недоступно и не видно. В этой LAN уже все настроено, отлажено и работает как часы. Желательно вообще не вмешиваться и ничего не менять, не настраивать на стороне LAN1.

Есть еще одна "дружественная" LAN2, но она пока полностью независима и никак не связана с LAN1.

Цель - дать возможность SIP-клиентам из LAN2 подключаться к softswitch и получить полный функционал, что и внутренние SIP-клиентам из LAN1. При этом никакое иное взаимодействие между LAN1 и LAN2 не нужно и нежелательно.

Теоретически, существует возможность найти физическую точку соприкосновения LAN1 и LAN2.

Вопрос - что нужно поставить на стыке между LAN1 и LAN2, чтобы проходил SIP-сигналинг и медиа-трафик в обе стороны но больше ничего лишнего не ходило?

Как будут регистриться SIP-клиенты из LAN2? Какой адрес источника им прописывать?

• Локальный LAN2
• через STUN получить адрес:порт с точки зрения LAN1
• неважно какой - бридж на стыке сам подправит SIP-header
• неважно какой - softswitch сам подправит SIP-header

Как обеспечить возможность приема входящих вызовов на SIP-клиентах из LAN2?

Что будет если один SIP-клиент из LAN2 будет звонить другому SIP-клиенту из LAN2? Пойдет ли медиа трафик напрямую или через бридж? Если softswitch имеет свой медиа-прокси, то понятно, что все всегда через него идет...

Надо ли учитывать, что SIP-клиентов в LAN2 теоретически может быть очень много - например, 100 тысяч. Понятно, что одновременно они разговаривать вряд-ли будут, но как обрабатывать пиковые ситауции?

 

Может вообще лучше в LAN2 поставить свой локальный SIP-сервер, который будет сам регистрить клиентов и проксировать вызовы в LAN1?

[palich]

В этой LAN уже все настроено, отлажено и работает как часы.

Думаю, не только мне будет интересно узнать какая связка оборудования абон. шлюз --- SSW --- GW работает как часы.

Расскажите, если не секрет.

[Mikler]

Могу предложить решение. Поставить компьютер который смотрит в LAN1&LAN2 на него поставить SIP proxy и соответственно общаться. Ну и Абоненты LAN2 на него регистрируются и звонят как между собой так и маршрутизируются наружу. А сам SIP proxy представить как обычный GW с большим количеством абонентом и зарегистрировать на SW.

 

[ram_scan]

Протуннельте LAN1 в LAN2 решив этот вопрос с администрацией LAN2.

[leveler]

Думается, что при 100 тысячах точно потребуется в ЛАН2 свой СС.

А так, если адресное пространство не пересекается, то поставьте тачку (если на железный рутер денег жалко) между сетками и настройте файрвол.

[AEro]

В этой LAN уже все настроено, отлажено и работает как часы.

Думаю, не только мне будет интересно узнать какая связка оборудования абон. шлюз --- SSW --- GW работает как часы.

Расскажите, если не секрет.

:) не знаю, если честно, я смотрю со стороны LAN2, а LAN1 для меня чужое решение, подробности которого мне пока неизвестны - все со слов их стороны. Может и преувеличивают. Фактически LAN1 от нас хочет наших LAN2-абонентов, а мы просто хотим сделать своим абонентам приятное.

Когда узнаю детали, могу отписать.

 

Могу предложить решение. Поставить компьютер который смотрит в LAN1&LAN2 на него поставить SIP proxy и соответственно общаться. Ну и Абоненты LAN2 на него регистрируются и звонят как между собой так и маршрутизируются наружу. А сам SIP proxy представить как обычный GW с большим количеством абонентом и зарегистрировать на SW.

Решение интересное, проблема только в том, что все абоненты сейчас живут в софтсвитче в LAN1 - там база логинов+паролей, туда же прикручен биллинг, там единая служба поддержки, свои общие системы отчетов и проч... Тогда еще нужно мудрить с провижинигом подписок с софтсвитча на этот новый SIP proxy. Непонятно кто и как будет логировать, биллить в случае прямых контактов LAN2-LAN2. Также придется настраивать маршрутизацию из софтсвитча в этот новый SIP proxy, чтобы абоненты из LAN1 и из PSTN могли пробится в LAN2. Видимо, этому новому SIP proxy придется давать отдельный realm?

Собственно такое решение тоже рассматривается, но оно требует существенных доработок на стороне LAN1.

Сейчас основной вариант все-таки просто обеспечить транспортный канал между LAN1&LAN2 - роутер, который просто позволит клиентам из LAN2 прокидываться на софтсвитч в LAN1. Осталось только подумать, как там получится с преобразованием адресов (преодоление НАТ и файрволла) для сигнального и медиа трафика...

Думается, что при 100 тысячах точно потребуется в ЛАН2 свой СС.

А так, если адресное пространство не пересекается, то поставьте тачку (если на железный рутер денег жалко) между сетками и настройте файрвол.

Адресные пространства могут пересекаться. И там и там локальные серые IP. Так что роутер еще должен и НАТ-ПАТ преобразование делать.

Денег не на что не жалко, лишь бы все было по-правильному.

Как правильно настроить файрволл, чтобы SIP-сигналлинг туда-сюда ходил и медиа трафик когда нужно пробивался, а все остальное не пролезало.

Похоже, тут нужно нечто типа SBC.

Изменено 27 августа, 2008 пользователем AEro

[Mikler]

Вам сдаваться или поиграться? От этого и надо рассуждать.

Если сдаваться то нужно ставить SW

Если поиграться то звонки LAN2<-> LAN2 Билинговать нет необходимости. А сам факт прекрасно сохраняет прокси.

[ram_scan]

С прокси все не очень хорошо, потому-как не все прокси могут RTP проксирование, а те что могут не всегда делают это хорошо, или имеют много лишних бантиков которые будут и глючить и ресурсы жрать, и с совместимостью проблемить. Оно ж все что на сипе у каждого вендора по части допуслуг все "ниже пояса" сделано.

 

По идее таки да, надо SBC но стоять он должен в LAN1. Более менее рабочие варианты это подымать в LAN2 IP PBX и транком совокуплять ее с SW в LAN1, либо ставить в LAN1 SBC (штука очень-очень недешевая и со своим набором граблей).

 

Можно выкрутиться и с прокси конечно, но ежели завтра захочется дать клиенту что-то большее чем "набрать номер и дозвониться", хотя-бы тот-же call transfer элементарный придется начинать все сначала и все переделывать.

[rover-lt]

А что мешает дать белый IP софтсвитчу?

 

[BorodaSpb]

Вам однозначно нужен SBC или BCP (border control point).

[ram_scan]

"Вам" не нужен. "Вам" нужно поставить этот контроллер в LAN1, то есть 1) где-то за разумные деньги достать безглючный девайс, 2) договориться с администрацией LAN1 на тему "давайте поставим", и 3) решить вопрос с саппортом энтого барахла. Плюс SBC как девайс весьма специфический оч нетривиально работает и конфижится, поэтому надо иметь гуру под боком, или вендора за яйца держать.

 

Все сипово-опенсорцное что я видел и пробовал и что может подойти в качестве SBC - несьедобно. Все что продается за деньги стоит минимум пятизначную сумму зелени, и тоже не факт что сьедобно (я лично трогал Audiocodes nCite, отказаись нафиг, глюк на глюке даже со своими же родными шлюзами плюс пришлось на стенде очень здорово менять схему маршрутизации потому-что по другому никак, так задумано через жопу).

 

Поэтому топиктстартеру будет эффективнее всего поставить у себя на хорошем железе звезду, грамотно ее настроить, и решить вопрос с администрацией LAN1 с просовыванием транка со звезды до SSW. По крайней мере такое решение работать 100% будет, с отказами, косяками но будет. Эта же схема избавит администрацию LAN1 от геморроя с поддержкой чужих юзеров. Нарежут они у себя емкость, в транк завернут, а топикстартер у себя рулит, кого отключит, кого включит, кому допуслугу повесит, где в глюках разберется. Кроме того решить вопрос связности между двумя девайсами в разы проще чем решать этот вопрос для каждого юзера персонально. Плюс если вдруг появится более удачная схема то уволить звездочку не жалко.