Re: TD-50/Osaka - Changes to the conferenceGoal field
Pete, As you well know, for H.323 mandatory is in the eyes of the implementors. If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.) The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field Bob, You have made the perfect argument for leaving neededFeatures in the conferenceGoal! Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled. If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present. I would imagine that you wouldn't like this. Pete. P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with packages. Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect the choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :) ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
But the version number will also detect the older versions. A v4 client can properly detect and decode the new structure. However, support of
failure. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob, It seems to me that the issue with the negotiation process you discuss below is that the call could be in an alerting state before the negotiation is done. On the other hand, if we make it mandatory in v4 for the called endpoint to check the neededFeatures field then we could avoid false starts, even if the endpoint doesn't support packages. Of course, that doesn't provide a solution for pre-v4 endpoints, but I don't think we have arrived at a reliable solution for that case, yet. Rich "Callaghan, Robert" wrote:
Pete,
As you well know, for H.323 mandatory is in the eyes of the implementors. If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.)
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
You have made the perfect argument for leaving neededFeatures in the conferenceGoal!
Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled.
If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present.
I would imagine that you wouldn't like this.
Pete.
P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with packages. Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect the choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :)
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
But the version number will also detect the older versions. A v4 client can properly detect and decode the new structure. However, support of
failure. 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
Bob,
It seems to me that the issue with the negotiation process you discuss below is that the call could be in an alerting state before the negotiation is done. On the other hand, if we make it mandatory in v4 for the called endpoint to check the neededFeatures field then we could avoid false starts, even if the endpoint doesn't support packages. Of course, that doesn't provide a solution for pre-v4 endpoints, but I don't think we have arrived at a reliable solution for that case, yet.
Rich
"Callaghan, Robert" wrote:
Pete,
As you well know, for H.323 mandatory is in the eyes of the
implementors.
If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.)
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
You have made the perfect argument for leaving neededFeatures in the conferenceGoal!
Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled.
If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present.
I would imagine that you wouldn't like this.
Pete.
P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with
Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect
choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :)
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
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
even packages
is optional, so the client can ignore the requirement to evaluate
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
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
Rich, After some thought on the situation, my feeling is that if you think the original method is unreliable, then I think the second suggestion works even less reliably. Basically the second solution stands zero chance of working with pre v4 entities, and based on Bob's comments will be an implementation issue for v4 and later. I therefore suggest that we remove neededFeature from the SETUP message completely. I will say that I am VERY unhappy with this situation as it compromises what can be done with packages quite considerably. However, we have made rush decisions before which have come back to haunt us. By leaving this out for the time being we can hopefully get it right when we finally decide to put it in. Still, Bob should be pleased about this!!! Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Rich Bowen <rkbowen@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 21 June 2000 01:37 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field packages. the the the 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
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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
Pete, Bob, Support for packages would, of course, be optional in v4. The only mandatory requirement in v4 would be for an endpoint to recognize that a neededFeatures field is present, and if so, either process it or drop the call. The minimal requirement would be very simple to implement, so I don't know of any reason why vendors would ignore it. My suggestion would be to add the neededFeatures field for now and remove it in November if it's still controversial. It will be difficult to add fields after the White Paper is issued. - Rich Pete Cordell wrote:
Rich,
After some thought on the situation, my feeling is that if you think the original method is unreliable, then I think the second suggestion works even less reliably. Basically the second solution stands zero chance of working with pre v4 entities, and based on Bob's comments will be an implementation issue for v4 and later.
I therefore suggest that we remove neededFeature from the SETUP message completely.
I will say that I am VERY unhappy with this situation as it compromises what can be done with packages quite considerably. However, we have made rush decisions before which have come back to haunt us. By leaving this out for the time being we can hopefully get it right when we finally decide to put it in.
Still, Bob should be pleased about this!!!
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Rich Bowen <rkbowen@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 21 June 2000 01:37 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
It seems to me that the issue with the negotiation process you discuss below is that the call could be in an alerting state before the negotiation is done. On the other hand, if we make it mandatory in v4 for the called endpoint to check the neededFeatures field then we could avoid false starts, even if the endpoint doesn't support packages. Of course, that doesn't provide a solution for pre-v4 endpoints, but I don't think we have arrived at a reliable solution for that case, yet.
Rich
"Callaghan, Robert" wrote:
Pete,
As you well know, for H.323 mandatory is in the eyes of the
If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.)
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
You have made the perfect argument for leaving neededFeatures in the conferenceGoal!
Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled.
If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present.
I would imagine that you wouldn't like this.
Pete.
P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with
Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect
choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :)
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
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
even packages
is optional, so the client can ignore the requirement to evaluate
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
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
implementors. packages. the the the 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 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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.comFor 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
Pete, Bob,
Support for packages would, of course, be optional in v4. The only mandatory requirement in v4 would be for an endpoint to recognize that a neededFeatures field is present, and if so, either process it or drop the call. The minimal requirement would be very simple to implement, so I don't know of any reason why vendors would ignore it.
My suggestion would be to add the neededFeatures field for now and remove it in November if it's still controversial. It will be difficult to add fields after the White Paper is issued.
- Rich
Pete Cordell wrote:
Rich,
After some thought on the situation, my feeling is that if you think the original method is unreliable, then I think the second suggestion works
even
less reliably. Basically the second solution stands zero chance of working with pre v4 entities, and based on Bob's comments will be an implementation issue for v4 and later.
I therefore suggest that we remove neededFeature from the SETUP message completely.
I will say that I am VERY unhappy with this situation as it compromises what can be done with packages quite considerably. However, we have made rush decisions before which have come back to haunt us. By leaving this out for the time being we can hopefully get it right when we finally decide to
it in.
Still, Bob should be pleased about this!!!
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Rich Bowen <rkbowen@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 21 June 2000 01:37 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
It seems to me that the issue with the negotiation process you discuss below is that the call could be in an alerting state before the negotiation is done. On the other hand, if we make it mandatory in v4 for the called endpoint to check the neededFeatures field then we could avoid false starts, even if the endpoint doesn't support packages. Of course, that doesn't provide a solution for pre-v4 endpoints, but I don't think we have arrived at a reliable solution for that case, yet.
Rich
"Callaghan, Robert" wrote:
Pete,
As you well know, for H.323 mandatory is in the eyes of the
implementors.
If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.)
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
You have made the perfect argument for leaving neededFeatures in the conferenceGoal!
Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled.
If we have to move neededFeatures to some other position, then
become MANDATORY, at least in terms of recognising that neededFeatures are present.
I would imagine that you wouldn't like this.
Pete.
P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with
Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect
MUST packages. the
choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :)
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
related to those features.
Rich
"Callaghan, Robert" wrote:
Rich,
I question that the concept for forcing conferenceGoal to fail
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
is optional, so the client can ignore the requirement to evaluate
will even packages 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
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
Rich, I really don't want the second option. If you think the original is weak, then I think the second option is far weaker. My feeling is that it buys us nothing. But as long as you can guarantee that we can remove it in Geneva if need be, then I can go along with it. Otherwise I would prefer to remove it now and attempt to re-insert it in Geneva. This seems more fail-safe. It's just that I am aware that the process is getting tighter on what changes are acceptable in Geneva. (For v3 no body was even allowed to turn up.) If we can not make changes in Geneva I would prefer to remove it now and add it into v5 if need be. This would be safer. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Rich Bowen <rkbowen@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 22 June 2000 07:07 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field put packages packages the 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
> > > > 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
>
> --
> --------------------------------------------------------------------
> 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
From a customer's point of view, the standard forms part of the contract. If you're saying that your selling an H.323 v4 compliant endpoint, then you have no choice but to implement what the standard says is mandatory, unless any exceptions are spelt out in the contract. After all, there's not a lot of point in having a standard if implementors can build what they like, and
Bob, then call it H.323. If that were allowed I could build an HTTP server and then fob it off to a customer as an H.323 entity. (Mind you, based on the behaviour of some of the things we have tested, that's probably what a lot of vendor's have done!!! The situation is getting better though.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 20:47 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Pete,
As you well know, for H.323 mandatory is in the eyes of the implementors. If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.)
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Bob,
You have made the perfect argument for leaving neededFeatures in the conferenceGoal!
Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled.
If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present.
I would imagine that you wouldn't like this.
Pete.
P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with packages. Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect the choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :)
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field
Rich,
I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal.
Bob
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: 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
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
even 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
Bob, Forgot to respond to this bit...
The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals.
You would use desiredFeatures if you wanted to operate in this way. neededFeatures is for when you absolutely must not go to CONNECT (ACTIVE) state if features certain are not supported as this typically may imply a billing event. desiredFeatures means that you can work around any features that are not supported. Such a distinction was important in our tunnelling proposals.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Callaghan, Robert -
Pete Cordell -
Rich Bowen