VoIP
.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) — версия протокола.
P-бит (0) - показывает, что пакет не содержит октетов, заполняющих бит для выравнивания.
RC размером 5 бит (00001) обозначает число блоков источников, представленных в данном рапорте.
Поле PT – 8 бит - тип пакета (SR – рапорт отправителя, RR – рапорт приемника).
Далее идут биты для поля Length – длина пакета.
После идет Timestamp MSW для Sender Report (64 бита) – абсолютная метка времени в формате протокола NTP, может быть использована для расчета RTT.
Далее идет относительная метка времени LSW для Sender Report (64 бита), сгенерированная потоком RTP.
После идет Senders packer count для Sender Report (64 бита) — число отправленных пакетов с начала текущей сессии.
Далее расположен Senders octet count для Sender Report (64 бита) – общее число октетов, отправленное с начала сессии.