TD-50/Osaka - Changes to the conferenceGoal field
Rich Bowen
rkbowen at CISCO.COM
Tue Jun 20 03:20:18 EDT 2000
Bob,
If the v4 client supports the features listed in the needFeatures field,
then it will respond with those same features listed in a
supportedFeatures field, as an acknowledgement. Presumably if it
acknowledges features in this way, then it will not ignore packages
related to those features.
Rich
"Callaghan, Robert" wrote:
>
> Rich,
>
> I question that the concept for forcing conferenceGoal to fail will even
> work.
>
> The use of conferenceGoal will detect a v2 or v3 client through a failure.
> But the version number will also detect the older versions. A v4 client can
> properly detect and decode the new structure. However, support of packages
> is optional, so the client can ignore the requirement to evaluate the
> packages.
>
> Then what?
>
> Bob
>
> -----Original Message-----
> From: Rich Bowen [mailto:rkbowen at CISCO.COM]
> Sent: Sunday, June 18, 2000 5:14 PM
> To: ITU-SG16 at mailbag.cps.intel.com
> 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
--
--------------------------------------------------------------------
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
More information about the sg16-avd
mailing list