neededFeaturesNotSupported Reject Reason for RAS missing in H225.0v4

[Logan Modahala]

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 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
> 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 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
> >

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