test - please ignore
meu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Hi all, I currently noticed an issue/error with the use of FeatureSet in H225.0v4' RAS messages. In section 7.9.3.1 Processing by the requesting entity of H323v4 document, there is a statement as follows: "In response to its request, a requesting entity should either reject a confirm or reject a message". The neededFeatures field can be filled in RAS messages (RRQ/GRQ/ARQ). If the GK does not support those features or cannot find a EP that supports these neededFeatures from the originator, then I think the only sane thing the GK can do is to Reject (GRJ, RRJ or ARJ) the request with a suitable reject reason value and I guess that is what the above statement is trying to convey. However, we do not have the appropriate value (neededFeatureNotSupported) rejectReason field of RAS Reject (ARJ, RRJ, GRJ, etc.) messages. We DO HAVE that in the ReleaseComplete H225.0 CallSignaling message for the same purpose. Why is this discrimination? So, I request the charter to consider this as an oversight/error and recommend the editor to add this value (neededFeatureNotSupported) in the rejectReason field of RAS Reject messages. Otherwise, it will lead to chaos where the Request containing the neededFeatures not being handled appropriately. -- Logan Modahala lmodahal@cisco.com, logan@cisco.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Logan, I agree that, based on the text in H.323, that the Gatekeeper may clearly reject a request due to a lack of needed features and there is no reason code defined to signal such a rejection. Those messages that need this reason include: GRJ, RRJ, ARJ, and LRJ. The SCR message may also indicate a failure, but there is no "reason" field. For that message, I assume we should add a "neededFeaturedNotSupported" choice under "result". I'd much rather address this issue before we publish H.225.0v4, rather than afterwards. This clearly appears to be an oversight. Do others have an opinion on this one way or the other? On a side note, you say that an xRJ may be sent if "the GK does not support those features or cannot find a EP that supports these neededFeatures". I have a question about the latter: was it the intent that the GK would look for a registered endpoint that contains the needed features? I'm not disputing the statement, but I don't believe that's clear in H.323. Also, are the neededFeatures in an ARQ supposed to be propagated via an LRQ when LRQs are used to resolve addresses? Pete, can you address these last two questions? Thanks, Paul ----- Original Message ----- From: "Logan Modahala" <lmodahal@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, December 06, 2000 6:00 PM Subject: neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4
Hi all,
I currently noticed an issue/error with the use of FeatureSet in H225.0v4' RAS messages.
In section 7.9.3.1 Processing by the requesting entity of H323v4 document, there is a statement as follows:
"In response to its request, a requesting entity should either reject a confirm or reject a message".
The neededFeatures field can be filled in RAS messages (RRQ/GRQ/ARQ). If the GK does not support those features or cannot find a EP that supports these neededFeatures from the originator, then I think the only sane thing the GK can do is to Reject (GRJ, RRJ or ARJ) the request with a suitable reject reason value and I guess that is what the above statement is trying to convey.
However, we do not have the appropriate value (neededFeatureNotSupported) rejectReason field of RAS Reject (ARJ, RRJ, GRJ, etc.) messages. We DO HAVE that in the ReleaseComplete H225.0 CallSignaling message for the same purpose. Why is this discrimination?
So, I request the charter to consider this as an oversight/error and recommend the editor to add this value (neededFeatureNotSupported) in the rejectReason field of RAS Reject messages. Otherwise, it will lead to chaos where the Request containing the neededFeatures not being handled appropriately.
-- Logan Modahala lmodahal@cisco.com, logan@cisco.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul, Also, the SCI message is OPTIONAL from the receiving endpoint's view. i.e. the receiving EP may not even decode SCI message and therefore there will not be SCR message. I guess the only response would be a XRS message with the Seq.# of the SCI message. This needs to clearly stated as well. In my opinion, these ambiguous items need to resolved before H323v4 publication. - Logan "Paul E. Jones" wrote:
Logan,
I agree that, based on the text in H.323, that the Gatekeeper may clearly reject a request due to a lack of needed features and there is no reason code defined to signal such a rejection. Those messages that need this reason include: GRJ, RRJ, ARJ, and LRJ.
The SCR message may also indicate a failure, but there is no "reason" field. For that message, I assume we should add a "neededFeaturedNotSupported" choice under "result".
I'd much rather address this issue before we publish H.225.0v4, rather than afterwards. This clearly appears to be an oversight. Do others have an opinion on this one way or the other?
On a side note, you say that an xRJ may be sent if "the GK does not support those features or cannot find a EP that supports these neededFeatures". I have a question about the latter: was it the intent that the GK would look for a registered endpoint that contains the needed features? I'm not disputing the statement, but I don't believe that's clear in H.323. Also, are the neededFeatures in an ARQ supposed to be propagated via an LRQ when LRQs are used to resolve addresses?
Pete, can you address these last two questions?
Thanks, Paul
----- Original Message ----- From: "Logan Modahala" <lmodahal@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, December 06, 2000 6:00 PM Subject: neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4
Hi all,
I currently noticed an issue/error with the use of FeatureSet in H225.0v4' RAS messages.
In section 7.9.3.1 Processing by the requesting entity of H323v4 document, there is a statement as follows:
"In response to its request, a requesting entity should either reject a confirm or reject a message".
The neededFeatures field can be filled in RAS messages (RRQ/GRQ/ARQ). If the GK does not support those features or cannot find a EP that supports these neededFeatures from the originator, then I think the only sane thing the GK can do is to Reject (GRJ, RRJ or ARJ) the request with a suitable reject reason value and I guess that is what the above statement is trying to convey.
However, we do not have the appropriate value (neededFeatureNotSupported) rejectReason field of RAS Reject (ARJ, RRJ, GRJ, etc.) messages. We DO HAVE that in the ReleaseComplete H225.0 CallSignaling message for the same purpose. Why is this discrimination?
So, I request the charter to consider this as an oversight/error and recommend the editor to add this value (neededFeatureNotSupported) in the rejectReason field of RAS Reject messages. Otherwise, it will lead to chaos where the Request containing the neededFeatures not being handled appropriately.
-- Logan Modahala lmodahal@cisco.com, logan@cisco.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Logan Modahala lmodahal@cisco.com, logan@cisco.com 7025 Kit Creek Road, P.O. Box 14987 Research Triangle Park, NC 27709 (919) 392-6561 fax: (919) 392-6801 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Logan,
I agree that, based on the text in H.323, that the Gatekeeper may clearly reject a request due to a lack of needed features and there is no reason code defined to signal such a rejection. Those messages that need this reason include: GRJ, RRJ, ARJ, and LRJ.
The SCR message may also indicate a failure, but there is no "reason" field. For that message, I assume we should add a "neededFeaturedNotSupported" choice under "result".
I'd much rather address this issue before we publish H.225.0v4, rather
Paul, I agree this is a drop off. The reason needs to be in all the RAS messages that support the negotiation mechanism: I agree it should be in the set of messages you specified (including SCR). Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Paul E. Jones <paulej@PACKETIZER.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 07 December 2000 01:29 Subject: Re: neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4 than
afterwards. This clearly appears to be an oversight. Do others have an opinion on this one way or the other?
On a side note, you say that an xRJ may be sent if "the GK does not support those features or cannot find a EP that supports these neededFeatures". I have a question about the latter: was it the intent that the GK would look for a registered endpoint that contains the needed features? I'm not disputing the statement, but I don't believe that's clear in H.323. Also, are the neededFeatures in an ARQ supposed to be propagated via an LRQ when LRQs are used to resolve addresses?
Pete, can you address these last two questions?
Thanks, Paul
----- Original Message ----- From: "Logan Modahala" <lmodahal@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, December 06, 2000 6:00 PM Subject: neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4
Hi all,
I currently noticed an issue/error with the use of FeatureSet in H225.0v4' RAS messages.
In section 7.9.3.1 Processing by the requesting entity of H323v4 document, there is a statement as follows:
"In response to its request, a requesting entity should either reject a confirm or reject a message".
The neededFeatures field can be filled in RAS messages (RRQ/GRQ/ARQ). If the GK does not support those features or cannot find a EP that supports these neededFeatures from the originator, then I think the only sane thing the GK can do is to Reject (GRJ, RRJ or ARJ) the request with a suitable reject reason value and I guess that is what the above statement is trying to convey.
However, we do not have the appropriate value (neededFeatureNotSupported) rejectReason field of RAS Reject (ARJ, RRJ, GRJ, etc.) messages. We DO HAVE that in the ReleaseComplete H225.0 CallSignaling message for the same purpose. Why is this discrimination?
So, I request the charter to consider this as an oversight/error and recommend the editor to add this value (neededFeatureNotSupported) in the rejectReason field of RAS Reject messages. Otherwise, it will lead to chaos where the Request containing the neededFeatures not being handled appropriately.
-- Logan Modahala lmodahal@cisco.com, logan@cisco.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Pete, Can you also address my other questions:
On a side note, you say that an xRJ may be sent if "the GK does not support those features or cannot find a EP that supports these neededFeatures". I have a question about the latter: was it the intent that the GK would look for a registered endpoint that contains the needed features? I'm not disputing the statement, but I don't believe that's clear in H.323. Also, are the neededFeatures in an ARQ supposed to be propagated via an LRQ when LRQs are used to resolve addresses?
Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Sorry Paul, suffering from executive fever!!! (Only reading the first paragraph)
On a side note, you say that an xRJ may be sent if "the GK does not
support
those features or cannot find a EP that supports these neededFeatures". I have a question about the latter: was it the intent that the GK would look for a registered endpoint that contains the needed features? I'm not disputing the statement, but I don't believe that's clear in H.323.
By default I would only expect a GK to consider the entity identified in the request and the entity would either support the features or not. However, in some cases endpoints may be reachable through multiple intermediate devices such as gateways to SS7, ISDN, DPNSS or QSIG etc. In that case the needed features may be involved in selecting the forwarding path.
Also, are the neededFeatures in an ARQ supposed to be propagated via an LRQ when LRQs are used to resolve addresses?
Yes. I had assumed that that was 'standard' procedure in turning an ARQ into a LRQ. However, it does make sense to explicitly say it. Note that in the case of multicast LRQ, this is a case where EP selection may be based on neededFeatures etc. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (4)
-
Euchner Martin -
Logan Modahala -
Paul E. Jones -
Pete Cordell