Issues with H.235

[Pete Cordell]

Paul,

Your logic is correct.

I only attempted to provide you with a summary of the discussion in
Santiago.

There were a number of IEs that forbidden that were to be added in Berlin.
This, in part, came about from one possible solution for transporting QSIG
over H.323.  Because there was no resolution to the primary question, the IE
change was not accepted.  This question is scheduled to return at Red Bank.
That would be a good chance for your opinion to be heard.  The worst case is
that everything forbidden will be possible.

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 3:13 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Pathological bearer cap changes in H.225.0v3


Bob,

1. But there has never been a requirement that components of IEs be treated
like actual IEs. Where did this come from? This is a gross rationalization.
The Recommendation clearly states that this octet shall not be encoded.
Therefore, it is perfectly reasonable for an entity to assume that it will
never encounter this octet. Geez, what are standards for? What other
"shalls" will be relaxed in the future?

2. Even if IE components were to be treated like IEs--which they
cannot--this would still not justify the removal of this requirement.
H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not
that well-known but otherwise clearly prohibited ones shall be ignored,
which is what you are proposing.

But please prove me wrong. Show me in the H.225.0 Recommendation where it
says that 1. IE components, such as Octet 3a of bearer caps, shall be
treated like IEs and 2. that well-known but otherwise prohibited IEs shall
be ignored.

BTW, our products in particular are okay in this regard--they will ignore
optional IE fields, even the ones that are prohibited--so I'm not simply
trying rationalize something to keep our products from becoming
non-interoperable due to a bad design decision. It's just that I don't like
the precedent this sets that it's okay to "change the rules once the game
has started." I won't go on about this, though. I'm done.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Callaghan, Robert [mailto:Robert.Callaghan at ICN.SIEMENS.COM]
Sent: Tuesday, September 07, 1999 12:58 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: Pathological bearer cap changes in H.225.0v3


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.