This is because neededFeatures was initially specified to be in conferenceGoal to illicit the correct neededFeatures type operation. There was concern that this would break some implementations so it was moved into the main body. As the move was still under consideration, the action wasn't taken to convert all three to featureSet.

Now neededFeatures is pretty much advisory only, which is undesirable as a proper neededFeatures has the potential for some very powerful things to happen. For example, in an implementation of presence, the semantics of SETUP could be changed and this would need a robust, backward compatible neededFeature operation. Alternatively an alternative media negotiation scheme could be used. Or you could require that certain QoS support is present. It's also useful for checking that what you think should happen does happen. For example, if your network is designed to ingress and egress with SS7 gateways you really want to make sure this happens even if there is some mis-configuration some where. Again, this needs to be backwards compatible.

Chris Wilmot (BT) should be able to discuss various options for how neededFeatures can be made more robust for those that are interested.

Pete.

============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================

----- Original Message ----- From: Frank Derks frank.derks@PHILIPS.COM To: ITU-SG16@mailbag.cps.INTEL.COM Sent: 29 May 2001 20:59 Subject: Generic Extensibility Framework elements in SETUP are different from those in other Call Signalling messages, why?

The SETUP messages contains the three elements neededFeatures,

desiredFeatures

and supportedFeatures. The other call signalling messages contain on

single

featureSet element that includes these three elements. Why does the SETUP message deviate frome the other call signalling messages?

Regards,

Frank

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