H323 version labeling - FW: h323 Annex E support

Paul E. Jones paulej at PACKETIZER.COM
Fri Jan 11 01:27:43 EST 2002


Terry,

The problem with this is simply that we will sacrifice backward
compatibility if the Implementers Guides are not adopted by vendors who ship
"3.0" equipment.

You are correct that matching the IG with the release of H.323 is a
potential source of confusing.  That is one reason I have that information
in a clear table on Packetizer.  Of course, having the same information
somewhere on the ITU site would be better, but they don't really have a good
place to keep that data.  However, I have not seen too many instances of
this kind of problem and vendors working with H.323 usually learn about the
IG pretty quickly.  (Though, I will admit, that I have seen it happen one
time.)

Paul

----- Original Message -----
From: "Lyons, Terry" <TLyons at SONUSNET.COM>
To: <ITU-SG16 at echo.jf.INTEL.COM>
Sent: Thursday, January 10, 2002 12:08 PM
Subject: H323 version labeling - FW: h323 Annex E support


> >  -----Original Message-----
> > From:         Lyons, Terry
> > Sent: Thursday, January 10, 2002 12:06 PM
> > To:   'imtch323implementors at mail.imtc.org';
ITU-SG16 at mailbag.cps.INTEL.COM
> > Cc:   Lyons, Terry
> > Subject:      H323 version labeling - FW: h323 Annex E support
> >
> > Maybe we should talk in terms of dot releases,
> > eg. v3.0 and v4.0 are the official ITU-T Recommendations
> > whereas v3.1 and v4.1 are the Implementers Guide changes.
> >
> > The need is to be clear about what H323 version an endpoint
> > conforms to or a protocol stack supports.  Calling different things,
> > eg. H323 (11/2000) and H323 IG (6/2001), by the same name "v4"
> > can lead to misunderstanding.
> >
> > - TLyons at sonusnet.com  +1 732 625-3003 ext 212
> >
> >
> > -----Original Message-----
> > From: Paul Long [mailto:plong at ipdialog.com]
> > Sent: Wednesday, January 09, 2002 12:19 PM
> > Subject: Re: h323 Annex E support
> >
> >
> > Paul,
> >
> > No, the concensus was that the IG is NOT normative because the ITU does
> > not
> > sanction its "normativeness" in any way, but it appears that we have
made
> > a
> > de facto decision to informally pretend that it is normative. I know for
> > sure that the H.324 IGs were NOT normative. In fact, the H.324 IG is
what
> > its name indicates--an actual guide for implementors, not an
corregendum,
> > which is what the H.323 IG really is (it's also an addendum, but that's
> > another issue altogether). I don't know about T.120 or H.320, but I'd be
> > willing to bet that their IGs, if they had any, were also NOT normative.
> >
> > Paul Long
> > ipDialog, Inc.
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > Sent: Wednesday, January 09, 2002 10:27 AM
> > To: Lyons, Terry
> > Cc: imtch323implementors at mail.imtc.org
> > Subject: [imtch323implementors] Re: h323 Annex E support
> >
> >
> > Terry,
> >
> > Arguably, the IG is not normative.  However, since the first day, ITU-T
> > SG16
> > has used the implementers guides as a normative texts.  This is done,
not
> > only with H.323, but also with T.120, H.320, H.324, etc.
> >
> > One could ignore the corrections applied to the IG, but doing so is
quite
> > dangerous.  You can't simply ignore the changes made via the IG, because
> > SG16 changes the ASN.1, not just add fields, and those changes will
appear
> > in the next revision of the Recommendations.  Of course, we try to limit
> > changes, but we usually do make a number of changes after the
> > Recommendation
> > is first approved and people start to finding problems.  There are no
> > plans
> > to change the v4 syntax any further-- and I will fight any change-- but
> > you
> > can see the history of changes made for v4 on Packetizer.  The last
> > approved
> > change was June 2001, yet the Recommendation was approved in November
> > 2000.
> >
> > It would be nice if we could first get implementations and then approve
> > the
> > Recommendation in a more solid state.  Unfortunately, that's not
possible
> > for several reasons:
> >   1) Companies do not want to spend engineering resources on a moving
> > target
> >   2) The standards work is usually way ahead of implementation
> >   3) No matter how hard we try, there's likely to be something we miss
> >   4) This is the way it has always been done-- tradition is hard to
change
> >
> > I presently have no intent to move the IG to series of amendments.  We
> > have
> > been using this approach for 5 years with good results.  Changing the
text
> > would require drafting a number of different documents and that process
is
> > also subject to error.  I'm not opposed to it, but I doubt we'll find
the
> > volunteers to write all of the amendments: it's boring, non-rewarding
> > work.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Lyons, Terry" <TLyons at sonusnet.com>
> > To: "'Paul E. Jones'" <paulej at packetizer.com>; "Lyons, Terry"
> > <TLyons at sonusnet.com>
> > Cc: <imtch323implementors at mail.imtc.org>
> > Sent: Wednesday, January 09, 2002 9:47 AM
> > Subject: RE: h323 Annex E support
> >
> >
> > > We all recognize, don't we, that the Implementers Guide
> > > is not a normative ITU Recommendation.  The way that the ITU
> > > changes things is through an amendment or subsequent edition.
> > > I believe there was some discussion of just this point in the past.
> > >
> > > The IG is best understood as a indication of what is coming next.
> > > The correct statment is that the fields are in v4, not v3.
> > >
> > > - TLyons at sonusnet.com  +1 732 625-3003 ext 212
> > >
> > >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > > Sent: Tuesday, January 08, 2002 11:44 PM
> > > To: Lyons, Terry
> > > Cc: imtch323implementors at mail.imtc.org
> > > Subject: Re: h323 Annex E support
> > >
> > >
> > > Terry,
> > >
> > > They were added to H.323v3 via the H.323 Implementers Guide approved
in
> > > November 2000.
> > >
> > > Paul
> > >
> > > ----- Original Message -----
> > > From: "Lyons, Terry" <TLyons at sonusnet.com>
> > > To: "'Paul E. Jones'" <paulej at packetizer.com>
> > > Cc: <imtch323implementors at mail.imtc.org>
> > > Sent: Tuesday, January 08, 2002 11:12 AM
> > > Subject: RE: h323 Annex E support
> > >
> > >
> > > > Hmmm ... the fields are NOT in the ITU publication H.225.0(09/99)
> > > > nor in the "Draft H.323 Core Document" H.225.0 Version 3 tabulated
at
> > > > http://www.packetizer.com/iptel/h323/
> > > > which links to
> > > >
> > >
> >
ftp://standard.pictel.com/avc-site/till_0012/9909_Gen/h225v3_decided_wcm_9
> > 90
> > > > 930
> > > >
> > > > Endpoint ::= SEQUENCE
> > > > {
> > > > nonStandardData NonStandardParameter OPTIONAL,
> > > > aliasAddress SEQUENCE OF AliasAddress OPTIONAL,
> > > > callSignalAddress SEQUENCE OF TransportAddress
> > > > OPTIONAL,
> > > > rasAddress SEQUENCE OF TransportAddress
> > > > OPTIONAL,
> > > > endpointType EndpointType OPTIONAL,
> > > > tokens SEQUENCE OF ClearToken OPTIONAL,
> > > > cryptoTokens SEQUENCE OF CryptoH323Token
> > > > OPTIONAL,
> > > > priority INTEGER(0..127) OPTIONAL,
> > > > remoteExtensionAddress SEQUENCE OF AliasAddress OPTIONAL,
> > > > destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL,
> > > > ...
> > > > }
> > > >
> > > > - TLyons at sonusnet.com  +1 732 625-3003 ext 212
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > > > Sent: Tuesday, January 08, 2002 12:56 AM
> > > > Subject: RE: h323 Annex E support
> > > >
> > > >
> > > > C. S.,
> > > >
> > > > Those fields are also in v3.  See the ASN.1 file here:
> > > > http://www.packetizer.com/iptel/h323/h2250v3.asn
> > > >
> > > > As for how a v2 device will work, Annex E describes how the endpoint
> > may
> > > > initiate a call with Annex E and then fall back to TCP if it is
> > determined
> > > > that Annex E is not supported.  Of course, this is less efficient in
> > terms
> > > > of call setup time, so using the v3/v4 fields are preferred.
> > > >
> > > > Paul
> > > >
> > > > ----- Original Message -----
> > > > From: <subbac at hss.hns.com>
> > > > To: "Paul, Manoj" <mpaul at trillium.com>
> > > > Cc: <imtch323implementors at mail.imtc.org>
> > > > Sent: Monday, January 07, 2002 3:48 AM
> > > > Subject: [imtch323implementors] RE: h323 Annex E support
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi paul,
> > > > >
> > > > > These "alternateTransportAddress" and "useSpecifiedTransport"
fields
> > are
> > > > > present in h323V4.
> > > > >
> > > > > In Case of H323V3 how to mention.
> > > > >
> > > > > regards
> > > > > C. S. Rao
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Paul, Manoj" <mpaul at trillium.com> on 01/07/2002 01:49:59 PM
> > > > >
> > > > > To:   Subbarao Chanduri/HSSBLR, imtch323implementors at mail.imtc.org
> > > > > cc:
> > > > >
> > > > > Subject:  RE: [imtch323implementors] h323 Annex E support
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Rao:
> > > > >
> > > > >   GK can indicate it's Annex E transport addresses in
> > > > > "alternateTransportAddress"
> > > > > field. It also indicates in "useSpecifiedTransport" to use
TCP/Annex
> > E.
> > > > >
> > > > > -Manoj Paul
> > > > > Trillium Digital Systems (Intel).
> > > > >
> > > > > -----Original Message-----
> > > > > From: subbac at hss.hns.com [mailto:subbac at hss.hns.com]
> > > > > Sent: Monday, January 07, 2002 1:37 PM
> > > > > To: imtch323implementors at mail.imtc.org
> > > > > Cc: subbac at hss.hns.com
> > > > > Subject: [imtch323implementors] h323 Annex E support
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > If  Gatekeeper supports  H323 Annex E.
> > > > > inresponse to Admission Request from an endpoint,
> > > > > through ACF, how gatekeeper informs the endpoint  that it is
> > listening
> > > on
> > > > > two different Transport Addresses.
> > > > >      i.e. one transport address (TA1) for Annex E messages.
> > > > >                        other transport Address (TA2) for TCP
> > messages.
> > > > >
> > > > > As there is only one field in ACF to indicate the destination call
> > > > > signalling address, how endpoint come to know
> > > > > about the different addresses GK is listening.
> > > > >
> > > > >
> > > > > regards
> > > > > C. S. Rao
>



More information about the sg16-avd mailing list