[VOIPSEC] RTP packet signature

mailinglist mailinglist at pbxnsip.com
Wed Oct 5 13:36:53 CDT 2005


Oopps, true. Anyway, the hash would be an additional method.-)

Take a look at Ethereal. I checks the signalling and then uses the
signalling as hint that a packet is a RTP packet. Seems like without looking
at the signalling it is not possible to detect that a packet is a RTP
packet.

> -----Original Message-----
> From: Haluska, John J [mailto:jhaluska at telcordia.com] 
> Sent: Wednesday, October 05, 2005 7:52 PM
> To: mailinglist at pbxnsip.com
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] RTP packet signature
> 
> I had the impression that the original question was regarding 
> a third party, not the intended recipient (who would have had 
> access to the signaling protocol). Third party would also not 
> be able to decode the packet if it's SRTP.
> 
>  
> -----Original Message-----
> From: mailinglist at pbxnsip.com [mailto:mailinglist at pbxnsip.com]
> Sent: Wednesday, October 05, 2005 12:11 PM
> To: Haluska, John J
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] RTP packet signature
> 
> 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
> > 
> > 
> > 
> 
> 
> 






More information about the Voipsec mailing list