TD-50/Osaka - Changes to the conferenceGoal field

Paul E. Jones paulej at PACKETIZER.COM
Mon Jun 19 03:22:29 EDT 2000


I prefer the new approach.  Should be also consider adding a release
complete reason "neededFeaturesNotSupported"?  Of course, that would be
worthless to a V2 EP, but it would let a V4 EP tell its V4 GK that it
dropped the call due to a lack of feature support.


----- Original Message -----
From: "Rich Bowen" <rkbowen at CISCO.COM>
Sent: Sunday, June 18, 2000 5:14 PM
Subject: TD-50/Osaka - Changes to the conferenceGoal field

> All,
> In Osaka we agreed to add support for packages to H.225.0 along the
> lines of TD-50 (
> There was some concern raised about the proposed modifications to the
> conferenceGoal field in the Setup message.  The meeting report states:
> "Some issues were raised about conflicts in the usage of the conference
> goal field between this new method and H.450.x.  A possible solution is
> to create a new field in the ASN.1 to avoid conflicts.   The editors are
> empowered to work with interested parties to resolve these conflicts in
> the ASN.1 before the white paper is issued."
> The modification proposed in TD-50 was the addition of the
> "neededFeatures" field to the confereceGoal field of the Setup-UUIE:
>         conferenceGoal          CHOICE
>         {
>                 create          NULL,
>                 join            NULL,
>                 invite          NULL,
>                 ...,
>                 capability-negotiation          NULL,
>                 callIndependentSupplementaryService     NULL,
> -->             neededFeatures          NeededFeatureGoal
>         },
> where the NeededFeatureGoal structure is defined as:
> NeededFeatureGoal ::= SEQUENCE
> {
>         basicGoal       CHOICE
>         {
>                 create                                  NULL,
>                 join                                    NULL,
>                 invite                                  NULL,
>                 capability-negotiation                  NULL,
>                 callIndependentSupplementaryService     NULL,
>                 ...
>         } OPTIONAL,
>         features        SEQUENCE OF SupportedFeatures,
>         ...
> }
> An alternative approach would be to add a neededFeatures field at the
> highest level of the Setup-UUIE ASN.1 instead of inside the
> conferenceGoal structure, similar to the way the desirededFeatures and
> supportedFeatures fields will be added (see TD-50), like this:
> {
>         [snip]
> -->     neededFeatures          SEQUENCE OF SupportedFeatures OPTIONAL,
>         desiredFeatures         SEQUENCE OF SupportedFeatures OPTIONAL,
>         supportedFeatures       SEQUENCE OF SupportedFeatures OPTIONAL
> }
> The motivation for adding neededFeatures to the conferenceGoal field was
> to force a call failure when trying to setup a call to pre-v4 endpoint
> and there is some v4 or later feature that is *required* for the call.
> The mechanism is intended to work like this:
> o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some
> required feature in the neededFeatures field of the conferenceGoal.
> o The pre-v4 EP doesn't recognize the neededFeatures field as a
> supported CHOICE for a conferenceGoal, so it sends Release Complete.
> There would not be any conflicts with H.450, as suggested in the meeting
> report, because if the callIndependentSupplementaryService was needed,
> it would still be specified.  The difference is that, if a neededFeature
> was also required, the H.450 goals would be specified inside the
> NeededFeatureGoal structure, which v4 and later endpoints would be aware
> of.
> These are the pros and cons of adding neededFeatures to the
> conferenceGoal vs. adding it to Setup-UUIE, IMO:
> o Advantages:
>     - *May* force an early call release if a required feature is
>       not supported by a pre-v4 endpoint.
> o Disadvantages:
>     - ASN.1 and thus implementation would be more complex.
>       Potentially have to check the conferenceGoal in two structures
>       instead of one.
>     - If pre-v4 EP sends Release Complete, there is no way to
>       know whether it was sent because of an unrecognized
>       conferenceGoal, because there is no ReleaseCompleteReason
>       defined for that purpose.
>     - H.323 does not require failing a call if the conferenceGoal
>       is unrecognized, so the mechanism may not work at all.
> Although I think this mechanism is a good idea (and I supported it in
> Osaka), at this point I don't think it would work reliably enough to
> justify the added complexity.  So I would prefer the alternative
> approach described above, adding the neededFeatures field directly to
> the Setup-UUIE.
> Okay, fire away. :-)
> Regards,
> Rich
> --------------------------------------------------------------------
> Richard K. Bowen                     Cisco Systems, Inc.
> VoIP Session Protocols               Research Triangle Park, NC, USA
> --------------------------------------------------------------------
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list