TD-50/Osaka - Changes to the conferenceGoal field

[Paul E. Jones]

Rich,

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.

Paul

----- Original Message -----
From: "Rich Bowen" <rkbowen at CISCO.COM>
To: <ITU-SG16 at MAILBAG.INTEL.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 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip).
> 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:
>
> Setup-UUIE ::= SEQUENCE
> {
>         [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 mailbag.intel.com
>

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