#6: Акулы в океане SIP-телефонии. Анализ трафика с помощью Wireshark

Анна Сергеева. Акулы в океане SIP-телефонии. Анализ трафика с помощью Wireshark // Системный администратор. 2014. № 5. С.30-36.

Быстро выявить и устранить проблемы со связью в сетях SIP администратору поможет знание принципов работы протокола SIP и грамотное применение Wireshark.

Опубликовано в разделе "IP-телефония / Инструменты"

Эта же статья на сайте журнала

Широко распространенная сегодня SIP-телефония, как и любая технология, созданная человеком, не является абсолютным совершенством. А это значит, что возникают те или иные сложности со связью. Например, ситуация, когда с SIP-телефона не удается позвонить через маршрутизатор. Или возникают проблемы с принятием вызова, или происходит срыв вызова. А как насчет неисправностей при попытке переадресации вызова (нет возможности перевода на другого абонента или удержания звонящего абонента)? Не говоря уж о проблемах с прохождением голоса (не слышно собеседника, односторонняя слышимость)...

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

Откуда возникают проблемы

В сравнении с другими видами связи SIP-телефония предоставляет широкий спектр сервисных услуг. Помимо передачи голосовых данных, доступно еще трансляция видео, изображений различных форматов, почты, факсов и т.д. [1]. Пример построения сети SIP приведен на рис. 1 [2].

Рис. 1. Пример сети SIP

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

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

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

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

Структура сообщений SIP

В протоколе SIP структура сообщений следующая (Рис. 2).

Рис.2. Структура сообщений протокола SIP

Стартовая строка в запросах содержит тип запроса, указание адресата и номер версии протокола, а в ответах — номер версии протокола, идентификатор и расшифровку статуса обработки запроса.

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

То используется для идентификации адресата в формате протокола SIP в одном из форматов:

имя@IР-адрес

имя@домен

имя@хост

Nтелефона@шлюз

Также может содержать имя пользователя, например, если его нужно визуально отобразить на дисплее.

From используется для идентификации отправителя запроса. Структура аналогична полю То.

Call-ID — уникальный идентификатор сеанса связи или всех регистраций отдельного клиента. Его значение задается стороной, инициирующей вызов. Содержит буквенно-числовое значение, символ-разделитель (@) и имя рабочей станции, которая присвоила это значение (например, 123abc@site.domen.ru). Следует указать, что если с одной мультимедийной конференцией связано несколько соединений, то каждое из них будет иметь собственный Call-ID.

CSeq — уникальный идентификатор запроса, связанного с одним соединением. Используется для корреляции запросов и ответов. Содержит числовое значение (от 1 до 232) и текстовое указание типа запроса (например, 2 INVITE).

Via используется для настройки маршрутизации пакетов. В одних случаях, для избежания зацикливания пути следования запроса, в других случаях — для обязательного прохождения запросов и ответов по одному и тому же пути (например, при использовании брандмауэров). На пути следования запрос может проходить через ряд прокси-серверов, и каждый из них выполняет прием, обработку и перенаправление запроса к следующему прокси-серверу. При этом сервер дополняет содержимое данного заголовка указанием своего адреса. Это происходит до тех пор, пока запрос не достигает адресата. Таким образом, заголовок Via указывается весь путь, пройденный запросом. Содержимое полей заголовка Via копируется из запросов в соответствующие им ответы. И на пути следования ответов каждый сервер удаляет поле Via со своим именем.

Record-route используется прокси-сервером, если он желает, чтобы все последующие запросы проходили через него. В таком случае, прокси-сервер вписывает в заголовок свой адрес.

Content-Type указывает формат, в котором описан сеанс связи (например, SDP). Само же описание сеанса содержится в теле сообщения.

Content-Length указывает длину тела сообщения.

Алгоритмы установления соединения SIP

В стандарте сигнализации по протоколу SIP предусмотрены три базовых сценария процедуры установления соединения:

• непосредственно между пользователями сети;

• с участием сервера переадресации;

• с участием прокси-сервера.

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

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

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

Соединение SIP с участием сервера переадресации

Данный сценарий предусматривает следующую последовательность операций (рис. 3).

Рис. 3. Установление соединения SIP через сервер переадресации

Пользователи получают от администратора сети адрес сервера переадресации. Вызывающий абонент посылает запрос INVITE на этот известный адрес сервера и используемый по умолчанию порт 5060 (1). В запросе он указывает также адрес вызываемого пользователя. Сервер переадресации запрашивает у сервера определения местоположения текущий адрес нужного пользователя (2), и получает в ответ этот адрес (3). Затем сервер переадресации возвращает вызывающей стороне ответ 302 Moved temporarily, который содержит текущий адрес вызываемого пользователя (4). В качестве альтернативы, сервер переадресации может указать в ответе перечень зарегистрированных адресов, имеющих привязку к вызываемому пользователю, и оставить за вызывающей стороной право выбора одного из них. Вызывающая сторона посылает ACK (5) и тем самым подтверждает прием ответа 302.

Далее вызывающий пользователь имеет возможность связи непосредственно с вызываемым пользователем. Он посылает новый запрос INVITE (6), с тем же идентификатором вызова Call-ID, но уже с другим номером последовательности Cseq.

Само сообщение содержит SDP-информацию о функциональных возможностях оборудования вызывающей стороны. Вызываемая сторона возвращает ответ 100 Trying (7), при помощи которого сигнализирует о приеме INVITE и о начале его обработки. При приеме этого ответа таймеры вызывающей стороны перезапускаются. После того, как оборудование вызываемой стороны завершило обработку поступившего запроса, оно извещает своего пользователя о входящем вызове и вместе с тем возвращает ответ 180 Ringing (8) встречной стороне. Как только вызываемый абонент принял входящий вызов, по направлению к вызывающей стороне посылается сообщение 200 OK (9). Оно содержит SDP-информацию о функциональных возможностях оборудования вызываемого пользователя. Вызывающая сторона посылает сообщение ACK (10), с помощью чего подтверждает прием ответа. Теперь фаза установления соединения считается завершенной, и вызов переходит в разговорную фазу. По завершении разговора любая из сторон может передать завершающее сообщение BYE (11), которое будет подтверждено ответом 200 OK (12).

SDP (Session Description Protocol) — протокол описания сессий трансляции потоковых данных различных мультимедийных приложений. Поля протокола SDP служат для описания параметров видео, аудио, управления, данных, и по сути являются вспомогательными при организации процесса управления вызовом [3]).

Соединение SIP с участием прокси-сервера

Данный сценарий предусматривает следующую последовательность операций (рис. 4).

Рис. 4. Установление соединения SIP через прокси-сервер

Пользователи получают от администратора сети адрес прокси-сервера. Вызывающий абонент посылает запрос INVITE на этот адрес сервера и используемый по умолчанию порт 5060 (1). Здесь пользователь передает известный ему адрес вызываемого абонента. Далее прокси-сервер запрашивает у сервера определения местоположения текущий адрес вызываемой стороны (2), и в ответ получает этот адрес (3). Затем прокси-сервер связывается непосредственно с оборудованием вызываемого пользователя и передает ему запрос INVITE (4). Здесь так же содержится информация о функциональных возможностях оборудования вызывающей стороны, но в запрос при этом включается дополнительное поле Via, которое содержит адрес прокси-сервера. Это необходимо, чтобы все встречные сообщения проходили именно через него. После того, как оборудование вызываемой стороны завершило обработку поступившего запроса, оно извещает своего пользователя о входящем вызове и возвращает ответ 180 Ringing (5) встречной стороне. Этот ответ содержит копию полей То, From, Call-ID, Cseq и Via из соответствующего запроса.

Как только абонент принял вызов, встречной стороне отправляется сообщение 200 OK (6). Оно содержит SDP-информацию о функциональных возможностях оборудования вызываемого абонента. Вызывающий пользователь подтверждает прием ответа сообщением ACK (7). Фаза установления соединения считается завершенной, и вызов переходит в разговорную фазу. По завершении разговора любая из сторон передает завершающее сообщение BYE (8), которое будет подтверждено ответом 200 OK (9). Все запросы и отклики передаются через прокси-сервер, который, в свою очередь, может изменять в сообщениях некоторые поля.

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

Какие задачи нужно решать

Для обнаружения проблем связи в сетях SIP, специалисту, обеспечивающему обслуживание сети, нужно решать следующие задачи:

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

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

• Осуществлять проверку запросов, выполняемых по протоколу STUN.

• Просматривать и анализировать, как обрабатывается процедура регистрации телефонов.

• Прослушивать обнаруженные голосовые вызовы и оценивать качество обслуживания.

STUN (Session Traversal Utilities for NAT) — сетевой протокол, позволяющий клиенту выяснить свои сетевые параметры: внешний IP-адрес, способ трансляции адреса, порт во внешней сети, который связан с конкретным внутренним номером порта. Используется для UDP-соединений между двумя хостами в случаях, если оба они находятся за маршрутизатором NAT [4]).

Выбор инструмента. Wireshark

Существует целый ряд программных средств, более или менее подходящих для сбора сетевого трафика. Однако, они используются ограниченным кругом технических специалистов. И среди них можно найти такие инструменты, которые действительно будут эффективными и окажут помощь в каждодневной работе, связанной с обслуживанием сетей.

Автор предлагает остановить выбор на программе Wireshark, которую и сам с успехом использует.

Программа Wireshark (ранее известная под названием Ethereal), среди приложений с открытым кодом, является общепринятым фактическим стандартом для исследования сетей, а также анализа протоколов. Она дает возможность выполнять низкоуровневую фильтрацию пакетов и проводить их анализ. Wireshark позволяет открывать и работать с файлами, содержащими захваченные сетевые данные (trace files), и детально рассматривать их вплоть до каждого пакета.

Программа Wireshark находит широкое применение среди исследователей сетей. Администраторы сетей с ее помощью выявляют причины неполадок, возникающих в сетях. Специалистам в области сетевой безопасности программа помогает в поиске проблем с безопасностью сетей. Разработчики реализаций протоколов применяют Wireshark в отладочных целях, а пользователи — в процессе изучения принципов функционирования сетевых протоколов.

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

Сбор трафика

Итак, остановимся и подробнее рассмотрим действия, которые необходимо выполнить для сбора SIP-трафика при помощи программы Wireshark.

В первую очередь, необходимо скачать [5] и инсталлировать сам Wireshark.

Далее, запустив программу, нужно включить в меню интерфейсы для сбора трафика. Для этого нужно воспользоваться командой меню «Capture > Interface» (рис. 5).

Рис.5. Включение интерфейсов для сбора трафика с помощью программы Wireshark

Здесь необходимо выбрать тот или иной интересующий сетевой интерфейс, для которого Wireshark будет выполнять отслеживание трафика. После нажатия на кнопку "Start" будет отслеживаться и отображаться вся информация о пакетах, проходящих через данный интерфейс.

Настройка фильтрации

Чтобы Wireshark отслеживал только SIP-трафик, необходимо задать соответствующий фильтр (в главном окне программы в поле Filter указать sip).

Теперь, когда все настройки заданы, администратору нужно воспроизвести (повторить) то самое действие, которое он желает проанализировать (это может быть, например, исходящий вызов или регистрация на VoIP-провайдере).

Главное окно программы будет отображать только SIP-пакеты (рис.6). После завершения работы все данные могут быть сохранены для дальнейшего анализа (с помощью меню File).

Рис.6. Отображение SIP-пакетов в Wireshark

Здесь все данные представлены в удобном виде: можно быстро перемещаться по списку последовательных запросов и откликов или же просматривать детальную информацию по каждому сообщению.

Так, при необходимости, можно в этой детализации отыскать значение поля, связывающего интересующие сообщения, и задать его в качестве дополнительного параметра фильтрации. Практика показывает, что умелое применение фильтров дает возможность отсеивать значительную часть ненужного потока пакетов и позволяет сосредоточиться на проблемных данных. Здесь автор приводит краткий перечень удобных в каждодневном использовании фильтров (табл. 1). Отметим, что все используемые классификаторы являются регистрозависимыми, и они должны быть заданы только строчными буквами. При правильном задании фильтров поле Filter в главном окне программы подсвечивается зеленым.

Таблица 1. Удобные фильтры для отображения SIP-пакетов

Формат фильтра	Описание
ip.src== <IP_АДРЕС>	Исходящий трафик с указанного IP-адреса
ip.dst == <IP_АДРЕС>	Входящий трафик на указанный IP-адрес
ip.addr == <IP_АДРЕС>	Трафик с и на указанный IP-адрес
ip.src == <IP_АДРЕС> && sip	Исходящий SIP-трафик с указанного IP-адреса
ip.dst == <IP_АДРЕС> && sip	Входящий SIP-трафик на указанный IP-адрес
ip.src != <IP_АДРЕС> && ip.dst != <IP_АДРЕС> && sip	SIP-трафик, за исключением нежелательных IP-адресов
udp.port eq 5060	Трафик по UDP-порту 5060
ip.src==aaa.bbb.0.0/16 and ip.dst==aaa.bbb.0.0/16	Трафик из локальной сети (aaa.bbb.x.x) только между серверами и рабочими станциями, без интернет-трафика
alias contains <псевдоним>	Сообщения с указанием алиаса, содержащего конкретный псевдоним
<поле> matches <значение>	Фильтр с использованием регулярных выражений, например, frame matches "[Pp][Aa][Ss][Ss]"

Анализ графических диаграмм вызовов

Также, программа Wireshark содержит реализацию удобного механизма диагностики и анализа голосовых вызовов VoIP. В частности, есть возможность просматривать графические диаграммы интересующих вызовов и наблюдать, как выполнялся обмен данными SIP и его RTP-нагрузки.

Используя команду меню «Statistics > VoIP Calls» (или «Telephony > VoIP Calls», что определяется версией программы), доступно окно просмотра голосовых вызовов. (Рис. 7)

Рис.7. Обнаруженные голосовые вызовы

Для каждого вызова в списке отображается следующая информация:

• Start Time – время начала вызова.

• Stop Time — время завершения вызова.

• Initial Speaker – IP-адрес стороны (источник пакетов), инициирующей звонок.

• From — для вызовов SIP здесь указывается запрос INVITE.

• To — для вызовов SIP здесь также INVITE.

• Protocol — протокол сигнализации.

• Packets — количество пакетов, использованных за время вызова.

• State — статус вызова после его окончания.

• Comments - дополнительные комментарии.

В этом же окне можно выбрать интересующий вызов и с помощью кнопки «Graph” (или «Flow”, что определяется версией программы) вызвать окно, которое отображает графическую диаграмму, соответствующую обмену данными конкретного вызова. (Рис. 8)

Рис.8. Графическая диаграмма голосового вызова

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

Прослушивание вызовов и оценка качества обслуживания

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

Для анализа голосового трафика в программе отведено целое меню Telephony. Например, используя команду меню Telephony –> RTP –> Show All Streams, доступно окно RTP Streams для просмотра характеристик голосового трафика (обнаруженных RTP-потоков) (рис. 9).

Рис.9. Характеристики голосового трафика

Зачастую на наличие проблемы может сразу указать значение, пожалуй, самого важного для голоса, параметра Jitter. Также стоит обратить внимание и на количество потерянных пакетов (параметр Lost) и другие характеристики.

В этом же окне доступна кнопка “Analyze”, при нажатии на которую открывается окно анализа RTP-потоков (RTP stream Analysis). Здесь, выбрав интересующий поток, есть возможность его воспроизведения, для чего предусмотрена кнопка “Player”. При ее нажатии открывается окно проигрывателя (рис.10), где, в первую очередь, необходимо задать подходящее значение параметра Jitter buffer, а затем использовать кнопку ”Decode”.

Рис.10. Проигрыватель голосового трафика

Отобразится окно, напоминающее анализатор спектра (рис. 11).

Рис.11. Проигрыватель голосового трафика

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

Также есть еще один способ прослушивания голосовых вызовов. В упомянутом ранее окне (рис. 7) доступна кнопка «Player». Используя ее, можно выбрать и прослушать интересующие вызовы. Для установления приемлемого качества воспроизведения, следует задать подходящее значение параметра Jitter buffer.

Устранение наиболее распространенных проблем со связью

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

• Односторонняя слышимость
  

Чаще всего проблема возникает, когда для передачи или приема к одной из сторон закрыты порты. Может оказаться, что сетевой трафик по транспортному протоколу UDP/TCP блокируется каким-либо брандмауэром или роутером. Нужно в настройках устройства разрешить исходящий и входящий трафик для прохождения голосовых данных по UDP и TCP для конкретных IP-адресов и портов.

• Полностью отсутствует слышимость

Скорее всего, в сети периодически возникают перегрузки. Или ситуация схожа с предыдущей, но трафик блокируется в обе стороны.

Срыв вызова

Здесь возможно несколько причин.

1. Сеть не пропускает пакеты протокола UDP. Необходимо проверить, как настроены системы ограничения сетевого доступа.

2. Роутер или само оборудование абонента выполняет подмену содержимого в протоколе SIP. Следует в настройках оборудования выключить функцию поддержки SIP ALG (SIP Application Level Gateway – шлюз прикладного уровня, позволяющий голосовому RTP-трафику проходить устройство NAT без препятствий).

3. Проблема оборудования пользователя. Требуется сброс и переустановка настроек или же смена прошивки.

• Невозможно позвонить на номер телефонной сети

Если в архитектуре сети используется NAT или брандмауэр, то следует проверить, разрешен ли в его настройках трафик, а также убедиться в успешной маршрутизации пакетов SIP.

Cледует обратить внимание на код ошибки, по которой прерывается соединение.

Ошибка 480 Gateway timeout (таймаут шлюза) указывает на наличие проблем при прохождении сигнальных пакетов (от вызывающей стороны уходит запрос, но отсутствует прием ответного пакета ACK). Как правило, на это оказывают влияние некоторые NAT и брандмауэры.

Ошибка 513 Message Too Big (слишком большое сообщение) обусловлена проблемами маршрутизации пакетов SIP. При ошибочной маршрутизации возникает зацикливание пути пакетов от одного сервера к другому, и поскольку каждый сервер при прохождении пакета добавляет в него информацию о себе, то, пакет значительно разрастается и, в конце концов, превышает допустимый размер.

• Нет исходящей связи, после набора номера только короткие гудки

На это может быть несколько причин.

1. Возможно, оборудование абонента не зарегистрировано на сервере. Следовательно, нужно проверить наличие регистрации.

2. Неверно настроен план набора номера. Нужно проверить, как задан параметр Dial Plan в настройках оборудования конкретного абонента.

3. Неверный набор номера. Нужно выяснить, в каком виде абонент набирал номер, и известить его о правильном способе набора. Например, следует набирать номера в формате E.164 (74951234567) и учитывать формат и коды в случае междугородних и международных вызовов.

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

• Нет входящей связи, отсутствует переадресация

Возможные причины.

1. Неверно задан номер переадресации. Нужно в настройках переадресации оборудования абонента проверить, какой задан формат номера переадресации. Например, следует набирать номера в формате E.164 (74951234567) и учитывать формат и коды в случае междугородних и международных вызовов.

2. Неверно настроена сама переадресация вызовов. Следовательно, нужно проверить настройки переадресации. Например, проблема может возникнуть, когда в настройках указан тип переадресации «telephone», а в качестве номера для вызова указан идентификатор SIP-ID.

3. Причиной проблемы может оказаться и включенная на оборудовании абонента функция DND (Do Not Disturb, не беспокоить). В таком случае, стоит отключить ее.

• Нет возможности удержания входящего вызова или перевода на другого абонента

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

1. Оборудование абонента функционирует в импульсном режиме. Следует перевести его в тоновый режим работы.

2. Некорректно обрабатываются сигналы DTMF. Нужно сменить тип обработки сигналов DTMF на оборудовании абонента или на VoIP-шлюзе.

3. Проблема оборудования пользователя. Требуется сброс и переустановка настроек или же смена прошивки.

Заключение

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

Ссылки:

[1] Стандарт SIP — RFC3261. SIP: Session Initiation Protocol, IETF RFC 3261, June 2002.

[2] Гольдштейн, Б. С. IP телефония — М.: Радио и связь, 2001.

[3] Стандарт SDP — RFC4566. SDP: Session Description Protocol, IETF RFC 45661, July 2006.

[4] Стандарт STUN — RFC5389. Session Traversal Utilities for NAT (STUN), IETF RFC 5389, October 2008.

[5] Сайт программы Wireshark – http://www.wireshark.org/