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:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2003 11:21 AM > To: Chet Seligman > Cc: [EMAIL PROTECTED] > 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. > >
