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@radvision.com]
Sent: Monday, October 05, 2009 2:31 PM
To: Paul E. Jones; itu-sg16@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@packetizer.com]
Sent: Friday, October 02, 2009 2:29 PM
To: Sasha Ruditsky; itu-sg16@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@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com]
On Behalf Of Sasha Ruditsky
Sent: Wednesday, September 30, 2009 6:01 PM
To: itu-sg16@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