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.