Мониторинг SIP и устранение неполадок

Управлять VoIP системой достаточно сложно, особенно если вы работаете в гетерогенной сети с большим количеством различных SIP клиентов (различное программное обеспечение, все виды SIP-телефонов и терминалов, особенно IP-УАТС). SIP клиенты, как известно, постоянно сталкиваются с различными ошибками  реализации, и если вы не контролируете их сами (например, с центральным инструментом инициализации устройства), то появляются дополнительные факторы ошибок конфигурации, введенные вашими клиентами.

Ключевым фактором не всегда является гибкость заказа, особено когда она заканчивается на интерфейсе пользователя. Вот почему Skype настолько успешен, потому что «он просто работает».

В любом случае, если клиент использует ваш сервис VoIP (особенно, если это платная услуга), он просто должен работать, если же нет, необходимо как можно быстрее устранить причину ошибки и обеспечить решение для клиента. Если этого не сделать, клиенты уйдут очень скоро.

В плане устранения неполадок есть несколько подходов:

Подход бедняка

При таком подходе, чтобы устранить неполадки VoIP  где-то на линии используют следующее:

  1. Спрашивают клиента, когда он сделал неудачный вызов или когда не удалось зарегистрировать телефон.

  2. Используем греп лог-файлов для подсказок, которые указывают на ошибки.

  3. Если ничего существенного не происходит, то включите tcpdump в системе и попросите пользователя повторить вызов.

  4. Скопируйте результаты трассы на локальный компьютер и попытайтесь извлечь потенциальные пакеты с потенциальной большой трассы.

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

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

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

Внешние инструменты мониторинга в помощь!

Из-за огромных накладных расходов по устранению неполадок традиционным способом, вся новая экосистема построена вокруг внешнего мониторинга и анализа SIP. Для решения этих проблем созданы новые стартапы, и поддержка VoIP определенным образом упростилась. Единственная проблема для небольших операторов — эти решения стоят очень дорого. В телефонной промышленности, модели лицензирования разбиваются цене за линию или каждого абонента, и это не редкость, что цена линии из инструментов анализатора превышает цену линии в VoIP софт-переключателе, что является нецелесообразным.

Тем не менее, поскольку проекты с открытым исходным кодом становятся все более распространенными на рынке VoIP, то вполне естественно,  начинают появляться системы мониторинга VoIP и инструменты поиска неисправностей. Наиболее перспективным проектом в с открытым исходным кодом есть Homer, открытый SIP сервер  захвата. С тех пор, когда он научился пассивно перехвачивать трафик на зеркальных портах коммутатора, он прекрасно интегрировался в сетевую среду VoIP без вмешательства с существующими элементами сети.

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

Вместо того, чтобы вовлекать клиента в процесс поиска и устранения неисправностей, процесс выглядит следующим образом:

  • Фильтр звонков и регистрации соответствующего клиента

  • Визуальная проверка потоков вызовов и пакетов для обнаружения очевидных проблем

  • При необходимости, греп логов для конкретных звонков

  • Принятие мер и повторение процесса, если это необходимо

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

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