Terry,

Following that logic, I believe it makes sense to have the desired/needed features in the GRQ. That way, if the GK does not support the needed features, it could chose to not respond or send a GRJ message. The idea, of course, would to put the endpoint into a zone with a GK that supports the needed features.

Paul

----- Original Message ----- From: "Terry L Anderson" tla@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Monday, July 31, 2000 11:21 AM Subject: Re: H.225 white draft - more

as a follow on to my previous question -

It would seem useful to have featureSet in RRQ rather than only in ARQ. This would allow desired and needed Features to be indicated at

registration

time. If the features are needed for all calls and not available this

would

allow determining this before the first call.

And it should be in RCF so that the gatekeeper can indicate to the GW features that it desires or needs. For example, a GW might indicate in

RRQ

that is supports feature "A" and GK might indicate in RCF that feature "A" is needed (thereby indicating that feature-A-specific GenericData should

be

included in ARQs).

featureSet is not currently in either RRQ or RCF, so currently such negotiation can only occur in ARQ/ACF. The later is useful for

negotiating

per-call features, but cannot indicate all-call needs or affect

genericData

to be included in ARQ's.

Terry L Anderson wrote:

...

I am looking over the "GenericData" related fields in the ASN.1 and saw one asymmetry. Several commands (e.g., Alerting, ARQ, etc) contain featureSet FeatureSet OPTIONAL while Setup contains neededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, desiredFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, supportededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, which with the exception of the replacementFeatureSet BOOLEAN is exactly the contents of FeatureSet. Is there a reason for having these separately in Setup rather than having featureSet in Setup?

--

Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--

Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

You must have very different uses in mind for neededFeatures than I. If this is used in negotiating the use of GenericData items (and the feature supporting this data), it is as necessary to indicate to the downstream entity (toward called party) any feature that is required as it is for the downstream entity to indictate back to the upstream entity in the reply. So I believe neededFeatures (as well as supported and desired) is needed in both Setup and Connect (just as in both ARQ and ACF). Without having it in Setup there is no way to tell the downstream entities that the "robustness feature" (if we choose to implement it this way) is required or the call should be rejected or routed to an entity that can support it. I would assume that other features might also want to force routing to an entity that supports some vital feature (say some special billing server authorization token).

Pete Cordell wrote:

Terry,

The reason for the difference is that originally, neededFeature was in the cofferenceGoal as I felt that would have more of a chance of achieve the right result in a backwards compatible manner. Hence it was split from the other items.

Concerns have been raised about the effectiveness of having the field in conferenceGoal, and hence the editors with a few supporters moved the neededFeatures next to desiredFeatures.

However, my feeling is that this is even less satisfactory than where it was originally (i.e. guarenteed to not achieve the desired effect every time). Therefore, at the moment I intend to recommend removing neededFeatures from SETUP all together.

Therefore, at this stage it is probably best not to include a FeatureSet in SETUP. However, depending on the decisions taken in Geneva, (i.e. if neededFeatures remains where it is in the white paper) then changing to FeatureSet would be more appropriate (it provides consistent parsing and a whole bunch of other benefits etc.)

Hope this helps,

Pete.

============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com

+44 1473 635863

----- Original Message ----- From: Terry L Anderson tla@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 28 July 2000 17:12 Subject: H.225 white draft

...

I am looking over the "GenericData" related fields in the ASN.1 and saw one asymmetry. Several commands (e.g., Alerting, ARQ, etc) contain featureSet FeatureSet OPTIONAL while Setup contains neededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, desiredFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, supportededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, which with the exception of the replacementFeatureSet BOOLEAN is exactly the contents of FeatureSet. Is there a reason for having these separately in Setup rather than having featureSet in Setup?

--

Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla