0

I am working on a packet capture program to analyze RTP/RTCP traffic. The traffic is in mobile network, e.g., the VoLTE. I understand that I need to search in the SIP/SDP packets first to get the actual addresses and port numbers used in RTP/RTCP. The question is what information should I look into. For example:

  • Source/Destination and other information in the SIP packets. Since SIP proxy is used, the address of the SIP packet and information in SIP header like: "Via", "To" and "From", etc., have nothing to do with the RTP addresses, right? (P.S., what is the really purpose of these fields?)
  • What is the difference between o= line and c= line in SDP? Will the RTP uses one of them?
  • I have to find the common codecs and payload types supported in caller and callee's SDP to determine RTCP ports. If they support more than one codec for a media type, is it possible for the two ends to use different codec?
  • If there are STUN, TURN or ICE involved, what else should I look into?

There are so many protocols and it's hard to grasp them all to get a particular info needed. Thanks.

user2847598
  • 1,247
  • 1
  • 14
  • 25

1 Answers1

3

Source/Destination and other information in the SIP packets. Since SIP proxy is used, the address of the SIP packet and information in SIP header like: "Via", "To" and "From", etc., have nothing to do with the RTP addresses, right? (P.S., what is the really purpose of these fields?)

RIght, these information has nothing to do with your RTP/RTCP information, these are just information about the SIP proxy and two party associated with the SIP session related information.

What is the difference between o= line and c= line in SDP? Will the RTP uses one of them?

O line is also something you don't need to know, its about originator client information or identifier. C= line holds the default address for your session, this can be session level attribute or media level attribute if you have multiple media like RTP and RTCP. If its session level attribute in SDP then it will appear before m= line. If the session is non-ICE session then this address will be used for your media.

I have to find the common codecs and payload types supported in caller and callee's SDP to determine RTCP ports. If they support more than one codec for a media type, is it possible for the two ends to use different codec?

You will find the codec related information in m= line which will hold the media name, transport type and default port for that media, in case of non-ICE media this port will be used for that corresponding media. m= will hold the codec related information as well, these are space separated values. You can not use different codec unless the codec you selected is interoperable with the other one which is most unlikely.

If there are STUN, TURN or ICE involved, what else should I look into?

You will find these information as a= line, all the a= line appears after m= line until another m= line of end of SDP are that corresponding media attributes, lets say for candidate you will see something like a=candidate lines as ICE candidates, you may also see a=ice-pwd, a=ice-ufrag etc. Lets say if you have audio m= line with RTP and RTCP component then you may also see a=rtcp line with a port value which is RTCP default port, in that case the port appears in that m= line is RTP default port. For more details on SDP you can check the SDP RFC. Also you can check ICE RFC for ICE related attribute details.

Community
  • 1
  • 1
Palash Borhan Uddin
  • 374
  • 3
  • 12
  • To determine RTP and RTCP candidates from a=candidate you need to check the component ID of that candidate, for example {a=candidate:1 1 UDP 2130706431 10.1.1.26 59251 typ host} here two integer after the :, first one is foundation number which is defined by the ICE protocol, and next integer 1 is component ID. In that 1 for RTP and 2 for RTCP. so you will see something line {a=candidate:1 2 UDP 2130706430 10.1.1.26 59253 typ host} for RTCP with same foundation candidate. – Palash Borhan Uddin Dec 12 '15 at 16:57
  • Thank you for the info. By the way, is there a way to tell if the network has STUN, TURN or ICE configured (maybe the only info can tell is the a=candidate line)? – user2847598 Dec 13 '15 at 00:15
  • ICE is a client side application level protocol, STUN/TURN is client-server model but works with ICE so that means these requires client side implementation as well. If you are tracking these from as middle man than yes you need to check the SDP to understand if it supports ICE or not, There are same criteria which determines the SDP is ICE supported or not. a=candidate lines are one of them. If you see server-reflexive candidate then you can assume that its STUN supported, if you see relay type candidate then you can assume that TURN is also configured. – Palash Borhan Uddin Dec 13 '15 at 10:04
  • Thanks very much again. – user2847598 Dec 13 '15 at 16:24
  • But what about the correlation number (I've posted a question about it)? It seems to me that it is not needed, or did I get the answer wrong? – Uwe_98 Mar 09 '20 at 10:48