Стресс-тест Asterisk
Не так давно проводил стресс-тест ростовского Asterisk на сервере, еще не введённом в боевую эксплуатацию. Тест проводил средствами утилиты sipp, с генерацией rtp-трафика в обе стороны, максимально близко к реальным условиям. Результаты приведу без анализа.
Параметры sipp следующие:
sipp -rtp_echo -mi 172.16.хх.хх -sn uac 192.168.хх.хх -d 2000 -s 100 -rp 2000 -r 5 -i 172.16.хх.хх -l 1
Сервер с Asterisk: 2,66 QuadCore 2 гига, HP DL120G5 X3330.
# uname -a Linux elastix.ххх.local 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008 i686 i686 i386 GNU/Linux
Тест проводился в два этапа. На первом этапе сервер загружался звонками приблизительно с 18.30 до 0.00. Прошло около 2 млн. звонков.
Загрузка памяти:
Видно, что загрузка памяти за время теста постоянно росла, после снятия звонковой нагрузки память осталась в том же состоянии до 10 утра, после чего видно, что память освободилась.
Второй тест проводился на следующий день. Где-то с 12.30 на средней загрузке, с 18.10 нагрузку резко увеличил. В срок с 18.10 по 4.00 утра прошло около 4х млн. звонков. На следующий день память освободилась в исходное состояние.
Отчёт sipp:
--------------------------- Statistics Screen ------- [1-9]: Change Screen -- Start Time | 2009-09-10 11:13:13:164 1252566793.164587 Last Reset Time | 2009-09-11 04:00:00:081 1252627200.081742 Current Time | 2009-09-11 04:00:00:973 1252627200.973702 -----------------------+---------------------------+-------------------------- Counter Name | Periodic value | Cumulative value -----------------------+---------------------------+-------------------------- Elapsed Time | 00:00:00:891 | 16:46:47:809 Call Rate | 109.989 cps | 69.101 cps -----------------------+---------------------------+-------------------------- Incoming call created | 0 | 0 OutGoing call created | 98 | 4174217 Total Call created | | 4174217 Current Call | 226 | -----------------------+---------------------------+-------------------------- Successful call | 98 | 4173045 Failed call | 0 | 946 -----------------------+---------------------------+-------------------------- Response Time 1 | 00:00:00:025 | 00:00:00:028 Call Length | 00:00:02:053 | 00:00:02:057 ------------------------------ Test Terminated --------------------------------
Лабораторная по полносвязной Frame Relay сети
Используется следующая топология:
Для full-mesh сети создаем необходимое количество VLC и задаем маппинг.
Лабораторная по chap-аутентификации в PPP сети
Создаем в GNS3 сеть с простой топологией:
Топология PPP лабы
Делаем начальные настройки – прописываем хостнеймы (внимательно отнеситесь к этому пункту, хостнеймы роутеров используются при ppp аутентификации) и адреса интерфейсов. Проверяем коннективити и переходим к собственно кофигурированию PPP:
GNS3, настройка сохранения конфигурации роутеров
Самой первой проблемой, с которой новички сталкиваются при использовании GNS3, является то, что конфиги роутеров не сохраняются при сохранении проекта и рестарте роутеров. Для исправления этой ситуации делаем следующее:
- Заходим в File / New Project
- В диалоговом окне оставляем галочки Export router configuration files и Keep working directory files
- Жмем ОК
Либо делаем так:
Выбираем New Project, выбираем имя для проекта, жмем OK, после чего соглашаемся применить настройки проекта к текущей топологии.
Парковка звонков
Парковка звонков – довольно спорная, на мой взгляд, возможность Cisco CallManager. Суть её в следующем: активный вызов можно повесить на удержание, а подобрать – с любого другого аппарата. Настраивается это так:
Меню Call Routing/Call Park:
Здесь указываем диапазон парковочных номеров, в цискиной нотации регулярных выражений:
Call Park Number/Range allowed characters are numeric (0-9), X, close square bracket (]), open square bracket ([), dash (-), asterisk (*), carat (^), pound (#).
Далее указываем партицию и используемый сервер CallManager.
Для того, чтобы запарковать вызов, нажимаем кнопку «Park» (или «Парк») после чего звонок паркуется на первый свободный номер из заданного диапазона. Информация о номере высвечивается на дисплее телефона. После этого звонок можно подобрать с любого аппарата, входящего в указанную партицию, просто набрав парковочный номер.
Медиа ресурсы
Этим громоздким словосочетанием (от английского media resources) называются устройства, терминирующие медиа трафик и предоставляющие определённый функционал оконечным потребителям IP телефонии – IP телефонам и голосовым шлюзам.
Рассмотрим примеры медиа ресурсов:
Конференцмосты (Conference Bridges)
Предоставляют возможность собирать и проводить конференции. Существует два типа конференций – Ad Hoc и Meet-me. В случае Ad Hoc конференции диспетчер собирает участников, обзванивая каждого со своего аппарата. В конференции Meet-Me каждый участник набирает определённый, уникальный для конференции номер, после того, как диспетчер создал конференцию. Конференцмосты бывают программными (например сервис Software Conference Bridge, входит в состав Cisco CallManager) и аппаратными (такие как Cisco IOS Conference Bridge).
Транскодеры (Transcoders)
Устройства, осуществляющие преобразование кодеков дуплексных rtp-потоков в реальном времени. Например, из G.711 в G.729. Преобразования между двумя кодеками, осуществляющими компрессию с потерей качества (такими как G.729 и G.723) нежелательны, потому что вследствие такого преобразования качество голоса ухудшается с каждым циклом компрессии/декомпрессии.
Транскодирование потребляет DSP ресурсы, следовательно при планировании сети с транскодерами следует выделять под них обособленные, специализированные устройства, с достаточным запасом DSP ресурсов.
Точки терминации среды (Media Termination Points, MTP)
Транскодеры также могут выступать в роли точек терминации среды, которые обеспечивают дополнительные сервисы, такие как удержание и трансфер звонка для устройств, работающих на протоколе H.323, который не обеспечивает подобные услуги по умолчанию.
Сервис ТТС может быть обеспечен программно. Отличие между транскодерами и программными MTP состоит в том, что программные MTP поддерживают лишь один кодек – G.711. Соответственно, MTP могут предоставлять дополнительные услуги для H.323 устройств, но не обеспечивают преобразование кодеков.
Все голосовые шлюзы, работающие на Cisco IOS, обеспечивают т.н. «null capabilities set» для протокола H.323, соответвенно MTP обычно использются для H.323 устройств сторонних производителей.
Сервера музыки-на-удержании (Music On Hold, MOH)
Служба MOH позволяет как OnNet так и OffNet абонентам при удержании слушать музыку, предоставляемую сервером MOH.
Количество участников конференций Cisco CallManager
Количество участников конференций Cisco Call Manager
Cisco Hardware Conference Bridge поддерживает голосовые модули Cisco Catalyst 4000 и 6000 со следующим количеством конференц-сессий:
- Cisco Catalyst 6000
В конференции с использованием кодека G.711 доступны 32 аудиопотока; до 10 конференц-сессий с тремя участниками в каждой конференции или одна конференц-сессия с 32 участниками.
- Cisco Catalyst 4000
В G.711 конференции возможен разговор между 24мя участниками, либо четыре конференции максимум, с шестью участниками в каждой.
- Cisco Software Conference Bridge; максимальное количество аудиопотоков – 128.
В програмной реализации Conference Bridge возможно участие до 128 пользователей в одной конференции, либо вплоть до 42х конференций с тремя участниками одновременно.
Замечание: если Cisco IP Voice Media Streaming Application service запущен не на одном сервере с Cisco CallManager service, то количество программных конференций (созданных при помощи Software Conference Bridge) не может превышать 128. Если же IP Voice Media Streaming Application service запущен на одном сервере с Cisco CallManager service, то количество программных конференций не должно превышать 48.
Примечание
Перевод этой статьи.
Дополнение
Количество пользователей в Ad Hoc конференциях (конференциях «по требованию», инициируемых организатором конференции) регламентируется в глобальных настройках Cisco CallManager – System/Service Parameters, Cisco CallManager Service, Maximum Ad Hoc Conference. Максимальное возможное число пользователей для этого параметра – 64; минимальное – 3; по умолчанию стоит 4. Эти данные нашел в документе, описывающем Cisco CallManager 4.0, но, подозреваю, это справедливо и для старших версий.
