[itu-sg16] !!!URGENT: Your Badge for Rapporteur meeting Geneva 21-23

Fri Oct 9 12:15:03 EDT 2009

Sasha,

I cannot disagree with you on this example.  Q.931 only addresses issues in
Q.931, but H.225.0 ought to address issues in the ASN.1.  Where there are
possible conflicts, we ought to make a clear statement.

H.323 only has a very small section on protocol error handling (8.6) and
would be a good place to expand.  It would be a good place to address any
general issues that might arise from H.225.0 and/or H.245.

H.225.0 would be a good place to expand on things specific to H.225.0,
though not necessarily in section 7.1, since we do also have to cover non
Q.931 error issues.

In general, though, H.225.0 does work a lot like Q.931, which is dictated by
the opening statement in 7.1 that reads "Implementations shall follow ITU-T
Q.931 as specified in this Recommendation."  This statement has led to
confusion over implementation of timers, error codes, etc. over the years.
While this statement exists, it's also important that developers recognize
that H.225.0 is not Q.931.  I've seen many diagrams that show H.245 and
"H.225.0/Q.931" as components of H.323, which is not accurate.

If we can reach agreement on specific text at this upcoming meeting, we
could clarify some issues in the v7 document.  If not, we can certainly
entertain an amendment to v7.  Do you have a list of similar issues and a
specific proposal?  One thing that concerns me, obviously, is  putting in
text of this nature at the last minute without wide review.  As such, I'd
really like to discuss specific proposals on this via the mailing list in
advance of the meeting to seek implementer input.  We might even want to
take this to the H.323 implementers list:
http://www.packetizer.com/ipmc/h323/lists.html

Paul

From: Sasha Ruditsky [mailto:sasha at radvision.com] 
Sent: Monday, October 05, 2009 2:31 PM
To: Paul E. Jones; itu-sg16 at lists.packetizer.com
Subject: RE: [itu-sg16] AVD-3813 Handling Of Error Conditions in H.323

Hi Paul,

Yes, I am looking for a Broader statement. 

Specifically, my problem is the fact that ETSI TS 101 804 - 2 defines
procedures referring to Q.931 sections.

Let consider one example from ETSI TS 101 804 - 2:

BCC_TE_S_U00_07 clause 5.8.6.1 [4]

Ensure that the IUT in the Null call state U0, on receipt of a SETUP message
with a mandatory information element

missing,

sends a RELEASE COMPLETE message containing a Cause information element
indicating the cause value 96

"mandatory information element missing" and remains in the Null call state
U0.

Which suggest to the reader that Q.931 section 5.8.6.1 (and some other
explicitly referenced sections) 

is the way H.323 should be implemented.

What I want to achieve is an explicit statement in H.323 or H.225.0, which
would say that this is not the case,

that these sections do not apply, instead. and here we do need to provide
something which would 

close the gap created by this unspecified Cause code value.

The problem to select such cause is stemmed from the fact that syntax of
Q.931 messages and syntax of 

H.225.0 messages are quite different.

Q.931 status codes cover syntax errors in Q.931 part of the message.
However, very significant part of the H.225.0 

is PER encoded, so "is the perfectly encoded Q.931 message with ASN.1 part
encoded incorrectly encoded correctly?" 

and should the response be STATUS and if STATUS then with which cause code?

I believe it does not make sense to respond to syntactical errors in Q.931
part and ignore such errors in ASN.1. 

On the other hand we did not have and do not have any fine grained
definition of what to do with different ASN.1 error cases 

and this most probably created the situation where different implementations
behave differently. 

BTW: In our implementation for example we use cause value 95: "Invalid
message, unspecified" for any syntactical mistake 

in any H.225.0 message. If somebody has a different approach, please share
with us!

So my ultimate goal is to make clear that H.323 is not working according to
ETSI TS 101 804 - 2 and at the same to create minimal 

possible impact on existing implementations. 

Regards,

Sasha

From: Paul E. Jones [mailto:paulej at packetizer.com] 
Sent: Friday, October 02, 2009 2:29 PM
To: Sasha Ruditsky; itu-sg16 at lists.packetizer.com
Subject: RE: [itu-sg16] AVD-3813 Handling Of Error Conditions in H.323

Sasha,

The fact that H.225.0 says a device shall send a Status message for an
unknown message, yet leaves the Cause code unspecified, is certainly an
issue we should close on.  My suggestion would be to use 97: "Message type
non-existent or not

Implemented."

I think an "unknown message" would be one that is not currently defined
today in H.225.0.  If the message is syntactically invalid, then I believe
that is a protocol error.  In that case, either 100 or 111 would be good
choices depending on whether it is just an invalid IE or something that is
impossible to decode.

Those are fairly minor changes, though the impact might be significant.
However, your problem description suggests you are looking for a broader
statement.  Do you have a specific proposal in mind, either a new paragraph
or section on error handling or a reference to Q.931?

Paul

From: itu-sg16-bounces at lists.packetizer.com
[mailto:itu-sg16-bounces at lists.packetizer.com] On Behalf Of Sasha Ruditsky
Sent: Wednesday, September 30, 2009 6:01 PM
To: itu-sg16 at lists.packetizer.com
Subject: [itu-sg16] AVD-3813 Handling Of Error Conditions in H.323

Q2 Experts,

The conclusion for the discussion of the AVD-3813 during the last SG16
meeting's was to ask the experts opinion through the mailing list.

My apology for the short notice. I hope that we still have time before the
next meeting for people to understand the problem and express their
opinions. 

The problem discussed in AVD 3813 is more or less as follows:

"

H.225.0 gives very little attention to the specification of processing of
the H.225.0 Call Signaling messages errors. The only place dedicated to this
subject is Clause 7.1 of H.225.0.  

On the other hand, ITU-T Recommendation Q.931 on which H.225.0 messages are
based provides quite detailed information on the same subject. While H.225.0
states that Implementations shall follow ITU-T Rec. Q.931 as specified in
H.225.0, there is a lot of confusion surrounding the cases which H.225.0
does not cover and Q.931 does.

In addition, ETSI TS 101 804 - 2 defines Conformance Test Specification for
ITU-T H.225.0. This test specification apparently based on Q.931 procedures,
not on the corresponding H.225.0 ones. More than this, in many cases ETSI TS
101 804 - 2 requests behavior which claims to be based on Q.931, however is
not defined neither in Q.931, nor H.225.0. 

"

Apparently "H.323 conformant" not always means "ETSI TS 101 804 - 2
conformant" and I believe we need to find some solution to at least make
this particular point clear.

I'm going to resubmit AVD-3813. 

It would be great to be able to get some ideas from the group into the
resubmitted document.

Thank you,

Sasha 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20091007/5696049c/attachment-0001.htm>