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

Francois Audet audet at NORTELNETWORKS.COM
Thu Jun 1 15:14:17 EDT 2000


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000601/74ee27a9/attachment-0004.html>


More information about the sg16-avd mailing list