H.323 procedures and H.450.1 procedures reference H.225.0 on how to set the conferenceGoal for certain cases (e.g. for conference invitations, 450 call independent signalling connections, ...). So far there is exactly one field to be used for setting the appropriate value. With the original BT proposal, we would suddenly in v4 have two ways on how to set the conferenceGoal (depending on whether I send the new v4 optional neededFeatures package or not).
Again, we should go with the alternative proposal provided by Rich keeping the optional neededFeatures package out of the conferenceGoal construct. It does not belong there. The guideline has always been that new optional features shall not impact existing behaviour.
Karl Klaghofer Siemens karl.klaghofer@icn.siemens.de
-----Ursprüngliche Nachricht----- Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] Gesendet am: Tuesday, June 20, 2000 09:20 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: TD-50/Osaka - Changes to the conferenceGoal field
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@CISCO.COM] Sent: Sunday, June 18, 2000 5:14 PM To: ITU-SG16@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@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com