2c2i

Вы наверное читаете как то не так - тут написано "Добавлять и использовать не принадлежащие вам IP адреса." Нигде не написано про bgp анонсы. Кроме того не понятно зачем вообще какой либо bgp на впс. >Как я понял, достаточно настроить default напримнр на telia а вернуть трафик через ростелеком? >А если так делать через vps, можно попасть на 1000$. На впс очевидно так сделать не получится, просто потому что никакой хостинг не даст вам подключать свои каналы(телию и ростелеком) к впс.

Не знаю что там за "транзит через впс", но трафик отлично вернется через другого апстрим провайдера, которому клиент анонсирует свои префиксы.

Не понятно почему вы называете спуфингом отсылку трафика со своих адресов без анонсирования их. Спуфинг это когда для отсылки трафика используются _чужие адреса_, и эта принадлежность определяется не анонсами bgp, а базой данных например RIPE.

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

Есть еще опенсорс yeti. Для транскодинга ничего докупать не нужно, из коробки работает.

На А ноге для балансировки на несколько FS, тк FS заметно менее производителен, по этой же причине стоит на камаилио делать всякий рейтлимит и блеклистинг. На Б ноге чтобы отсылать звонки от кучи FS с одного сорс адреса. Если у вас на ноге Б множество чужих гейтвеев, то не очень удобно каждый раз при добавлении FS всех оповещать про новый IP. Мы довольно долго работали с такой системой, пока свой софт не написали.

sbc чисто на камаилио сложно весьма запилить, потому что kamailio это прокси, а для sbc неплохо иметь b2bua - отсюда рождаются схемы типа kamailio ->FS->kamailio.

Вообще можно, но так просто - нельзя. Для того чтобы RTP прошел нужно: 1) Знать реальные адреса и порты. В таблице locations могут быть адреса с которых пришла сигнализация, но rtp может приходить совсем с другого адреса 2) Иметь открытые NAT трансляции на пути к обоим абонентам.

https://yeti-switch.org/ - готовое решение для class4 роутинга, опенсорс. Биллинг и свитч в одном флаконе.

У меня нет конкретного желания покупать софт такого рода - я уже выше писал что мы успешно разрабатываем свой опенсорс и работаем на нём. Потому врядли я смогу получить цены в личку или у интеграторов. Речь о том что бесплатность о которой вы говорите публично - это просто игра слов. Правильнее сказать "до 250 сессий вы платите, а после 250 сессий вы платите еще больше".

Остается понять главное - сколько денег нужно заплатить чтобы получить 250 сессий, например без транскодинга.

Я не в теме про audiocodes и медиант, но из вышеописаного очевидно, что бесплатно вы можете только установить софт и запустить. А как только появятся звонки (больше 3х) - придется покупать некие лицензии. А как только одновременных звонков станет > 250 то придется платить еще больше(тк окажется что софт тоже начинает стоить денег, как только через него проходит > 250 звонков). Кроме того везде говорилось про сессии, их можно считать по разному, но часто 1 звонок=2 сессии и тогда все цифры можно поделить на два. Поправьте если я неправильно понял. PS: не ясно что значит " SBC, а не каллсвитч 4 уровня, т.е. функционал коммутации на нем отсутствует.". По моим представлениям sbc это одна из реализаций ssw class4. Ну и сложно понять что такое по вашему коммутация, если в sbc её нету.

Вы сообщили о проблеме, спасибо - мы услышали и устраним её. Если валидный сертификат вам настолько важен - ждите или скачайте софт на гитхабе или просто не рассматривайте наш софт.

Мы знаем о проблеме с сертификатом, попробуйте другой браузер - тема вроде про sbc, а не о проблемах сертификатов.

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

https://yeti-switch.org/ опенсорс, из сигнальных протоколов - только SIP, умеем кластеризацию, несложный биллинг. Есть поддержка RADIUS, транскодинг тоже есть. Скачивать из репозитория описанного в документации.

у кого-нибудь есть опыт применения в качестве SBC ? У нас есть опыт. Как чистый b2bua SEMS вполне неплох, однако если нужна хитрая логика - нужно программировать. Для нашего решения модуль sbc пришлось форкнуть и много переделывать. Если интересно - https://yeti-switch.org/

Есть еще опенсорс решения - SEMS с sbc модулем например.

Хотя, если вам нужно прозрачно - SEMS sbc подойдет, если конечно ваша схема позволит роутить через SEMS, без asterisk.

Вроде бы есть модуль камаилио http://kamailio.org/docs/modules/devel/modules/sipt.html, который декодирует sip-i/sip-t ISUP и даже умеет немного модифицировать. SEMS в режиме sbc умеет пропускать ISUP прозрачно, но декодировать/модифицировать не умеет. Мы похожую задачу сейчас планируем на SEMS решать, путем написания парсера ISUP.

http://yeti-switch.org/demo.html Готовое решение, бесплатно, разработано специально для транзита. Идеология роутинга - примерно как у MVTS II. Простой биллинг интегрирован, если хочется что то свое - очень просто сделать экспорт СДР во внешнюю систему. Разрабатывалось для работы в кластере, каждая часть системы резервируется.

Кому то интересен опенсорс SIP class4 SBC? Решение сделано по мотивам mvtsII, и предназначено для A-Z транзита. В качестве свитча используется SEMS + свои модули. Демо можно посмотреть тут - http://yeti-switch.org/demo.html

Забыли только сказать что FT не работает с SMP.

Если система грузится сама(имеется ввиду ключ вводить не нужно), то может банально попробовать init=/bin/bash параметром ядра, перед тем как к серьезным действиям приступать?

Пробовал ли кто-то с 3.9 ядром? [2013-05-08 14:56:23]: msg: accel-ppp version d38ee4ecee74f47a7fdbff7a5d77b7c6371776d6 [2013-05-08 14:56:23]: info: recv [PPPoE PADI 20:cf:30:27:10:97 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 0100000001000000>] [2013-05-08 14:56:23]: info: send [PPPoE PADO 00:0e:0c:a7:23:f6 => 20:cf:30:27:10:97 sid=0000 <AC-Name pppoe-node2> <Service-Name > <AC-Cookie 37dbbbf1d3639278c7c880322c06ca36d703056575e2b561> <Host-Uniq 0100000001000000>] [2013-05-08 14:56:23]: info: recv [PPPoE PADR 20:cf:30:27:10:97 => 00:0e:0c:a7:23:f6 sid=0000 <Service-Name > <Host-Uniq 0100000002000000> <AC-Cookie 37dbbbf1d3639278c7c880322c06ca36d703056575e2b561>] [2013-05-08 14:56:23]: info: send [PPPoE PADS 00:0e:0c:a7:23:f6 => 20:cf:30:27:10:97 sid=0001 <AC-Name pppoe-node2> <Service-Name > <Host-Uniq 0100000002000000>] [2013-05-08 14:56:23]: error: : ioctl(PPPIOCGCHAN): Bad file descriptor [2013-05-08 14:56:23]: info: send [PPPoE PADT 00:0e:0c:a7:23:f6 => 20:cf:30:27:10:97 sid=0001 <AC-Name pppoe-node2> <Service-Name > <Host-Uniq 0100000002000000>] [2013-05-08 14:56:24]: warn: failed to load pppoe kernel module [2013-05-08 14:56:24]: msg: accel-ppp version d38ee4ecee74f47a7fdbff7a5d77b7c6371776d6 Судя по всему accel еще и рестартует после "error: : ioctl(PPPIOCGCHAN): Bad file descriptor"