No subject

Dave Walker Dave_Walker at MITEL.COM
Mon Jan 17 15:54:20 EST 2000

Hi Krishna,

See my answers below...

> Hi ..!!
> I have a few queries regarding H.225.0 RAS/AnnexG:
> 1. AnnexGCommonInfo does not contain Protocol Identifier. Why is it not
> required for AnnexG messages?
>    Keeping in view, the possible future versions of AnnexG; how shall a
> Border Element, on receiving a PDU from some other Border Element know
> version of protocol being used by the sender of the PDU? Also, how does
> sender ascertain which version of protocol the receiver understands? e.g.
> an element is added in version 3 of the protocol, and the recepient can
> handle upto version 7, how can it be ascertained that the peer entity
> understand the information sent/received?

Actually, Annex G does has a Protocol Identifier - it is the "version"
field that
is part of the common message info and is included in every message:

AnnexGCommonInfo ::= SEQUENCE
     sequenceNumber INTEGER (0..65535),
     version        AnnexGVersion,
     hopCount       INTEGER (1..255),
     replyAddress        SEQUENCE OF TransportAddress OPTIONAL, -- Must be
present in request
     integrityCheckValue ICV OPTIONAL,
     tokens              SEQUENCE OF ClearToken OPTIONAL,
     cryptoTokens        SEQUENCE OF CryptoH323Token OPTIONAL,
     nonStandard         SEQUENCE OF NonStandardParameter OPTIONAL,
     serviceID           ServiceID   OPTIONAL

In the first version of Annex G, it is defined as:

AnnexGVersion       ::=  OBJECT IDENTIFIER
                    -- shall be set to
                    -- {itu-t (0) recommendation (0) h(8) 2250 annex (1) g
(7) version (0) 1}

> 2. Why is Sequence Number from 0 to 65535 for AnnexG, while for RAS its
> 1 to 65535 (ASN.1 Message Syntax)?
>    Also, in section 7.17 (Message Not Understood) of H.225.0 it is
>mentioned that RequestSeqNum shall be zero if the message cannot be
> PDU encoding shall fail in such a case.

You're right. I am guessing that nobody ever noticed the discrepancy
between H.225.0 (RAS)
and Annex G. From the section you quote (H.225.0, section 7.17)),
specifying the sequence number to zero
seems to be a bug in the standard, since it defines the sequence number as:

RequestSeqNum       ::= INTEGER (1..65535)

> Regards
> Krishna

Michael Fortinsky
Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd.
Email: mike at      Tel: 972 9 9707768      Fax: 972 9 9561867

More information about the sg16-avd mailing list