Every RTP packet should have a payload type that lists the codec used.
In my case it would be G.729A or G.711, there are 3 or 4 other common ones
After I guessed which ports were used by RTP, I examined the decodes and saw
the G.729 payload - that's how I knew I was correct. What I didn't know was
whether I got all the packets. Not getting all packet makes jitter
measurements not terribly meaningful.
You speak of a "look-ahead" - could that be where the payload type is used?
BTW: Agilent Advisor and Radcom can identify RTP & RTCP without human help -
I don't know how they do it.
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Thursday, August 28, 2003 11:21 AM
> To: Chet Seligman
> Cc: ethereal-users@xxxxxxxxxxxx
> Subject: Re: [Ethereal-users] How do I decode RTP ?
>
>
>
> On Thursday, August 28, 2003, at 8:13 AM, Chet Seligman wrote:
>
> > I have captured a few VoIP calls and the decode only shows them to be
> > UDP.
> > I have done a "decode as" and selected a pair of ports as RTP (they
> > probably
> > are but I'm not certain) and I get a decode.
> >
> > Is this the proper methodology?
> >
> > Is there a way to get ethereal to recognize which packets are RTP and
> > without me knowing what ports are involved?
>
> http://www.ethereal.com/faq.html#q5.26
>
> If somebody can come up with a "good" heuristic to implement 2) from
> the list in that FAQ, where "good" means "recognizes as many RTP
> packets as possible as being RTP *AND* mis-recognizes as *FEW*
> *NON*-RTP packets as possible as being RTP even though they aren't", we
> could add that to the RTP dissector.
>
> Unfortunately, the "(they probably are but I'm not certain)" suggests
> that it wasn't obvious to you, from looking at the packet, whether it
> was RTP; if it's hard for a human to figure that out, it might be hard
> for a computer to do it as well....
>
> There don't seem to be a lot of fields in the RTP fixed header that
> would always have the same value, or a value within a given range.
> There's the "V" field, although that's only 2 bits, so other packets
> might well have binary 10 in those two bits, and there's the "PT"
> field, for which we could require that it be a *known* payload type.
> Ethereal heuristics have to look at the packet in isolation (a
> cross-packet heuristic would be much more complicated - we'd have to
> implement some sort of "look-ahead", but, in the general case, I'm not
> sure you can implement a form of look-ahead that could recognize
> packets as being UDP and thus potential RTP packets without having to
> dissect those packets, in which case we'd have to worry about that
> dissection affecting packet state), so the sequence number doesn't seem
> to be usable.
>
>