Call-центр

Для IP-телефонии критичны задержки пакетов в сети, хотя технология обладает некоей толерантностью (устойчивостью) к потерям отдельных пакетов. Так, потеря до 5 % пакетов не приводит к ухудшению разборчивости речи. Максимальное отклонение между последовательной передачей пакетов в сети Интернет не должны превышать 50 мс. Максимальный процент потерь при передачи пакетов в сети Интернет – не более 3%.

Причины задержек в передаче голосовых данных по сети IP в большой степени связаны с особенностями транспорта пакетов. Протокол TCP обеспечивает контроль доставки пакетов, однако достаточно медленный и потому не используется для передачи голоса. UDP быстро отправляет пакеты, однако восстановление потерянных данных не гарантируется, что приводит к потерянным частям разговора при восстановлении (обратном преобразовании) звука. Немалые проблемы приносит джиттер (отклонения в периоде поступления-приёмки пакетов), появляющийся при передаче через большое число узлов в нагруженной IP-сети. Недостаточно высокая пропускная способность сети (например при одновременной нагрузке несколькими пользователями), серьёзно влияет не только на задержки (то есть рост джиттера), но и приводит к большим потерям пакетов.

Между конечными точками пользователей и серверами IP-телефонии, а также между серверами IP-телефонии и оборудованием оператора связи (поставщика VoIP) программных или аппаратных устройств, канал должен отвечать описанным выше требованиям.

Проверить пропускную способность каналов можно с помощью простой утилиты iperf-2.0.5. Предположим, что мы хотим гарантировать 10 одновременных разговоров с использованием G.711 кодека. Рекомендуемое требование к каналу составляет 1 Мбит/с.

На сервере запускаем iperf с параметрами (ожидать на стандартном порте 5001 входящие UDP запросы):
iperf -u -s

На клиенте запускаем тестирование UDP c длиной 160 байт со скоростью 1 Мбит/с в течение 180 секунд на сервер 10.10.10.119:
iperf -u -c 10.10.10.119 -l 160 -b 1M -t 180

Получаем результат:

Канал пригоден для 10 одновременных соединений.

До официального релиза Webitel 1.3 осталось еще не много, а я уже сейчас хочу начать рассказывать о всех тех новых фишках, что мы в него добавили. Первая на очереди небольшая функция «Маршрут звонка».

Нас часто спрашивали: а как узнать где уже был звонок? Либо: а можно оператору сразу в карточке показать, что абонент был в IVR, потом поговорил с другим оператором, потом его переключили опять на IVR, а с него он попал на другого оператора?

Теперь это все возможно! В карточке звонка оператора доступна новая вкладка «Маршрут», а в разделе [Статистика] — кнопка, нажав на которую, Вы увидите историю прохождения звонка:

Roadmap

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

Как Вы думаете: насколько будет полезной эта функция?

Каждый, кто успел попробовать Webitel CallManager, обратил внимание, что в версии 1.0 отсутствует понятие очередей. Этот досадный момент будет решен с выходом 1.1. В этой небольшой заметке хочу описать, как построен механизм создания входящей очереди.

Входящая очередь
Входящая очередь

Что здесь самое интересное?

Планирую во вторник (20.11.2012) провести вебинар, на котором расскажу о функциональных возможностях нашего нового продукта Terrasoft Webitel CallManager. Если Вам интересно, что он из себя представляет — регистрируйтесь на вебинар. Так же, можете задавать вопросы в комментариях к данному посту.

Softswitch — Выпуск #04 от 15.09.2012

После перерыва в 3 недели я записал 4 выпуск!
Из новостей. Обновились: YATE, 3CX, Asterisk. Мысли о безопасности программных IP АТС.
Практика отправки SMS, FAX и как пропустить 30 звонков через канал в 0,5 Mbps
Встречаем новый кодек Opus. Когда уже наступит эра HD телефонии???
У нас есть первый победитель!
Жду Ваших вопросов!