If they reject the call with cause 100, then it is their implementation that is
broken.

> -----Original Message-----
> From: Paul Long [mailto:Plong@SMITHMICRO.COM]
> Sent: Thursday, June 01, 2000 8:04 AM
> To: ITU-SG16@MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Francois,
>
> We should not be taking a poll as to whether something would
> break existing
> implementations. What about vendors that we don't ask, that
> don't respond,
> or are out of the loop for some reason? A standard is a
> contract of sorts.
> Breaking contracts is a bad thing in part because future
> contracts cannot be
> depended on.
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Francois Audet [mailto:audet@NORTELNETWORKS.COM]
> Sent: Thursday, June 01, 2000 7:34 AM
> To: ITU-SG16@MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> I fully agree with Orit.
>
> So far, I haven't heard of anybody that actually implemented clearing
> the call
> if both fastStart and h245Control are present in SETUP. I would argue,
> it would
> be a very bad implementation, regardless of what they interpreted the
> spec
> saying.
>
> This being said, it seems that it will not create any interoperability
> problems.
> The *worst* case scenario (here again, I haven't heard of anybody that
> actually implemented it that way) is that the call would
> proceed as fast
>
> tunnelling (as per the spec) and ignore the fast start.
>
> The benefits of doing the fastStart and the fast tunnelling
> at the same
> time
> far outweight the theoretical backward compatibility problems.
>
> If anybody wants to revoke the Osaka agreement, contributions in
> Portland are
> welcomed. ;^)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv@mailbag.intel.com
>