Re: Deficiency in Annex M, specifically M.2?
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@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
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@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 >
-- 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
participants (2)
-
Daniel Eskenazi -
Francois Audet