Отказоустойчивое ядро VoIP сети

[EDA_SPB]

Коллеги, приветствую!

 

Хотел обратиться к коллективному разуму, не могу найти ответа на глупый вопрос.

Рисую на бумаге проект VoIP сети. Рисую для себя, в продакшн не собираюсь использовать, исключительно в образовательных целях пока.

Все просто, 2 сервера с freeswitch, шлюз в PSTN. Балансировать предполагаю с помощью Cisco ACE (просто у нас уже имеется).

Вопрос в маршрутизации. Не могу понять, по какому принципу настраивается, когда есть неопределенность и неизвестно на каком сервере зарегистрирован абонент.

1. Приходит звонок из pstn. Как понять, на какой freeswitch маршрутизировать звонок? Только перебором? А если их не 2, а 10?

2. Звонок между абонентами внутри сети. У freeswitch есть список локальных префиксов, и он должен быть одинаковым на всех серверах. И если 2 абонента зарегистрировались на разных серверах, то звонок будет невозможен.

 

Подскажите best practice таких архитектур.

 

Спасибо!

Edited April 10, 2013 by EDA_SPB

[QWE]

Коллеги, приветствую!

 

Хотел обратиться к коллективному разуму, не могу найти ответа на глупый вопрос.

Рисую на бумаге проект VoIP сети. Рисую для себя, в продакшн не собираюсь использовать, исключительно в образовательных целях пока.

Все просто, 2 сервера с freeswitch, шлюз в PSTN. Балансировать предполагаю с помощью Cisco ACE (просто у нас уже имеется).

Вопрос в маршрутизации. Не могу понять, по какому принципу настраивается, когда есть неопределенность и неизвестно на каком сервере зарегистрирован абонент.

1. Приходит звонок из pstn. Как понять, на какой freeswitch маршрутизировать звонок? Только перебором? А если их не 2, а 10?

2. Звонок между абонентами внутри сети. У freeswitch есть список локальных префиксов, и он должен быть одинаковым на всех серверах. И если 2 абонента зарегистрировались на разных серверах, то звонок будет невозможен.

 

Подскажите best practice таких архитектур.

 

Спасибо!

В общем случае для разруливания вызовов из PSTN по всей видимости не хватает еще одного элемента/балансера или просто SIP proxy - между PSTN шлюзом и FS1&2. FS1&2 должны сообщить этому SIP proxy о зарегистрированных абонентах. PSTN шлюз делает вызов на этот SIP proxy, он "отбивает" c SIP redirect/refer на какой FS отправлять запрос.

Cisco ACE нарисована в том месте где она сможет сделать балансинг только для транзитного трафика в PSTN( терминация), но непонятно для чего на пути вызова в PSTN FS - в качестве SBC?

Чтобы использовать вместо SIP proxy Cisco ACE для разруливания вызовов из PSTN видимо надо задействовать RADIUS - http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/classlb.html#wp1165781,

либо скриптом с freeswitch править критерии class-map ов для "SIP Header Fields" http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/classlb.html#wp1117403

 

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

Надо определиться - балансинг для распределения чего?

может что то классическое http://www.kamailio.org/w/2010/05/kamailio-and-freeswitch-integration-jun-2-2010/ ?

Edited April 12, 2013 by QWE

[EDA_SPB]

Цель - спроектировать масштабируемую и отказоустоичивую VoIP сеть. У нас проблемы с прогнозированием нагрузки. Но оставим этот вопрос. В общем, хотелось иметь такую архитектуру, которая позволит без проблем включать в будущем новый freeswitch для разгрузки существующих. Softswitch в схеме для клиентского медиа + sip регистрация.

Т.е. хотелось бы динамически распределять абонентов одного домена между n софтсвитчами.

Проблема в том, что я очень слабо представляю возможности всех компонентов, ну и опыта нет.

 

Чтобы использовать вместо SIP proxy Cisco ACE для разруливания вызовов из PSTN видимо надо задействовать RADIUS - http://www.cisco.com....html#wp1165781,

Покурю этот документ да досуге. Вообще авторизация по радиусу предполагается.

 

 

Надо определиться - балансинг для распределения чего?

 

Для распределения нагрузки на SW. Предполагаем много медиа (нагруженные коллцентры), транскодинг.

 

Спасибо!

[Shiva]

А вы представляете количество разговоров, что бы среднему ксеону стало плохо от фрисвича? Я думаю вы столько не нагенерите. У ФС есть фейловер с подхватом разговоров. Абонент максимум 3-5 секунд слышит тишину, далее разговор продолжается. Проще железо растить, ибо виртуалку перекинуть с старого на новый сервер проблем не составит.

 

И зачем Вам транскодинг?

[rover-lt]

И зачем Вам транскодинг?

Умную дипломку пишет

[EDA_SPB]

А вы представляете количество разговоров, что бы среднему ксеону стало плохо от фрисвича? Я думаю вы столько не нагенерите. У ФС есть фейловер с подхватом разговоров. Абонент максимум 3-5 секунд слышит тишину, далее разговор продолжается. Проще железо растить, ибо виртуалку перекинуть с старого на новый сервер проблем не составит.

 

Вникаю в тему потихоньку. Прихожу к мысли, что схема в первом сообщении не катит. Согласен с Вами, зарезервирую на уровне кластера виртуальных машин.

 

И зачем Вам транскодинг?

 

Сеть состоит из сегментов с различным транспортом - оптика, wifi, wimax. Есть проблемные участки.

В моем ограниченном понимании работы VoIP будет иметь смысл использовать различные кодаки на этих участках.

Дать лучшее качество оптическим клиетнам, зажать максимум в wimax, но сэкономить на полосе. (Есть проблема в аплинке)

 

И зачем Вам транскодинг?

Умную дипломку пишет

Вы так говорите, как будто в этом есть что-то плохое :)

[Shiva]

Сеть состоит из сегментов с различным транспортом - оптика, wifi, wimax. Есть проблемные участки.

В моем ограниченном понимании работы VoIP будет иметь смысл использовать различные кодаки на этих участках.

Дать лучшее качество оптическим клиетнам, зажать максимум в wimax, но сэкономить на полосе. (Есть проблема в аплинке)

Высоконагруженный колцентр на WiFi/WiMax, lol, точно дипломка... Молчу.

[EDA_SPB]

Вот почему выпускники вне рынка, им консультации никто не дает. :)

 

Высоконагруженный колцентр на WiFi/WiMax, lol, точно дипломка... Молчу.

 

Не "Высоконагруженный". А просто нагруженный. И, конечно, подключение по оптике. У нас в компаниий (в ПТУ где я учусь, то есть) есть свой + предполагается еще штуки 2-3. Около 50 одновременных звонков в пике каждый.

 

Теперь про транскодинг. В моей воображаемой сети есть различные сегменты. WiMax (802.16e), WiFi (Mikrotik), оптика.

Есть проблемы, в основном в 802.16e - недостаток ресурсов в аплинке на некоторых секторах.

Вопрос - имеет ли смысл запилить разные кодаки на этих участках? Идея - на участках без проблем с пропускной способностью дать лучшее качество, на проблемных хуже, но экономить на полосе. Вопросы QoS опускаем пока.

Не хочу завалить защиту, декан может денег не дать на реализацию.

 

Спасибо!

[QWE]

Вот почему выпускники вне рынка, им консультации никто не дает. :)

 

Высоконагруженный колцентр на WiFi/WiMax, lol, точно дипломка... Молчу.

 

Не "Высоконагруженный". А просто нагруженный. И, конечно, подключение по оптике. У нас в компаниий (в ПТУ где я учусь, то есть) есть свой + предполагается еще штуки 2-3. Около 50 одновременных звонков в пике каждый.

 

Теперь про транскодинг. В моей воображаемой сети есть различные сегменты. WiMax (802.16e), WiFi (Mikrotik), оптика.

Есть проблемы, в основном в 802.16e - недостаток ресурсов в аплинке на некоторых секторах.

Вопрос - имеет ли смысл запилить разные кодаки на этих участках? Идея - на участках без проблем с пропускной способностью дать лучшее качество, на проблемных хуже, но экономить на полосе. Вопросы QoS опускаем пока.

Не хочу завалить защиту, декан может денег не дать на реализацию.

 

Спасибо!

Как то не ассоциируется колл центр с wimax и wifi, и тем более что уже есть проблемы.

Ну да ладно. Определитесь со свободной полосой на этих сетях (там где она есть) и поделите на потребляемую полосу кодека (учитывая все заголовки) = макс кол-во вызовов. Так же помониторьте ping -ом с ключом -f задержки/потери/дрожание wimax wifi сетей дозагрузив сети необходимым кол-вом трафика близким по природе к голосовому (RTP), 100 pps на двусторонний голосовой канал для g711, можно iperf-om, sipp или fs. И убедитесь в том что сможете ли вы даже выбрав кодек с наименьшей полосой для необходимого числа каналов обеспечиться требуемое качество. Если вылезут потери, джиттер то все это чревато. Может быть потери уже есть? На fs можно проиграть и записать голосовой трафик в файл, после при прослушивании можно убедиться в качестве.

 

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

g729 на fs стоит денег. Транскодинг будет кушать ресурсы системы. Аппаратное решение для транскодинга по типу http://www.sangoma.com/assets/docs/datasheets/en/d100.pdf

 

Вообще коллцентр высоконагруженный нужно делать на IP телефонах и на свичах соединяя их на скорости 100/1000 Мбит/с. 150*85кбит(g711)=12,75Мбит/с полоса потребления голосовым трафиком на внутреннем и внешнем интерфейсах fs.

[EDA_SPB]

QWE, Shiva, огромное спасибо за разъяснения.

Реально помогли.

 

Плату транскодинга вряд ли получится прикрутить, softswitch планируется в виртуальной машине, виртуализация на блейдах.

Edited April 18, 2013 by EDA_SPB

[agr]

Будет ли success story внедрения, ну то есть сдачи диплома, в отдельно взятом ПТУ связи им. Симона Боливара ?:)

 

Какая в итоге схема load-balancing'а в/из PSTN будет делаться на кластере из FS?

[EDA_SPB]

Если и будет, то нескоро...

Не раньше, чем через полгода.

 

Пока схему делаю по принципу этой статьи: http://habrahabr.ru/post/140517/

По совету Shiva, решил не заморачиваться с балансировкой на уровне sip.

Стресс тесты еще не проводил, железо не готово, но уверен что с производительностью будет все ок.

G729 платный только для транскодинга, в теории можно построить всю VoIP сеть на нем и не платить.

Сильно не хватает практики для подтверждения/опровержения этой теории.

[QWE]

Если и будет, то нескоро...

Не раньше, чем через полгода.

 

Пока схему делаю по принципу этой статьи: http://habrahabr.ru/post/140517/

По совету Shiva, решил не заморачиваться с балансировкой на уровне sip.

Стресс тесты еще не проводил, железо не готово, но уверен что с производительностью будет все ок.

G729 платный только для транскодинга, в теории можно построить всю VoIP сеть на нем и не платить.

Сильно не хватает практики для подтверждения/опровержения этой теории.

Построить можно, если медиа будет только транзитом ходить через fs. Если функции IP PBX: IVR,voicemail,call record (и др) не нужны то все будет работать.Медиа можно даже и на fs не заводить. Вопрос в чем, перечисленные функции скорее всего (я так думаю - не проверял) используют кодек g711, и если приходит вызов из PSTN, а предполагается что вызов придет уже в g729 то каким образом функции "согласуют" медиа? нужен ли будет транскодинг? можете проверить, железо как я понял у Вас уже есть (PSTN GW) для этого - для практики.

может выбрать кодек g726 (толще чем g729 в два раза)? , он по умолчанию работает во fs.

на кодеках отличных от g711 DTMF в inband (т.е. не в голосовых пакетах кодека) не пройдет. Здесь могут быть заморочки.

 

Оригинал для http://habrahabr.ru/post/140517/ находится на официальном сайте fs. Приведенная статья на хабрахабр вцелом охватывает принципы. На этапе внедрения вылезет много вопросов. Рекомендую дистр Centos 5.8. Шлюзы/телефоны должны уметь reINVITE, на этом построена схема восстановления(перехода на резервную ноду) кластера. Если у Вас реально будет 160 одновременных вызовов то failover во fs для такой нагрузки надо потестить, если конечно для Вас будет супер критично чтобы голос обрывался на заявленное в статье время. CPS 160 - это прилично, для скромного десктопного железа под fs. Выдержат ли цифровой (я так понял он у Вас один) и много портовые аналоговые шлюзы (если будут или уже есть) такой CPS? Для себя считаю Более важным не подхват резервной нодой установленных вызовов основной, а просто активацию на 100% резервной ноды. не все функции IP PBX во fs поддерживают кластерный режим работы.

Не забывайте что проектируемая Вами VoIP сеть это не только медиашлюзы и софтсвичи это еще и ethernet коммутаторы + в вашем случае железо WiFI WiMax сетей. Если между PSTN GW и кластером fs только один коммутатор - единая точка отказа, и он тоже может сломаться/глюкнуть.

Edited April 20, 2013 by QWE

[EDA_SPB]

на кодеках отличных от g711 DTMF в inband (т.е. не в голосовых пакетах кодека) не пройдет. Здесь могут быть заморочки.

 

Не знал. Т.е. во избежание лучше использовать g711?

 

Для себя считаю Более важным не подхват резервной нодой установленных вызовов основной, а просто активацию на 100% резервной ноды.

 

Совершенно согласен. Подхват сессий как приятный бонус.

 

Если между PSTN GW и кластером fs только один коммутатор - единая точка отказа, и он тоже может сломаться/глюкнуть.

 

Нет, не забываем. У нас, слава богу, с этим все впорядке. Ресурсы ДЦ неплохо зарезервированы.

[QWE]

на кодеках отличных от g711 DTMF в inband (т.е. не в голосовых пакетах кодека) не пройдет. Здесь могут быть заморочки.

 

Не знал. Т.е. во избежание лучше использовать g711?

 

 

DTMF может передаваться

 

1. в голосовом тракте (inband) - подходит только для кодеков g711

2. в методах SIP INFO

3. rfc 2833, внутри rtp пакетов

 

Читаем возможности fs

http://wiki.freeswitch.com/wiki/Sofia.conf.xml#DTMF

http://wiki.freeswitch.com/wiki/Misc._Dialplan_Tools_start_dtmf

http://wiki.freeswitch.com/wiki/Misc._Dialplan_Tools_start_dtmf_generate

 

с этим придеться столкнуться если вся сеть будет на кодеке g729

[agr]

в приведенной статье с хабра рассматривает вариант кластера типа Active/Stanby. В этом случае как такового распределения нагрузки по нодам не происходит, и производительность системы наращивается апгрейдом аппаратных ресурсов каждой ноды, а не увеличением количества нод. Более интересен был бы вариант с Active/Active, как в начальной постановке задачи.