[VOIPSEC] RTP packet signature

[mailinglist]

The SRTP packets may have a hash at the end of the packet (4 or 10 bytes).
If the receiver is able to decoce the packet it will also be able to check
the hash. If it does not match you can discard the packet.

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Haluska, John J
> Sent: Wednesday, October 05, 2005 3:46 PM
> To: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] RTP packet signature
> 
> 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 etc
> a.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
> 
> 
>