Deficiency in Annex M, specifically M.2?

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Fri Jul 7 16:31:01 EDT 2000


Daniel,

The problem in the past with defining variants of ISUP is that many variants
are controlled by national bodies.  This will make it hard to define these
in an ITU-T defined structure.   (But you are welcome to try.)

I have no problem changing the OID to a list of.

Bob

------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756    Fax: +1.561.923.1403
Email:  Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------

 -----Original Message-----
From:   Daniel Eskenazi [mailto:deskenaz at cisco.com]
Sent:   Friday, July 07, 2000 3:02 PM
To:     Callaghan, Robert; audet at nortelnetworks.com
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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list