<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: Deficiency in Annex M, specifically M.2?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>I don't think you want to use the ITU OID for ISUP</FONT>
<BR><FONT SIZE=2>when using, for example, the North American variant.</FONT>
</P>
<P><FONT SIZE=2>An aditional problem is that there is no such thing as a version for</FONT>
<BR><FONT SIZE=2>QSIG. You have versions for basic call control, and another version for the</FONT>
<BR><FONT SIZE=2>generic functional protocol, others for individual supplementary services.</FONT>
<BR><FONT SIZE=2>I'm not sure how to solve that.</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Daniel Eskenazi [<A HREF="mailto:deskenaz@cisco.com">mailto:deskenaz@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, July 07, 2000 12:02 PM</FONT>
<BR><FONT SIZE=2>> To: Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH]</FONT>
<BR><FONT SIZE=2>> Cc: 'Mailing list for parties associated with ITU-T Study Group 16';</FONT>
<BR><FONT SIZE=2>> paulej@cisco.com</FONT>
<BR><FONT SIZE=2>> Subject: Re: Deficiency in Annex M, specifically M.2?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Bob (and Francois, who also mentioned the same thing),</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Agreed, this would work too, and I'm not opposed</FONT>
<BR><FONT SIZE=2>> to that solution. My thinking was that adding the </FONT>
<BR><FONT SIZE=2>> new fields would be slightly easier for implementors,</FONT>
<BR><FONT SIZE=2>> since an endpoint that is interested in tunneling,</FONT>
<BR><FONT SIZE=2>> for example, all ISUP variants but no QSIG variants can</FONT>
<BR><FONT SIZE=2>> easily determine that the tunneled data is ISUP rather</FONT>
<BR><FONT SIZE=2>> than QSIG just by matching the hard-coded ISUP OID, </FONT>
<BR><FONT SIZE=2>> without having to "parse" the OID. On the other hand,</FONT>
<BR><FONT SIZE=2>> the OID approach has the advantage of not requiring any</FONT>
<BR><FONT SIZE=2>> ASN.1 changes.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> But even with OID approach, Annex M.2 (and potentially M.1) need</FONT>
<BR><FONT SIZE=2>> minor chang(es), since they are hard-coded to indicate a single</FONT>
<BR><FONT SIZE=2>> OID value for QSIG or ISUP. We would need to define a new</FONT>
<BR><FONT SIZE=2>> OID hierarchy for specifying Annex-M Protocol/Variant/Version,</FONT>
<BR><FONT SIZE=2>> and refer to the OID hierarchy from within Annex-M.2(and </FONT>
<BR><FONT SIZE=2>> possibly M.1). Agreed?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Thanks,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Daniel Eskenazi</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> "Callaghan, Robert" wrote:</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Daniel,</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > This problem can also be solved by having different Object </FONT>
<BR><FONT SIZE=2>> Ids for each</FONT>
<BR><FONT SIZE=2>> > variant of ISUP.</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Bob</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> --------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> --------------</FONT>
<BR><FONT SIZE=2>> > -----------------------------</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Hi Jan,</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Annex M.2 does not seem to provide any standard mechanism for</FONT>
<BR><FONT SIZE=2>> > specifying the variant of ISUP that is being tunneled. </FONT>
<BR><FONT SIZE=2>> Therefore ISUP</FONT>
<BR><FONT SIZE=2>> > tunneling as currently defined in Annex M.2 will only work properly</FONT>
<BR><FONT SIZE=2>> > if both H.323 endpoints are connected to ISUP equipment using the</FONT>
<BR><FONT SIZE=2>> > exact same type and version of ISUP. Do you agree?</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Assuming that I didn't miss something and this is a valid</FONT>
<BR><FONT SIZE=2>> > concern, the addition of type and version fields would solve</FONT>
<BR><FONT SIZE=2>> > this problem. I believe Protocol type and version information</FONT>
<BR><FONT SIZE=2>> > would be universally useful for all tunneled protocols, so I</FONT>
<BR><FONT SIZE=2>> > propose that the tunneledSignallingMessage construct be enhanced</FONT>
<BR><FONT SIZE=2>> > to provide fields for protocolType (or maybe it should be called</FONT>
<BR><FONT SIZE=2>> > protocolVariant?) and protocolVersion; exact format TBD.</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Any comments?</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Thanks,</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > --</FONT>
<BR><FONT SIZE=2>> > Daniel Eskenazi .|. .|. dve@cisco.com OR deskenaz@cisco.com</FONT>
<BR><FONT SIZE=2>> > Cisco Systems ..::|::..::|::.. 919-472-3891</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT>
<BR><FONT SIZE=2>> > For help on this mail list, send "HELP ITU-SG16" in a message to</FONT>
<BR><FONT SIZE=2>> > listserv@mailbag.intel.com</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- </FONT>
<BR><FONT SIZE=2>> Daniel Eskenazi .|. .|. dve@cisco.com OR deskenaz@cisco.com</FONT>
<BR><FONT SIZE=2>> Cisco Systems ..::|::..::|::.. 919-472-3891</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>