Найти RTP/RTCP после SIP/SDP

Я работаю над программой захвата пакетов для анализа трафика RTP/RTCP. Трафик находится в мобильной сети, например, VoLTE. Я понимаю, что мне нужно сначала выполнить поиск в пакетах SIP/SDP, чтобы получить фактические адреса и номера портов, используемые в RTP/RTCP. Вопрос в том, какую информацию я должен изучить. Например:

  • Источник/назначение и другая информация в SIP-пакетах. Поскольку используется SIP-прокси, адрес SIP-пакета и информация в заголовке SIP, например: «Через», «Кому» и «От кого» и т. д., не имеют ничего общего с адресами RTP, верно? (P.S., какова истинная цель этих полей?)
  • В чем разница между строкой o= и строкой c= в SDP? Будет ли RTP использовать один из них?
  • Мне нужно найти общие кодеки и типы полезной нагрузки, поддерживаемые в SDP вызывающего и вызываемого абонентов, чтобы определить порты RTCP. Если они поддерживают более одного кодека для типа мультимедиа, возможно ли, чтобы две стороны использовали разные кодеки?
  • Если задействованы STUN, TURN или ICE, на что еще мне следует обратить внимание?

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


person user2847598    schedule 12.12.2015    source источник


Ответы (1)


Источник/назначение и другая информация в SIP-пакетах. Поскольку используется SIP-прокси, адрес SIP-пакета и информация в заголовке SIP, например: «Через», «Кому» и «От кого» и т. д., не имеют ничего общего с адресами RTP, верно? (P.S., какова истинная цель этих полей?)

ПРАВИЛЬНО, эта информация не имеет ничего общего с вашей информацией RTP/RTCP, это просто информация о прокси-сервере SIP и двух сторонах, связанных с информацией, связанной с сеансом SIP.

В чем разница между строкой o= и строкой c= в SDP? Будет ли RTP использовать один из них?

Строка O также является тем, что вам не нужно знать, это касается информации или идентификатора клиента отправителя. Строка C= содержит адрес по умолчанию для вашего сеанса, это может быть атрибут уровня сеанса или атрибут уровня мультимедиа, если у вас есть несколько носителей, таких как RTP и RTCP. Если его атрибут уровня сеанса в SDP, то он появится перед строкой m=. Если сеанс не является сеансом ICE, этот адрес будет использоваться для ваших медиафайлов.

Мне нужно найти общие кодеки и типы полезной нагрузки, поддерживаемые в SDP вызывающего и вызываемого абонентов, чтобы определить порты RTCP. Если они поддерживают более одного кодека для типа мультимедиа, возможно ли, чтобы две стороны использовали разные кодеки?

Вы найдете информацию, связанную с кодеком, в строке m=, которая будет содержать имя носителя, тип транспорта и порт по умолчанию для этого носителя. В случае носителя, отличного от ICE, этот порт будет использоваться для соответствующего носителя. m= также будет содержать информацию, связанную с кодеком, это значения, разделенные пробелами. Вы не можете использовать другой кодек, если только выбранный вами кодек не совместим с другим кодеком, что маловероятно.

Если задействованы STUN, TURN или ICE, на что еще мне следует обратить внимание?

Вы найдете эту информацию в виде строки a=, вся строка a= появляется после строки m= до тех пор, пока другая строка m= конца SDP не будет соответствовать атрибутам мультимедиа, скажем, для кандидата вы увидите что-то вроде строк a=candidate как ICE кандидаты, вы также можете увидеть a=ice-pwd, a=ice-ufrag и т. д. Допустим, если у вас есть звуковая строка m= с компонентом RTP и RTCP, вы также можете увидеть строку a=rtcp со значением порта, которое является значением порта RTCP по умолчанию. порт, в этом случае порт отображается в строке m= как порт по умолчанию RTP. Дополнительные сведения о SDP см. в RFC SDP. Также вы можете проверить ICE RFC, чтобы узнать подробности об атрибутах, связанных с ICE.

person Palash Borhan Uddin    schedule 12.12.2015
comment
Чтобы определить кандидатов RTP и RTCP из a=candidate, вам нужно проверить идентификатор компонента этого кандидата, например {a=candidate:1 1 UDP 2130706431 10.1.1.26 59251 typ host} здесь два целых числа после :, первое из которых является основанием номер, который определяется протоколом ICE, а следующее целое число 1 является идентификатором компонента. В том, что 1 для RTP и 2 для RTCP. поэтому вы увидите строку {a=candidate:1 2 UDP 2130706430 10.1.1.26 59253 typ host} для RTCP с тем же кандидатом в основу. - person Palash Borhan Uddin; 12.12.2015
comment
Спасибо Вам за информацию. Кстати, есть ли способ узнать, настроены ли в сети STUN, TURN или ICE (может быть, единственная информация, которую можно сказать, это строка a=candidate)? - person user2847598; 13.12.2015
comment
ICE — это протокол уровня приложения на стороне клиента, STUN/TURN — это модель клиент-сервер, но она работает с ICE, поэтому это означает, что они также требуют реализации на стороне клиента. Если вы отслеживаете их как посредника, тогда да, вам нужно проверить SDP, чтобы понять, поддерживает ли он ICE или нет. Существуют те же критерии, которые определяют, поддерживается ли SDP ICE или нет. строки a=candidate являются одними из них. Если вы видите серверно-рефлексивного кандидата, вы можете предположить, что его STUN поддерживается, если вы видите кандидата типа ретрансляции, вы можете предположить, что TURN также настроен. - person Palash Borhan Uddin; 13.12.2015
comment
Большое спасибо еще раз. - person user2847598; 13.12.2015
comment
Но как насчет числа корреляции (я задавал вопрос об этом)? Мне кажется, что он не нужен, или я неправильно ответил? - person Uwe_98; 09.03.2020