Paul,
The question you present was covered in Santiago.
The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem).
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3
I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept?
Paul Long Smith Micro Software, Inc.