H323 version labeling - FW: h323 Annex E support
Lyons, Terry
TLyons at SONUSNET.COM
Thu Jan 10 12:08:08 EST 2002
> -----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