On TD26 - Fast TCS and M/S negotiation in H.323v4

Chris Wayman Purvis cwp at ISDN-COMMS.CO.UK
Thu Jun 1 12:30:00 EDT 2000


Francois,

Time to wade in...

Whatever the advantages may be, given that a Setup message containing both
fastStart and Tunnelling is expressly forbidden up to and including at least
v3, it is extremely unsafe to second-guess what those implementations may do.
They may work in the way you desire.  They may immediately send RELEASE
COMPLETE.  They may crash irrecoverably.  They may act non-deterministically.
Maybe it would be a poor implementation to react badly: maybe it wouldn't.  The
fact of reacting badly would not stop it being a COMPLIANT implementation.
There are major implementations from people who do not watch this list, so it
isn't even safe to assume that anyone whose implementation will break will see
these emails.

Enough problems come about with endpoints which are non-compliant or at the
edge of compliance: please let's not make things worse by introducing something
where this sort of problem has been forseen!

In summary, allowing something expressly forbidden in earlier versions of the
standard breaks the principle of backward compatibility and would mean a new
recommendation (ie it would no longer be H.225.0).

Regards,
Chris

> Francois Audet wrote:
>
> > Francois,
> >
> > The UUIE _is_ a Q.931 IE, 5.8.6.2/Q.931 does not exclude this IE, and
> > neither H.225.0 or H.323 address the issue of how to handle a
> > UUIE--or any
> > other IE, for that matter--with invalid content, therefore
> > the behavior
> > defined in Q.931 is normative for H.323.
>
> An "invalid coding" for an information element does NOT include the content
> of a User-User information element. By definition, a Q.931 User-user IE can
> include whatever you feel like. A proper implementation will not reject a
> call because of the content of the User-user IE.
>
> > _All_ of Q.931 is an "ISDN thing," so what's your point?
> >
> > Finally, there is much in Q.931 that H.323 does not
> > reference, but that does
> > not invalidate the parts of Q.931 that H.323 references.
>
> H.323 does not use Q.931. H.225.0 recycled some of the messages (but not
> all of them). More importantly, it doesn't explicitly use the
> PROCEDURES of Q.931. There are some stringent timer requirements for
> example in Q.931 that not used use by H.323. The DISCONNECT and
> RELEASE messages are not even used. We are not even setting up
> a bearer channel in H.323 when doing a call setup.
>
> In summary, H.225.0 is NOT Q.931.

--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

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