No subject

[Dave Walker]

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
the
> version of protocol being used by the sender of the PDU? Also, how does
the
> sender ascertain which version of protocol the receiver understands? e.g.
if
> 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
would
> 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
from
> 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
decoded;
> 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 vocaltec.com      Tel: 972 9 9707768      Fax: 972 9 9561867