Re: caller ID and implementer's guide
Paul,
If we're going to standardise it, why should it be nonStandard? In other words, if it is considered an important thing to add, and it is considered impossible to include it in its original place (on which I express no opinion), then it should be added to the standard as an information element in the H.225.0 message, not put in a standard bit of non-standard information. If my reading of the ASN.1 is correct, and we were to follow your suggestion, it would be impossible to transmit a setup message with the addition you propose and also a non-standard parameter of my own devising (unless, of course, I could persuade Smith Micro to "like" my non-standard information and put it in their private non-standard parameter) - and I am sure this would be unacceptable to many.
Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com
-----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: 08 May 1999 3:22 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide
Karl,
It may have been a mistake to exclude octet 3a, but it is far too late to "fix" this through its inclusion. H.323 is not merely an academic work that is forever in progress, with no real repercussions if we change it. Compliant products have been shipped according to what is written in the H.323 Recommendation. Moreover, because an EP cannot determine the H.323 version of the remote EP before sending its SETUP, octet 3a must forever be excluded in H.323.
Here is a way we can maintain H.323's integrity and provide the apparently much needed information in octet 3a. Carry the value for octet 3a in H323-UU-PD.nonStandardData. Have boundary entities between the packet network and the SCN move this value between the real octet 3a on the SCN side and the octet-3a proxy on the packet side. Smith Micro would "donate" our H.221 identifier, but we could use anyone's. The nonStandardData.data octet string would hold an ASN.1 encoding of this type:
H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE { callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL, ... }
Practically speaking, if h323-message-body is setup, h323-uu-pdu.nonStandardData is present, h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard, h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStand ard is {181, 0, 30324}, and bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1 (callingPartyNumberIEOctet3a is present), then h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a.
Note that, according to ASN.1 PER aligned encoding, bits 6 through 1 of h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit 8 indicates whether other, TBD components are present that are not in the root extension. This allows us to provide other info in the future if needed.
This is what H323-UU-PD.nonStandardData would typically be set to: { h221NonStandard { 181, 0, 30324 }, -- Smith Micro's H.221 identifier { 64, x } -- x is octet 3a from calling party number information element }
This is similar to an H.324 fix, so there is precedent for this sort of thing.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Karl.Klaghofer@ICN.SIEMENS.DE[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, May 07, 1999 3:43 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide
Glen and others, It was a mistake to exclude the octet 3a in H.225.0(v1 and v2) Calling party number IE. It has led to interoperability problems with the SCN in the past (where octet 3a is used) ! Now, it is time to fix this error as discussed in the Monterey Rapporteuts meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via Implementors Guide !). There may be procucts already planning on that announced correction.
An endpoint B - not supporting octet 3a of CallingParty Number Information element - should treat this situation as a "non-mandatory information element content error". The reaction to such an type of error shall be: * Take actions on the SETUP received and on all the information elements that are recognized and have valid contents; i.e. ignore only the Calling party Number IE * A STATUS may optionally be returned with Cause #100.
Refer also to Q.931 clause 5.8.7.2 (which shouldapplicable also to H.225.0, since H.225.0 is so much based on the Q.931).
So, if such an endpoint B receives an octet 3a inCalling party Number set to "presentation allowed", all that happens is that the Number would not be displayed at B. But for the really critical case where the octet 3a is received by such an endpoint B being set to "presentation restrictet", we have even the behavier we intend, namely NOT to display the number to the endpoint B (since the whole IE should be ignored anyway).
A miscoded optional Information element should never lead to aclearing of the call !
Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer@icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Glen Freundlich [SMTP:ggf@lucent.com] > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > An: ITU-SG16@mailbag.cps.intel.com > Betreff: caller ID and implementer's guide > > At the Monterey meeting we discussed thepossibility of an addition to > the Implementer's Guide to support caller ID features (APC-1527). > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > Number IE (and also specifies that the octet 3 extension bit shall be > set to 1). The proposal calls for removing the restriction through the > Implementer's Guide. (See also the meeting report in APC-1554b.) > > Fixing this brings up the possibility of interoperability problems with > existing products. Please respond if you think this change will be a > problem. You can respond to me individually, rather than to the entire > list, if you prefer. > > Thanks, > Glen > > > -- > Glen Freundlich ggf@lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA
Paul, Chris, and others interested,
In APC-1527 of the Monterey meeting, I had proposed adding presentation and screening indicators in the ASN.1 definitions for several H.225/Q.931 messages. These were needed in the event the Calling Party Number IE is not used (e.g., when using an alias address that is not a telephone number). This would go into V3 and would seem to not create any interop problems among versions of H.225. It means waiting until V3, and may not be a good general fix to other potential inconsistencies between Q.931 and H.225, if they exist.
Glen
Chris Purvis wrote:
Paul,
If we're going to standardise it, why should it be nonStandard? In other words, if it is considered an important thing to add, and it is considered impossible to include it in its original place (on which I express no opinion), then it should be added to the standard as an information element in the H.225.0 message, not put in a standard bit of non-standard information. If my reading of the ASN.1 is correct, and we were to follow your suggestion, it would be impossible to transmit a setup message with the addition you propose and also a non-standard parameter of my own devising (unless, of course, I could persuade Smith Micro to "like" my non-standard information and put it in their private non-standard parameter) - and I am sure this would be unacceptable to many.
Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com
-----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: 08 May 1999 3:22 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide
Karl,
It may have been a mistake to exclude octet 3a, but it is far too late to "fix" this through its inclusion. H.323 is not merely an academic work that is forever in progress, with no real repercussions if we change it. Compliant products have been shipped according to what is written in the H.323 Recommendation. Moreover, because an EP cannot determine the H.323 version of the remote EP before sending its SETUP, octet 3a must forever be excluded in H.323.
Here is a way we can maintain H.323's integrity and provide the apparently much needed information in octet 3a. Carry the value for octet 3a in H323-UU-PD.nonStandardData. Have boundary entities between the packet network and the SCN move this value between the real octet 3a on the SCN side and the octet-3a proxy on the packet side. Smith Micro would "donate" our H.221 identifier, but we could use anyone's. The nonStandardData.data octet string would hold an ASN.1 encoding of this type:
H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE { callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL, ... }
Practically speaking, if h323-message-body is setup, h323-uu-pdu.nonStandardData is present, h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard, h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStand ard is {181, 0, 30324}, and bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1 (callingPartyNumberIEOctet3a is present), then h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a.
Note that, according to ASN.1 PER aligned encoding, bits 6 through 1 of h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit 8 indicates whether other, TBD components are present that are not in the root extension. This allows us to provide other info in the future if needed.
This is what H323-UU-PD.nonStandardData would typically be set to: { h221NonStandard { 181, 0, 30324 }, -- Smith Micro's H.221 identifier { 64, x } -- x is octet 3a from calling party number information element }
This is similar to an H.324 fix, so there is precedent for this sort of thing.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Karl.Klaghofer@ICN.SIEMENS.DE[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, May 07, 1999 3:43 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide
Glen and others, It was a mistake to exclude the octet 3a in H.225.0(v1 and v2) Calling party number IE. It has led to interoperability problems with the SCN in the past (where octet 3a is used) ! Now, it is time to fix this error as discussed in the Monterey Rapporteuts meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via Implementors Guide !). There may be procucts already planning on that announced correction.
An endpoint B - not supporting octet 3a of CallingParty Number Information element - should treat this situation as a "non-mandatory information element content error". The reaction to such an type of error shall be: * Take actions on the SETUP received and on all the information elements that are recognized and have valid contents; i.e. ignore only the Calling party Number IE * A STATUS may optionally be returned with Cause #100.
Refer also to Q.931 clause 5.8.7.2 (which shouldapplicable also to H.225.0, since H.225.0 is so much based on the Q.931).
So, if such an endpoint B receives an octet 3a inCalling party Number set to "presentation allowed", all that happens is that the Number would not be displayed at B. But for the really critical case where the octet 3a is received by such an endpoint B being set to "presentation restrictet", we have even the behavier we intend, namely NOT to display the number to the endpoint B (since the whole IE should be ignored anyway).
A miscoded optional Information element should never lead to aclearing of the call !
Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer@icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Glen Freundlich [SMTP:ggf@lucent.com] > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > An: ITU-SG16@mailbag.cps.intel.com > Betreff: caller ID and implementer's guide > > At the Monterey meeting we discussed thepossibility of an addition to > the Implementer's Guide to support caller ID features (APC-1527). > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > Number IE (and also specifies that the octet 3 extension bit shall be > set to 1). The proposal calls for removing the restriction through the > Implementer's Guide. (See also the meeting report in APC-1554b.) > > Fixing this brings up the possibility of interoperability problems with > existing products. Please respond if you think this change will be a > problem. You can respond to me individually, rather than to the entire > list, if you prefer. > > Thanks, > Glen > > > -- > Glen Freundlich ggf@lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA
-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
All,
I would agree with Chris that the nonStandardData field is not the most preferred place for the octet 3a information, although the suggested solution from Paul is appreciated.
Although I believe that endpoints that did not understand octet 3a should have ignored it, I think we can include octet 3a and adequately provide for backward compatibility if the new text for the H.323 v2 implementors' guide indicates that:
o Implementations that include octet 3a "must" provide a means to administratively disable its inclusion. o Implementations that do not understand octet 3a "should" ignore it.
Would this approach address the backward compatibility concerns? Would it place an undue burden on implementors who wish to include octet 3a?
To avoid propagating this error, text for H.323 v3 should reverse "must" and "should" in the above two bullets. For v3, the "reasonable period of time" requirement of WTSC-96 Resolution 1 will have been met, and implementors will have received a warning from the v2 implementors' guide assuming the above changes are included.
Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Chris Purvis wrote:
Paul,
If we're going to standardise it, why should it be nonStandard? In other words, if it is considered an important thing to add, and it is considered impossible to include it in its original place (on which I express no opinion), then it should be added to the standard as an information element in the H.225.0 message, not put in a standard bit of non-standard information. If my reading of the ASN.1 is correct, and we were to follow your suggestion, it would be impossible to transmit a setup message with the addition you propose and also a non-standard parameter of my own devising (unless, of course, I could persuade Smith Micro to "like" my non-standard information and put it in their private non-standard parameter) - and I am sure this would be unacceptable to many.
Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com
-----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: 08 May 1999 3:22 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide
Karl,
It may have been a mistake to exclude octet 3a, but it is far too late to "fix" this through its inclusion. H.323 is not merely an academic work that is forever in progress, with no real repercussions if we change it. Compliant products have been shipped according to what is written in the H.323 Recommendation. Moreover, because an EP cannot determine the H.323 version of the remote EP before sending its SETUP, octet 3a must forever be excluded in H.323.
Here is a way we can maintain H.323's integrity and provide the apparently much needed information in octet 3a. Carry the value for octet 3a in H323-UU-PD.nonStandardData. Have boundary entities between the packet network and the SCN move this value between the real octet 3a on the SCN side and the octet-3a proxy on the packet side. Smith Micro would "donate" our H.221 identifier, but we could use anyone's. The nonStandardData.data octet string would hold an ASN.1 encoding of this type:
H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE { callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL, ... }
Practically speaking, if h323-message-body is setup, h323-uu-pdu.nonStandardData is present, h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard, h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStand ard is {181, 0, 30324}, and bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1 (callingPartyNumberIEOctet3a is present), then h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a.
Note that, according to ASN.1 PER aligned encoding, bits 6 through 1 of h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit 8 indicates whether other, TBD components are present that are not in the root extension. This allows us to provide other info in the future if needed.
This is what H323-UU-PD.nonStandardData would typically be set to: { h221NonStandard { 181, 0, 30324 }, -- Smith Micro's H.221 identifier { 64, x } -- x is octet 3a from calling party number information element }
This is similar to an H.324 fix, so there is precedent for this sort of thing.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Karl.Klaghofer@ICN.SIEMENS.DE[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, May 07, 1999 3:43 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide
Glen and others, It was a mistake to exclude the octet 3a in H.225.0(v1 and v2) Calling party number IE. It has led to interoperability problems with the SCN in the past (where octet 3a is used) ! Now, it is time to fix this error as discussed in the Monterey Rapporteuts meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via Implementors Guide !). There may be procucts already planning on that announced correction.
An endpoint B - not supporting octet 3a of CallingParty Number Information element - should treat this situation as a "non-mandatory information element content error". The reaction to such an type of error shall be: * Take actions on the SETUP received and on all the information elements that are recognized and have valid contents; i.e. ignore only the Calling party Number IE * A STATUS may optionally be returned with Cause #100.
Refer also to Q.931 clause 5.8.7.2 (which shouldapplicable also to H.225.0, since H.225.0 is so much based on the Q.931).
So, if such an endpoint B receives an octet 3a inCalling party Number set to "presentation allowed", all that happens is that the Number would not be displayed at B. But for the really critical case where the octet 3a is received by such an endpoint B being set to "presentation restrictet", we have even the behavier we intend, namely NOT to display the number to the endpoint B (since the whole IE should be ignored anyway).
A miscoded optional Information element should never lead to aclearing of the call !
Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer@icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Glen Freundlich [SMTP:ggf@lucent.com] > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > An: ITU-SG16@mailbag.cps.intel.com > Betreff: caller ID and implementer's guide > > At the Monterey meeting we discussed thepossibility of an addition to > the Implementer's Guide to support caller ID features (APC-1527). > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > Number IE (and also specifies that the octet 3 extension bit shall be > set to 1). The proposal calls for removing the restriction through the > Implementer's Guide. (See also the meeting report in APC-1554b.) > > Fixing this brings up the possibility of interoperability problems with > existing products. Please respond if you think this change will be a > problem. You can respond to me individually, rather than to the entire > list, if you prefer. > > Thanks, > Glen > > > -- > Glen Freundlich ggf@lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA
participants (3)
-
Chris Purvis -
Glen Freundlich -
Rich Bowen