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

22 Jun 2000

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