Ethereal-dev: [Ethereal-dev] Re: h245 - fastStart support

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Wed, 9 Jul 2003 07:32:24 +1000
Thanks a lot for the feedback.
I am happy to hear that the tests worked well.

I am surprised the dissector works as well as it currently does,
only one real decoding bug yet and that was where i belive the per standard
was a bit unclear.

There are still a few places where the macro NOT_DECODED_YET() is invoked,
meaning
just that I dont have capture files showing how those constructs are encoded
in the bitstream
and thus i can not test them.

If you find any captures where the data is misdissected or where the
NOT_DECODED_YET macro is invoked
please email those captures to me.

Progress is good on the dissector.   With more testing and feedback on
missing items by those that have access
to h245 captures it looks like it might soon be possible to split it into a
asn-per.c and a packet-h245.c file and
add it properly to ethereal.

best regards
    ronnie sahlberg

----- Original Message -----
From: "Lars Roland"
Sent: Wednesday, July 09, 2003 4:12 AM
Subject: h245 - fastStart support


> Hello Ronnie,
>
> I created a smaller version of the original h323-plugin (nearly without
> h245) which uses your dissector for decoding fastStart elements. It
> should also register your dissector for h245 conversations, but I cannot
> test that.
> Therefore I 'd like to have the attachements checked in the cvs-tree. We
> will need those changes later anyway, when we create our own
> h225-dissector. I will mail the plugin-source to anyone, who is
> interested (about 188 kByte zipped). It is also necessary to change the
> plugin api, but because this is only for testing, I recommend to check
> them not in.
>
> I tested your dissector, and as far as I can see, it already decodes
> fastStart elements without any errors. However all fastStart elements
> start with dissect_h245_OpenLogicalChannel() so I can only tell you,
> that at least this function and its dependencies seem to be OK.
>
> Very good work.
>
> Regards,
>
> Lars
>