ASN.1 Changes in H.225.0v3

[Paul E. Jones]

Francois,

Although this is an important question, answering it one way or another does
not necessarily answer the question of mixed fast start & tunnelling.  The
basic point is that what you are advocating the allowance of is expressly
forbidden in earlier versions of H.323.  The BEST answer from this would be
that Q.931 applies (it's my personal feeling that it applies everywhere it is
not specifically over-ridden in H.225.0 or H.323) and the receiving
(early-version) endpoint rejects the call immediately.  This is the best answer
because it at least means behaviour is well-defined.  The alternative is that
Q.931 does not apply in this area, and the behaviour of the receiving endpoint
is undefined - some will work, but we have no sure way of knowing how many will
not - at which point I refer you to Mr Long's words about a standard being a
contract of sorts.  This is the ITU, where there is a requirement that new
versions interoperate with old ones.

To put things another way, I have nothing against putting these two things into
setup messages together.  What I do object to is calling the resulting
standards H.225.0 and H.323 (with whatever version number).  If, however, you
want to put them together in a new pair of standards, called (say) H.225.1 and
H.323.1 (for which you'll need the approval of lots of people) it might be an
idea to clean up the whole thing a bit, learning from some of the mistakes made
in H.225.0/H.323...

Regards,
Chris

> Francois Audet wrote:
>
> This has been discussed at lenght many times.
>
> Q.931 is in direct conflict with H.225.0 on many points, including
> mundate tasks like clearing a call. DISCONNECT and RELEASE messages
> for example are mandatory in Q.931 and forbitten in H.225.0. That
> is a trivial example. The bottom line, is that there is some sort
> of common understanding that Q.931-like procedures are used, with
> a lot of implied exceptions and divergences. The "call control"
> procedures are not formally described in H.225.0. There was even
> a suggestion to add them to a further version of H.323. Be my guess...
>
> > -----Original Message-----
> > From: Dave Walker [mailto:drwalker at SS8NETWORKS.COM]
> > Sent: Thursday, June 01, 2000 11:49 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >
> >
> > I'm not sure this is correct.  H.323 section 7.3.1 mandates the use of
> > Q.931 Annex D procedures.  In turn, that Annex uses Q.931 clause 5.
> > So *that* is what applies in the absence of any overriding provisions
> > in H.323.  So I think that Q.931/5.8.6.2 *should* apply.
> >
> > But to re-iterate what Paul asked earlier, if we had a description of
> > the problem that this was intended to solve, perhaps a less
> > contentious
> > solution could be found.
> >
> > Regards,
> >
> > Dave Walker
> > SS8 Networks
> > Ottawa, Canada
> >
> >
> > > Francois Audet wrote:
> > >
> > > Except that the section that Paul quotes is in Q.931 and
> > NOT in H.225.0.
> > > It has nothing to do with H.225.0. In fact, it talks about a message
> > > that is not even supported in H.225.0 (i.e., RELEASE).
> > >
> > > To reiterate: H.323v2 does not describe how an endpoint
> > receiving both
> > > elements shall behave themselves. It just says that the
> > sender shall not
> > > include both since it would cancel fast start. This
> > particular case (wich
> > > apparently is not supported by any implementation) would
> > result (if you
> > > follow the logic of H.323v2) in ignoring fast start and
> > proceeding with
> > > H.245 tunnelling. That is NOT a backward compatibility
> > problem, and it
> > > does't break anything.
> > >
> > > Rejecting the call with cause value 100 is definitively NOT
> > what H.323v2 says.
> > >
> > > > In Q.931, the user-user IE is typically optional, so the
> > clause that
> > > > Paul Long's been quoting wouldn't apply.  However, since
> > H.323 makes
> > > > the UUIE mandatory, it *does* apply in the case under discussion.
> > > > I think that the statement contained in TD-26, that it preserves
> > > > backwards compatibility, is completely wrong.  The
> > correct statement
> > > > should have been that it doesn't break implementations
> > known to the
> > > > authors.  I agree with Paul that we should try to develop a better
> > > > solution.
> > > >
> > > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >

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