Re: [Opalvoip-devel] Bug in ASN parser?

[Robert J. <ro...@vo...>]

I suppose so. The ASN.1 specifications just say that there must be a default
value for non-OPTIONAL extension field, but does not say what that value
must be. So, I suppose we need to build into the ASN system some mechanism
to do so.

I am currently overseas for work, I should be back in Australia next week
and will look at it then.

Robert Jongbloed
OPAL/OpenH323/PTLib Architect and Co-founder.
 
 
> -----Original Message-----
> From: Vyacheslav Frolov [mailto:v.f...@or...]
> Sent: Wednesday, May 12, 2010 8:04 AM
> To: Robert Jongbloed
> Cc: opa...@li...
> Subject: Re: [Opalvoip-devel] Bug in ASN parser?
> 
> > fields "version" and "t38FaxRateManagement" are not marked as OPTIONAL,
> even
> > if they are in the extensions, they MUST be given values even if they
> are
> > not present.
> 
> For "not present" the Rec. ITU-T H.245 (06/2008) says:
> 
>                     -- The default Data Rate Management is
>                     -- determined by the choice of
>                     -- DataProtocolCapability
> 
> so for
> 
>    t38FaxProtocol = udp <<null>>
> 
> it should be
> 
>    t38FaxRateManagement = transferredTCF <<null>>
> 
> It should NOT be localTCF!
> 
> > Wireshark is technically in error here
> 
> IMO Wireshark is correct here because the Rec. ITU-T H.245 (09/98) does
> not define any extensions:
> 
>   T38FaxProfile ::=SEQUENCE
>   {
>     fillBitRemoval BOOLEAN,
>     transcodingJBIG BOOLEAN,
>     transcodingMMR BOOLEAN,
>     :
>   }
> 
> Wireshark just follows to early version of specification w/o any
> assumptions
> about default values.
> 
> > So, other than the display of the non-OPTIONAL extension fields, was
> there
> > any actual problem?
> 
> It's not a problem till we ignore t38FaxRateManagement value.
> 
> 
> 
> 
> Robert Jongbloed wrote:
> 
> >>-----Original Message-----
> >>From: Vyacheslav Frolov [mailto:v.f...@or...]
> >>Sent: Thursday, 22 April 2010 2:31 AM
> >
> > ...
> >
> >>It seems there is a bug in the ASN parser.
> >
> >
> > I won't say it is impossible, but after some 4 or 5 years since the last
> bug
> > in the ASN code, I have my doubts that there is any problem.
> >
> >
> >>----------------------------------------------------------
> >>T38FaxProfile       ::=SEQUENCE
> >>{
> >>    fillBitRemoval  BOOLEAN,
> >>    transcodingJBIG BOOLEAN,
> >>    transcodingMMR  BOOLEAN,
> >>    ...,
> >>    version     INTEGER (0..255),
> >>                    -- Version 0, the default, refers to
> >>                    -- T.38 (2005)
> >>    t38FaxRateManagement    T38FaxRateManagement,
> >>                    -- The default Data Rate Management is
> >>                    -- determined by the choice of
> >>                    -- DataProtocolCapability
> >>    t38FaxUdpOptions    T38FaxUdpOptions OPTIONAL,
> >>                    -- For UDP, t38UDPRedundancy is the default
> >>    t38FaxTcpOptions    T38FaxTcpOptions OPTIONAL
> >>}
> >>----------------------------------------------------------
> >>
> >>it parses 0x10 to
> >>
> >>----------------------------------------------------------
> >>            t38FaxProfile = {
> >>              fillBitRemoval = false
> >>              transcodingJBIG = false
> >>              transcodingMMR = true
> >>              version = 0
> >>              t38FaxRateManagement = localTCF (NULL)
> >>            }
> >>----------------------------------------------------------
> >
> >
> > This is in fact correct.
> >
> >
> >>but it should be
> >>
> >>----------------------------------------------------------
> >>            t38FaxProfile = {
> >>              fillBitRemoval = false
> >>              transcodingJBIG = false
> >>              transcodingMMR = true
> >>            }
> >>----------------------------------------------------------
> >
> >
> > I could go through the intricate details of the specification, but as
> the
> > fields "version" and "t38FaxRateManagement" are not marked as OPTIONAL,
> even
> > if they are in the extensions, they MUST be given values even if they
> are
> > not present.
> >
> >
> >>See wireshark's shapshot and opal's trace.
> >
> >
> > Wireshark is technically in error here, though I think I agree with
> their
> > decision to not show fields that are not present. It is less confusing
> to
> > viewers of the data.
> >
> >
> > So, other than the display of the non-OPTIONAL extension fields, was
> there
> > any actual problem?
> >
> >
> > Robert Jongbloed
> > OPAL/OpenH323/PTLib Architect and Co-founder.
> >
> >
> > ------------------------------------------------------------------------
> ------
> > _______________________________________________
> > Opalvoip-devel mailing list
> > Opa...@li...
> > https://lists.sourceforge.net/lists/listinfo/opalvoip-devel
> >
> 
> 
> **************************************************************************
> *****************************
> Это сообщение и любые вложения являются конфиденциальными и
> предназначенными исключительно для адресатов.
> Любое неуполномоченное использование или распространение запрещено.
> Сообщения могут быть изменены. Компания Orange Business Services не несёт
> ответственности за изменение или фальсификацию
> сообщений. Если Вы не являетесь получателем данного сообщения, пожалуйста
> сообщите об этом отправителю
> и удалите это сообщение.
> **************************************************************************
> *****************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. Orange Business Services shall not
> be liable for the message if altered, changed or
> falsified. If you are not the intended addressee of this message, please
> cancel it immediately and inform
> the sender.
> **************************************************************************
> *****************************