(Apologies if you've already received this. It didn't bounce off the reflector to me, so I'm sending it again.)
Karl,
I agree that adding yet another calling-party-number field is not a good thing, but neither Glen's nor your most recent proposal takes into consideration that the octet-3 extension bit "_shall_ be set to '1'" at least for v1 and v2. Therefore, octet 3a can never be sent to a v1 or v2 EP. Any solution will have to take this into account. Mine does. There may be others. One could clarify perhaps ambiguous parts of a revision, but you can't go back and fundamentally change the rules simply by adding words to the Implementers Guide. Compliant products are already shipping that do not expect octet 3a to be present, because the Recommendation says that it can't be present. To change the rules at this point would at the very minimum be quite unfair.
Note: I'm not real familiar with the ITU standards-making process, but I don't think that agreement at the SG meeting in Monterey even constitutes Determination. These SG meetings are part of the iterative refinement of a draft Recommendation before submitting it to the Working Party. Although maybe not officially part of the ITU standards-making process, this email reflector is vital in exposing the process to a wider audience than those that attended the meetings. Besides, even if Decided for H.225.0v3, Glen's proposed "fix" can only be applied between v3 EPs, so a v3 EP employing it would have to determine the version of the remote EP before it sent SETUP (which would be quite a trick). If the remote is v1 or v2, it can't set the extension bit of octet 3 in the calling party number IE to 0.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Karl.Klaghofer@ICN.SIEMENS.DE mailto:Karl.Klaghofer@ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] mailto:[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, May 12, 1999 4:44 AM To: ITU-SG16@MAILBAG.INTEL.COM mailto:ITU-SG16@MAILBAG.INTEL.COM
Subject: AW: caller ID and implementer's guide
Paul,
We have already two elements in H.225.0 that carry Calling party number information: - Calling Party Number Information Element, and - sourceAddress in Setup-UUIE. I would prefer a solution that avoids introducing a third element.
You have agreed that an "comliant" EP that receives an octet 3a in Calling party number from a "non-compliant" EP shall: - ignore the complete information element - shall process the rest of the message - shall not clear the call - optionally send STATUS (which we might exclude, due to the argument mentioned by Chris Sharp)
Based on these rules, I have derived a procedure that allows exceptional CLIR Interworking support in H.225.0v2(v1), which should go to the implementors guide. How about this ? ( Note: I understand that for H.323v3 (H.225.0v3) the proposal as presented by Glen Freundlich in Monetrey was accepted).
" Exceptional procedures for H.225.0v2(v1) Interworking with SCN CLIR "Calling Line Identification Restriction" feature:
1) Sending of Calling Party Number Information Element with CLIR information: In order to enable interworking with the SCN Calling Line Identification Restriction (CLIR) feature, an endpoint (e.g. terminal or incoming gateway) may include an octet 3a containing "Presentation Indicator" and "Screening Indicator" fields, but only if presentation at the destination is to be restricted. The presentation Indicator field in this case shall be set to "01" (Presentation restricted). If octet 3a is included, the extension bit in octet 3 bit 8 shall be set to "0". For the coding of Calling Party Number IE octet 3a refer also to Q.931 clause 4.5.10. The sourceAddress field should not be present.
If presentation is to be allowed, octet 3a shall NOT be included in the Calling Party Number Information Element.
2) Receiving Calling Party Number IE including CLIR information:
An EP that receives a Calling Party Number Information element including octet 3a with "presentation restriction" shall act as follows: 2a) If the EP supports the CLIR extensions as defined in 1) above, it shall NOT display the Calling Party Number to the user (the Calling party Number may be stored and e.g. used inconjunction with supplementary services). Additional identification information received within sourceAddress in Setup-UUIE shall NOT be displayed to the user as well. If the called endpoint is not trusted, the gatekeeper may remove a Calling Party Number IE containing CLIR indication before passing the SETUP message to the called endpoint.
2b) An EP that does not support the exceptional procedure for CLIR support as mentioned in 1) above, which receives a Calling Party Number Information Element with octet 3 bit 8 NOT set to "1" but set to "0" (i.e. octet 3a present) shall: - ignore the complete Calling Party Number Information element and - process the rest of the SETUP message (i.e. this "optional information element content error" shall not lead to call clearing). - A STATUS message (as recommended in Q.931 for such a situation) should not be sent. "
Regards, Karl