[Michael Oliveras <moliveras@xxxxxxxx>]

Title: RE: [Ethereal-users] LCF decode from Vocaltec GK does not display 2ndalternate endpoi nt - challenge string

I assume that you only expanded the relavent sections of the setup message on the decode - that being the case it looks great!

Thanks for the quick turnaround.

Regards,

Michael Oliveras
ITXC QA Engineering
609.750.3454 - office
609.750.3272 - lab
moliveras@xxxxxxxx

-----Original Message-----
From: Tomas Kukosa [mailto:tomas.kukosa@xxxxxxxxxxx]
Sent: Wednesday, April 14, 2004 2:28 AM
To: Ethereal user support
Subject: Re: [Ethereal-users] LCF decode from Vocaltec GK does not
display 2ndalternate endpoi nt - challenge string

Could you look into the attached report if your capture file is decoded well?
If yes I will relese the h235 ASAP.
   Tomas

Michael Oliveras wrote:
> Ronnie,
>
> Thanks very much for your patch!  I compiled ehtereal from cvs and the
> LCF is now decoded properly. It seems however that the patch introduced
> a problem.  There is a "challengestring" present in the token section of
> several h225 messages - ARQ, RRQ, and SETUP.
>
> Before your patch ethereal simply ignored this section; in the cvs
> version, ethereal is trying  to decode the clear token and does not know
> how to decode this. The packet is reported as malformed, and the rest of
> the packet is not decoded.  Could you add support for the challenge
> string?
>
> I attached a capture file that contains an ARQ, RRQ, and SETUP message.
>
> Thanks for all your help,
>
> Mike Oliveras
>
>
>
> -----Original Message-----
> From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
> Sent: Thursday, April 08, 2004 8:10 PM
> To: Ethereal user support
> Subject: Re: [Ethereal-users] LCF decode from Vocaltec GK does not
> display 2ndalternate endpoi nt
>
>
> LCF decode from Vocaltec GK does not display 2nd alternate endpointHi,
> Many thanks for your bugreport.
> I have checked in a patch that will make ethereal decode that packet
> properly.
> It will be avaialble in the next version of ethereal.
>
> Ethereal when decoding that packet should have printed something like "NOT
> DECODED YET[ClearToken]" to the console which means
> that ethereal encountered a PER contrust (cleartoken in this case)
> ewthereal
> did not know how to decode and thus
> everything from that point further in that packet was just decoded as
> garbage data.
>
>
> The problem with your packet was that no one had even bothered enough about
> H.235 to even attempt to decode these
> ClearToken fields. Maybe H.235 is very rare so almost no one had
> encountered
> it previously? I dont know, Im not a VoIP person.
> Since no one had implemented decoding of ClearTokens previously ethereal
> failed to decode your packet
> properly (since it contained ClearTokens).
>
> I implemented a limited support for ClearTokens and its fields so it
> will at
> least decode your packet properly.
> There are though still a lot of other contrustcs, mainly related to H.235
> that no one has cared enough about to implement and which
> can/will cause similar problems.
> Please report any other problems you see and encounter. I dont use VoIP
> myself, dont have access to VoIP and also lack interest in VoIP so it
> is impossible for me to create required captures to test those
> unimplemented
> fields.
> Please keep sending captures and bugreports to the list and myself or
> someone else can implement the missing parts.
>
> Thanks again for the bugreport (missing functionality) and for the capture
> that allowed me to implement decodes for these fields.
>
> best regards
>     ronnie sahlberg
>
>
> ----- Original Message -----
> From: Michael Oliveras
> To: 'ethereal-users@xxxxxxxxxxxx'
> Sent: Thursday, April 08, 2004 9:34 AM
> Subject: [Ethereal-users] LCF decode from Vocaltec GK does not display
> 2ndalternate endpoi nt
>
>
> I noticed a decode issue on ethereal 0.10.3
> I attached a trace of an LCF that was sent from a Vocaltec GK.  The LCF
> contains a total of three endpoints (an endpoint and two alternate
> endpoints).
> When I look at the decode on ethereal, it only displays the 1st alternate
> endpoint and not the 2nd.  I can actually see the h323ID of the 2nd
> alternate endpoint in the text decode of the hex pane
> (5350-t1-13@xxxxxxxxxxxxxxxxxxx), so it seems that the information was
> captured but not decoded.
> Any help would be appreciated.
> Thanks,
> Mike Oliveras