["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

>I have tested with the CVS version and it seems to work good when Ethereal
sees the H.323 (H.225/H.245) signalling.

It works really well now.
A significant reason for it to work as well as it currently does is due to
the feedback, testing and hard work that You have
put into it  helping it becoming as good as it is today.
Thanks.

>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?

It is possible.  The things missing before this can b done are:
example captures
description by someone that knows how SIP and RTP signalling works to
describe how the detection/signalling works
a patch to implement it.

>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?

When h245 creates the conversation for RTP it ould attach a struct that
contains whatever extra data is needed.
This struct should come froma GMemChunk so it is easy to reclaim the data
later.
I think there is an example in packet-smb.c (and elsewhere) that attaches a
struct to the conversation for another dissector to pick up later.

>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

Maybe if h245 attaches such extra structs describing some extra information,
the rtp dissector could later pick this info up from
this struct and do the right thing?



----- Original Message -----
From: "Martin Regner"
Sent: Saturday, September 06, 2003 3:56 AM
Subject: 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.



_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users