neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4
pete at TECH-KNOW-WARE.COM
Thu Dec 7 14:06:51 EST 2000
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 at tech-know-ware.com
+44 1473 635863
----- Original Message -----
From: Paul E. Jones <paulej at PACKETIZER.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 07 December 2000 01:29
Subject: Re: neededFeaturesNotSupported Reject Reason for RAS missing in
> 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"
> 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
> 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
> 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?
> ----- Original Message -----
> From: "Logan Modahala" <lmodahal at CISCO.COM>
> To: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Wednesday, December 06, 2000 6:00 PM
> Subject: neededFeaturesNotSupported Reject Reason for RAS missing in
> > Hi all,
> > I currently noticed an issue/error with the use of FeatureSet in
> > H225.0v4' RAS messages.
> > In section 126.96.36.199 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 at cisco.com, logan at cisco.com
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd