[VOIPSEC] RTP packet signature

[Jeffrey Skelton]

I¹d describe this as a flow based analysis as opposed to a packet based
analysis. John describes a flow analysis technique that I believe is fairly
robust at identifying RTP producing/consuming endpoints on a network. One
other item to add would be the existence of an approximately symmetric data
flow between the communicating addresses.

On 10/5/05 8:52 AM, "Haluska, John J" <jhaluska at telcordia.com> wrote:

> Of course almost anything is  possible. In general, it would be very
> difficult to determine without any context whether a single packet
> contains RTP.
> 
> The only field you can really count on is the RTP version field, pretty
> much anything else can change. And this  is  a very small field, the
> chances of any random packet matching that value at that offset in the
> UDP header  is pretty good anyway,
> 
> The ports used for RTP are negotiated dynamically, so it's not possible
> (without context) to know even which port number to look for.
> 
> With context, it is possible, but not simple. So a single packet would
> tell nothing. But if you look for a stream, with packets sent at
> periodic intervals (usually 10 or 20 msec for pcm type codecs), and see
> appropriately incrementing values in the offsets where the RTP
> timestamps and sequence numbers belong, and a constant  value where  the
> SSRC belongs, and yu have some reason to think there could be  an RTP
> stream here, then you've got a start.
> 
> There are other clues too, like the presence of sparse traffic at udp
> port number + 1, which would be RTCP, you could analyze these packets
> (if they exist) and correlate the  information here with that in the
> suspected RTP stream.
> 
> In my experience I have seen that certain endpoint always use the same
> UDP port numbers for RTP streams, if you have the context of knowing the
> endpoints then you might also be able to use this information.  Also, if
> the particular endpoints always use the same SSRC (it is supposed to be
> randomly chosen but this may not always be done) then you can look at
> this too. But again this requires that you know in advance what you are
> looking at, so in general this cannot be used.
> 
> But this is only to determine that you do in fact have RTP, not sure
> what you intend to do with it. If they are using dynamic payload types
> as recommended by the RFCs, then you cannot in general know the codec
> from the payload type, you need to guess or play trial and error with
> different codecs.
> 
> So, for a single packet, there is really no signature you can reliably
> count on. With enough context and processing, you can do it. All this of
> course  applies just to RFC  3550 RTP sent in the clear.
> 
> 
> 
> John Haluska
> 
> 
> 
> Message: 3
> 
> Date: Tue, 4 Oct 2005 16:53:32 +0200
> 
> From: Marc.JACOBS at etca.alcatel.be
> 
> Subject: [VOIPSEC] RTP packet signature
> 
> To: Voipsec at voipsa.org
> 
> Message-ID:
> 
> 
> <OF377A4B83.D2232863-ONC1257090.0050CD02-C1257090.0051CE77 at etca.alcatel.
> be>
> 
>      
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> Dear all,
> 
> Is there a means to know either an UDP/TCP packet encapsulates a
> RTP/RTCP
> 
> packet or not without using the signaling protocols (SIP, H323, ...) ?
> In
> 
> other words, how can I identify a RTP packet on-the-fly without having
> 
> access to the signaling protocol ?
> 
> Thanks,
> 
> Marc
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>