Deficiency in Annex M, specifically M.2?

[Francois Audet]

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 at 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 at 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 at cisco.com OR deskenaz at cisco.com
> > Cisco Systems  ..::|::..::|::..  919-472-3891
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>
> --
> Daniel Eskenazi   .|.    .|.     dve at cisco.com OR deskenaz at cisco.com
> Cisco Systems  ..::|::..::|::..  919-472-3891
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000707/b349a97d/attachment-0004.html>