H.323 Annex D v2

Hans Viens hviens at MEDIATRIX.COM
Thu May 31 11:03:46 EDT 2001

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

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


Pete Cordell
pete at tech-know-ware.com
+44 1473 635863

----- Original Message -----
From: Frank Derks <frank.derks at PHILIPS.COM>
To: <ITU-SG16 at 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,
> and supportedFeatures. The other call signalling messages contain on
> 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 at mailbag.intel.com

More information about the sg16-avd mailing list