TD-50/Osaka - Changes to the conferenceGoal field

Rich Bowen rkbowen at CISCO.COM
Tue Jun 20 20:37:34 EDT 2000


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 at ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Pete Cordell [mailto:pete at TECH-KNOW-WARE.COM]
> Sent: Tuesday, June 20, 2000 2:01 PM
> To: ITU-SG16 at 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 at tech-know-ware.com
> +44 1473 635863
> =============================================
>
> ----- Original Message -----
> From: Callaghan, Robert <Robert.Callaghan at ICN.SIEMENS.COM>
> To: <ITU-SG16 at 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 at 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
> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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

--
--------------------------------------------------------------------
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