martin, et al--
changing the preferences does not make the decode any better. in fact i
believe it becomes worse. that would make sense since martin metions the
2 versions are not compatible. if it had worked i would have asked some
very different questions, starting with why the encoding version changes
for only 2 sequnece numbers several thousand packets into a call....
--roger
-----Original Message-----
From: martin.regner@xxxxxxxxx [mailto:martin.regner@xxxxxxxxx]
Sent: Friday, August 06, 2004 11:53 AM
To: Ethereal user support; 'ethereal-users@xxxxxxxxxxxx'
Cc: rnichols@xxxxxxxxxxxxxx
Subject: Re: [Ethereal-users] t.38/ udptl decode discrepancy
Roger Nichols wrote:
> i am using ethereal 10.5 and have a question on the decode of the
following
> 4 packets. (these are a t.38 trace from udp port 17126 to port 56210.)
the
> first packet decodes correctly, and is the 2nd to last piece of an ecm
> frame. the 2nd packet has a decode error, which it should. i believe the
> ifp length is wrong. it is reported as 10, but there seems to be a byte
> missing from the ifp indicating the recovery packet type. my question is
on
> the 3rd and 4th packets. they do not have a decode error in ethereal,
even
> though they contain as recovery/ secondary packets the same ifp which is
> (correctly, i believe) flagged as malformed.
>
> what do you guys think? is there an ethereal decoder bug? or am i missing
> somthing in the 'a' length ifp?
>
> thanks,
> --roger
>
> ps, ive never quite figured out how the hi-lighting works, and i liked the
> decode descriptions better in 10.4, which behaves the same way on these 4
> packets
Hi
I havent been able too look at your files since Im on a vatation trip and
sitting on
an Internet cafe.
But please note that you may have to change preference settings for T38 in
Ethereal
(Edit/Preferences.../Protocols/T38).
There are incompatible ASN.1 specifications for T.38 so you have to select
the
right one (pre-Corrigendum is the default).
