Pathological bearer cap changes in H.225.0v3

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Tue Sep 7 13:58:22 EDT 1999


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 at ICN.Siemens.com
------------------------------------------------------------------


-----Original Message-----
From: Paul Long [mailto:plong at SMITHMICRO.COM]
Sent: Tuesday, September 07, 1999 1:08 PM
To: ITU-SG16 at 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.



More information about the sg16-avd mailing list