Ethereal-users: Re: [Ethereal-users] how does ethereal determine whether RTP or not?
Guy Harris wrote:
>On Fri, Sep 05, 2003 at 04:48:30PM +1000, Ronnie Sahlberg wrote:
>> Version 0.9.15 of ethereal will be able to detect most RTP traffic
>> automatically since it has
>> support for h225 and h245 (h323).
>
>But it'll only be able to detect that traffic automatically *if* the
>H.245 packets or RTSP that set up the session are in the capture (and if
>the session was set up using H.245 or RTSP). If you capture the middle
>of some RTP session, or if some other protocol is used to set up the
>session, you'll still have to use "Decode As".
Hi,
I have tested with the CVS version and it seems to work good when Ethereal sees the H.323 (H.225/H.245) signalling.
Maybe even better than when using the H.323-plugin.
I think I remember that there could be some problem for "fast start" scenarios when using the H.323-plugin.
Wouldn't it be possible to get similar functionality for SIP (Session Initiation Protocol)? Maybe the SDP dissector could put some
data in the pinfo private data structure (or similar) that could be used by the SIP dissector to start a conversation?
Or maybe there is a better way of doing this?
Another thing I have been thinking about is that maybe it would be good to be able to include information about the "payload format"
(e.g. mime-type) and maybe some other things when starting the conversation (SIP/H.323/RTSP), so that the RTP dissector can get information whether the dynamic payload type is "H.263/2000", "AMR", MPEG-4 video ("MP4V-ES" ??) or ....
http://www.iana.org/assignments/rtp-parameters
Is there any good way for transferring this information from H.245 dissector to the RTP dissector?
If it was possible to have strings in dissector tables then the RTP dissector could call e.g. a "H.263-2000" dissector,
if the "H.263-2000" had registered that string in a "rtp.mime" dissector table or similar.
http://www.ethereal.com/lists/ethereal-dev/200308/msg00458.html
Ethereal (CVS-version) has support for payload type 34 (H263 - RFC 2190), but not "H.263-2000" (RFC 2429) that
is using a dynamic paylad type so it is not "possible" to recognize "H.263-2000" in a good way, I think.
http://www.ethereal.com/lists/ethereal-dev/200308/msg00336.html
PS! I'm working on some configurable heuristic RTP/RTCP dissectors that should be possible to be use for scenarios where the H.323/SIP/RTSP signalling is missing or similar. However in that case it would normally not be possible to get the right "payload
format" for dynamic payload types.
