[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
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
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
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
Hi Paul,
I agree that the problem which I touched has broader scope than the one resulted from the attempt to solve the ETSI TS 101 804 - 2 issue.
So my preference is to put some clarification/fixing text into v7, to help resolve the issue and continue the work if needed into v8.
I tried to classify the problems introduced by ETSI TS 101 804 - 2 and state what I believe is the reasonable H.323 behavior for these cases and where it should be defined.
I found the following two groups:
1) Receiving of incorrectly encoded H.225.0/Q.931 message.
Some facts:
a. H.245 has precisely one response to any incorrectly encoded message: (FunctionNotSupported.cause.syntaxError)
b. RAS has precisely one response to any incorrectly encoded message: (messageNotUnderstood a.k.a XRS)
c. Q.931 has very detailed approach to what to do with incorrectly encoded messages.
So detailed that for example the processed of:
incorrect protocol discriminator at the top level of the message differs from the processing of
incorrect protocol discriminator inside user-User IE.
d. H.225.0 7.1 provides very limited set of rules for error handling, I found these:
i. Implementations shall follow ITU-T Rec. Q.931 as specified in this Recommendation.
ii. The H.225.0 endpoint may ignore all optional messages it does not support without harming interoperability
iii. The H.225.0 endpoint ... but shall respond to an unknown message with a Status message
iv. Procedures for receiving unrecognized "comprehension required" information elements shall apply according to 5.8.7.1/Q.931.
v. Endpoints not supporting Q.931 shifted code sets shall ignore all Q.931 messages using such methods.
The BIG question is: shall Implementations follow ITU-T Rec. Q.931 clause 5.8 "Handling of error conditions" or not.
Should we have such an elaborate error handling processing for Q.931 messages, while the rest works well with simple mechanisms?
2) Behavior of an H.323 entity receiving a STATUS message with callState indicating a call state, which differs from the one known by the H.323 entity.
Q.931 specifies for example that if STATUS received with callState other than null and the known call state for this call is null then STATUS should be responded with RELEASE COMPLETE.
3) Behavior of an H.323 entity when SETUP is not acknowledged during T303 timeout.
Q.931 specifies that SETUP needs to be retransmitted.
======================================================================== ==============
So my proposal is (I'll work on precise wording, this is just the essence):
1) Remove from H.225.0 7.1 the sentences indicated by 1) d. ii-v. above.
2) Add new section H.225.0 7.1.1 dedicated to H.225.0/Q.931 messages error handling and stating the following:
a. Q.931 section 5.8 does not apply to H.225.0 endpoints.
b. The H.225.0 endpoint may ignore all optional messages it does not support without harming interoperability
c. The H.225.0 endpoint ... but shall respond with a Status message containing cause No. 95 to any H.225.0 message it cannot understand or decode due to Q.931 or ASN.1 encoding error.
3) Add to section 8.6 new paragraph (probably after the current third paragraph) stating that
"An H.323 entity receiving a STATUS message with a callState indicating a call state other then null and containing a callID value which is does not correspond to any of the calls currently handled by the entity may respond to STATUS message with RELEASE COMPLETE containing the CRV and callID from the STATUS message."
4) Add to section 8.6 new paragraph (probably at the end) stating that
"On expiration of the T303 the H.323 entity shall not retransmit the SETUP message, it shall clear the call according to the Phase E procedures defined in section 8.5."
I hope this does not disturb H.323/H.225.0 too much and we can agree at least on part of it.
I will prepare a contribution with the proposal outlining the above to the meeting.
Does this make sense?
Thanks,
Sasha
From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, October 07, 2009 10:27 PM To: Sasha Ruditsky; itu-sg16@lists.packetizer.com Subject: RE: [itu-sg16] AVD-3813 Handling Of Error Conditions in H.323
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
participants (2)
-
Paul E. Jones -
Sasha Ruditsky