AW: TD-50/Osaka - Changes to the conferenceGoal field - sg16-avd

19 Jun 2000

      Rich,
I agree with your summary and to your alternative proposal (i.e. to add the
neededFeatures field directly to
the Setup-UUIE).
Regards,
Karl Klaghofer
Siemens
...
-----Ursprüngliche Nachricht-----
Von:  Rich Bowen [SMTP:rkbowen@CISCO.COM]
Gesendet am:  Sunday, June 18, 2000 23:14
An:   ITU-SG16@mailbag.cps.intel.com
Betreff:      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@mailbag.intel.com

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

AW: TD-50/Osaka - Changes to the conferenceGoal field

Klaghofer Karl ICN SIB NL D1

tags (0)

participants (1)