Daniel,
Non-ITU variants can have OIDs that are defined by the controlling body.
OID for non-ITU variants should not be defined by the ITU. It is too easy
to omit one and then there is a problem.
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan(a)ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
Sent: Friday, July 07, 2000 3:40 PM
To: Francois Audet
Cc: Callaghan, Robert; 'Mailing list for parties associated with ITU-T
Study Group 16'; paulej(a)cisco.com
Subject: Re: Deficiency in Annex M, specifically M.2?
Hi Francois,
Are you saying that even if the OID hierarchy is underneath
ITU H 225, it is still not advisable to enumerate non-ITU variants?
I am not very knowledgeable about OID manners so I didn't realize
this is frowned upon.
Regarding variants for QSIG, I suppose you could have a complicated
OID hierarchy underneath Annex M (1) that lists the version for each
functional area (basic call, generic protocol, supp services, etc).
There's no reason the hierarchy can't be different underneath each
Annex M protocol, is there?
My original concern was for ISUP - I take it the ability to
discriminate version(s) is important for QSIG as well?
Thanks,
Daniel Eskenazi
> Francois Audet wrote:
>
> I don't think you want to use the ITU OID for ISUP
> when using, for example, the North American variant.
>
> An aditional problem is that there is no such thing as a version for
> QSIG. You have versions for basic call control, and another version
> for the
> generic functional protocol, others for individual supplementary
> services.
> I'm not sure how to solve that.
>
> > -----Original Message-----
> > From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
> > Sent: Friday, July 07, 2000 12:02 PM
> > To: Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH]
> > Cc: 'Mailing list for parties associated with ITU-T Study Group 16';
>
> > paulej(a)cisco.com
> > Subject: Re: Deficiency in Annex M, specifically M.2?
> >
> >
> >
> > Bob (and Francois, who also mentioned the same thing),
> >
> > Agreed, this would work too, and I'm not opposed
> > to that solution. My thinking was that adding the
> > new fields would be slightly easier for implementors,
> > since an endpoint that is interested in tunneling,
> > for example, all ISUP variants but no QSIG variants can
> > easily determine that the tunneled data is ISUP rather
> > than QSIG just by matching the hard-coded ISUP OID,
> > without having to "parse" the OID. On the other hand,
> > the OID approach has the advantage of not requiring any
> > ASN.1 changes.
> >
> > But even with OID approach, Annex M.2 (and potentially M.1) need
> > minor chang(es), since they are hard-coded to indicate a single
> > OID value for QSIG or ISUP. We would need to define a new
> > OID hierarchy for specifying Annex-M Protocol/Variant/Version,
> > and refer to the OID hierarchy from within Annex-M.2(and
> > possibly M.1). Agreed?
> >
> > Thanks,
> >
> > Daniel Eskenazi
> >
> > "Callaghan, Robert" wrote:
> > >
> > > Daniel,
> > >
> > > This problem can also be solved by having different Object
> > Ids for each
> > > variant of ISUP.
> > >
> > > Bob
> > >
> > >
> > --------------------------------------------------------------
> > --------------
> > > -----------------------------
> > >
> > > Hi Jan,
> > >
> > > Annex M.2 does not seem to provide any standard mechanism for
> > > specifying the variant of ISUP that is being tunneled.
> > Therefore ISUP
> > > tunneling as currently defined in Annex M.2 will only work
> properly
> > > if both H.323 endpoints are connected to ISUP equipment using the
> > > exact same type and version of ISUP. Do you agree?
> > >
> > > Assuming that I didn't miss something and this is a valid
> > > concern, the addition of type and version fields would solve
> > > this problem. I believe Protocol type and version information
> > > would be universally useful for all tunneled protocols, so I
> > > propose that the tunneledSignallingMessage construct be enhanced
> > > to provide fields for protocolType (or maybe it should be called
> > > protocolVariant?) and protocolVersion; exact format TBD.
> > >
> > > Any comments?
> > >
> > > Thanks,
> > >
> > > --
> > > Daniel Eskenazi .|. .|. dve(a)cisco.com OR
> deskenaz(a)cisco.com
> > > Cisco Systems ..::|::..::|::.. 919-472-3891
> > >
> > >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv(a)mailbag.intel.com
> >
> > --
> > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
>
> > Cisco Systems ..::|::..::|::.. 919-472-3891
> >
--
Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
Cisco Systems ..::|::..::|::.. 919-472-3891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
