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@ICN.Siemens.com ------------------------------------------------------------------

-----Original Message----- From: Daniel Eskenazi [mailto:deskenaz@cisco.com] Sent: Friday, July 07, 2000 3:02 PM To: Callaghan, Robert; audet@nortelnetworks.com Cc: 'Mailing list for parties associated with ITU-T Study Group 16'; paulej@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@cisco.com OR deskenaz@cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891

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

-- Daniel Eskenazi .|. .|. dve@cisco.com OR deskenaz@cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891

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