Deficiency in Annex M, specifically M.2?

[Daniel Eskenazi]

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