VoIP_V2
.docxМИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
Ордена Трудового Красного Знамени федеральное государственное бюджетное образовательное учреждение высшего образования
МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ
__________________________________________________________
Факультет СиСС
Кафедра Сети связи и системы коммутации
Задание № 4
по дисциплине «Мультисервисные системы и сети»
на тему:
«Чтение трассы вызова VoIP»
Выполнил: ст. гр. БЗС2002
Ломакин А. А.
Проверил: доц. каф. ССиСК
Деарт В. Ю.
(Весенний семестр)
Москва 2023
1. Задание
Установить программу – анализатор трафика WireShark. Изучить ее возможности, в частности, возможности фильтрации.
Показать временную диаграмму установления соединения VoIP по протоколу SIP.
Подробно проанализировать трассировку процесса установления соединения.
2. Исходные данные
Файл с трассой «SIP_CALL_RTP_G711» был взят с сайта «https://wiki.wireshark.org/gollum/search?q=sip_call» и будет в приложении к отчёту.
3. Выполнение
Для начала следует определить, сколько всего вызовов VoIP было на данной трассе. Для этого можно воспользоваться встроенной функцией WireShark, а именно Телефония Вызовы VoIP:
Рисунок 1 – вызовы VoIP
Нам откроется следующее окно, в котором можно заметить 3 вызова:
Рисунок 2 – все звонки VoIP
Обратим внимание на столбик «Протокол» - нас интересует только протокол инициации сессий SIP (Session Initiation Protocol), поэтому звонок по протоколу MGCP не будет рассмотрен.
Итак, имеется 2 звонка по протоколу SIP, разберем каждый из них более подробно. Для начала рассмотрим странный звонок длительностью в 0 секунд:
Для того, чтобы получить временную диаграмму установления соединения VoIP, нужно выделить интересующий нас звонок мышкой, после чего нажать «Flow Sequence»:
Рисунок 3 – Flow sequence
После чего нам откроется следующее окно с временной диаграммой:
Рисунок 4 – временная диаграмма вызова
Из диаграммы следует, что терминал с IP 200.57.7.196 (следует из разобранного ниже запроса INVITE в поле Message Body) послал INVITE (приглашение к соединению) на прокси-сервер с IP 200.57.7.195, который переслал INVITE на терминал с IP 200.57.7.204 с содержательной частью, сформированной протоколом SDP (указан список кодеков (которыми владеет терминал 200.57.7.196), порт для соединения и другая информация). В ответ терминал отсылает 100 Trying и 180 Ringing, после чего временная диаграмма кончается, хотя для разговора по RTP необходимо отправить еще 200 OK (со списком выбранных для разговорной сессии кодеков и номера порта) и принять ACK от вызвавшего терминала.
Полная временная диаграмма того, как это должно быть, представлена на рисунке:
Рисунок 5 - Временная диаграмма установления соединения VoIP, передачи речи и разъединения между двумя SIP терминалами через прокси-сервер
Посмотрим на каждый из запросов рассмотренного выше вызова подробнее, для этого применим фильтр «sip» к трассе:
Рисунок 6 – фильтр sip
На рисунке выше нас интересуют запросы, обведенные красным. Рассмотрим запрос INVITE более подробно (красным подчеркнуты данные, на которые, как я думаю, следует обратить внимание):
Рисунок 7 – запрос INVITE
Разберем запрос сверху-вниз:
Src: 200.57.7.195 – Ip-адрес прокси.
Dst: 200.57.7.204 – IP-адрес терминала, принявшего запрос.
Далее идут назначенные порты.
После идёт IP-адрес прокси.
<sip:francisco@bestel.com:55060> - кому назначается этот запрос.
1 INVITE – тип запроса.
application/sdp – указано, что для формирования тела сообщения был использован SDP.
200.57.7.196 – IP-адрес вызывающего терминала.
Далее видно, что будет передаваться audio, назначен порт, стек и список кодеков, которыми обладает отправивший запрос терминал.
После идет подробное описание кодеков.
Рисунок 8 – ответ 100 Trying
Из данного рисунка видно, что терминал посылает прокси ответ 100 Trying.
Далее терминал-получатель (изначального запроса INVITE) отвечает сообщением 180 Ringing, которое сервер пересылает терминалу-отправителю (изначального запроса INVITE):
Рисунок 9 – ответ 180 Ringing
Как уже было сказано выше, дальше по всем канонам должны были быть ответы 200 OK, ACK и начало RTP-сессии, но в данном звонке их не было, поэтому перейдем к более подробному рассмотрению второго звонка.
Теперь рассмотрим звонок длительностью 8.5 секунд (как я понял, 8.5 секунд – это длительность не самого звонка (RTP-сессии), а длительность установления соединения, т.к. сам звонок длится около 26 секунд (будет показано дальше)). Для начала рассмотрим его временную диаграмму:
Рисунок 10 – временная диаграмма вызова
Из диаграммы следует, что терминал с IP 200.57.7.196 послал INVITE (приглашение к соединению) на прокси-сервер с содержательной частью, сформированной протоколом SDP (указан список кодеков, порт для соединения и другая информация). Прокси переслал этот запрос к терминалу 200.57.7.204. В ответ терминал посылает 100 Trying, 180 Ringing и 200 OK, после чего образуется RTP-сессия.
Итого получаем: 200.57.7.196 – терминал, который первым послал INVITE на прокси, 200.57.7.204 – второй терминал, который принял INVITE, 200.57.7.195 – прокси.
Посмотрим на каждый из запросов/ответов рассмотренного выше вызова подробнее, для этого применим фильтр «sip» к трассе:
Рисунок 11 – фильтр sip
На рисунке выше нас интересуют запросы, обведенные красным. Рассмотрим запрос INVITE более подробно:
Рисунок 12 – запрос INVITE
Здесь, аналогично разобранному выше запросу INVITE, указаны IP-адреса терминала, принимающего запрос, прокси, от кого запрос, тип запроса, IP-адрес вызывающего (второго) терминала, что будет передаваться audio, назначен порт, стек и список кодеков с их подробным описанием.
После идут ответы 100 Trying и 180 Ringing, которые полностью аналогичны рассмотренным выше.
Далее вызываемый терминал посылает прокси 200 OK, подробное описание которого представлено на рисунке ниже:
Рисунок 13 – сообщение 200 OK
В этом сообщении указывается, что для передачи голоса выбран кодек G.711 с A-законом, а номер UDP-порта – 8000.
Между терминалами открывается RTP-сессия, по которой происходит обмен голосовыми пакетами. По значению временных меток этих пакетов можно судить о продолжительности разговора (Timestamp).
Рассмотрим RTP-сессию более подробно. Для начала мы можем в окне вызовов VoIP выбрать необходимый нам звонок и нажать «Play Streams», после чего нам откроется проигрыватель RTP:
Рисунок 14 – Play Streams
Рисунок 15 – проигрыватель RTP
В данном окне можно прослушать разговор, а также увидеть выбранный кодек, длительность разговора, порты, IP-адреса и количество пакетов.
Теперь рассмотрим RTP-сессию более подробно, для этого введем фильтр «rtp» ко всей трассе:
Рисунок 16 – фильтр «rtp»
На рисунке выше красным подчеркнуты первые 3 пакета RTP в одну сторону (от вызываемого терминала к вызывающему), а зеленым первые 3 RTP пакета в другую сторону (от вызывающего терминала к вызываемому). По значению меток Seq и Time можно судить о номере RTP-пакета. Время отправки первых пакетов с той и другой стороны совпадает с временной диаграммой.
Проследим, когда был отправлен последний RTP-пакет, что свидетельствует о конце разговора:
Рисунок 17 – конец RTP-сессии вызывающего терминала
На рисунке выше красным подчеркнут последний RTP-пакет для вызываемого терминала. Время отправки пакета совпадает со временем окончания разговора в проигрывателе RTP.
Рисунок 18 – конец RTP-сессии вызываемого терминала
На рисунке выше зеленым подчеркнут последний RTP-пакет для вызывающего терминала. Время отправки пакета совпадает со временем окончания разговора в проигрывателе RTP.
Подробнее разберемся с форматом RTP-пакета:
Рисунок 19 – RTP-пакет
На рисунке выше представлен первый RTP-пакет от вызываемого терминала. Мы можем увидеть IP-адреса обоих терминалов (поля Src и Dst), порт принимающей и отправляющей пакет стороны, Sequence number (определяет последовательный номер пакета (+1 с каждым пакетом RTP)), Timestamp (относительная временная метка), а также выбранный кодек. SSI – источник синхронизации, который выбирается случайно.
Также стоит рассмотреть пакет RTCP, который используется для контроля RTP сессии и сбора полезной информации:
Рисунок 20 – RTCP-пакет
SR (Sender Reports – рапорт источника) – содержит статистическую информацию отправителя и информацию получателей;
RR (Receiver Reports – рапорт приемника) – содержит статистическую информацию получателей;
Первые 2 бита (10) — версия протокола RTCP.
P-бит (0) - признак наличия заполнения (Padding).
RC размером 5 бит (00001) обозначает число блоков источников, представленных в данном рапорте.
Поле PT – 8 бит - тип пакета (SR – рапорт отправителя, RR – рапорт приемника).
Далее идут биты для поля Length – длина пакета.
SSRC – идентификатор источника синхронизации (идентификатор источника);
NTP timestamp (64 бита) – значение абсолютной метки времени в формате протокола NTP. Значение этого поля вместе с временной меткой в пакете отправителя может быть использовано для расчета RTT;
RTP timestamp – содержит метку относительного времени, сгенерированную протоколом RTP;
Sender packet count – содержит число отправленных пакетов с начала текущей сессии;
Sender octet count – содержит общее число октетов, отправленных с начала сессии;
Fraction Lost (8 бит) – доля потерянных пакетов данного источника относительно общего числа пакетов;
Packet Lost (24 бит) – общее число потерянных пакетов данного источника;
Highest Sequence Number – максимальный номер пакета, полученного от данного источника;
LSR – старшая часть последнего значения метки времени NTP (Network Time Protocol) TimeStamp, полученного от данного источника;
DLSR – задержка времени от получения последнего сообщения от данного источника до формирования данного блока.
Ключевыми полями для понимания качества обслуживания, как я думаю, являются Fraction Lost и Packet Lost, а также DLSR. В данном RTCP-пакете Fraction Lost = 0, Packet Lost = 0 и DLSR = 1 (0 milliseconds), поэтому можно с уверенностью сказать, что RTP-пакеты, отправленные до этого RTCP-пакета, дошли успешно.