neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4

Logan Modahala lmodahal at
Wed Dec 6 20:39:27 EST 2000


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

- 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 at CISCO.COM>
> To: <ITU-SG16 at>
> 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 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, logan at
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at
> >

Logan  Modahala
lmodahal at, logan at
7025 Kit Creek Road, P.O. Box 14987
Research Triangle Park, NC 27709
(919) 392-6561	  fax: (919) 392-6801

More information about the sg16-avd mailing list