Francois,
 
I agree that the behavior is desirable, but I still argue that it will break backward compatibility.  If we can agree with a new field "earlyH245" as a special field for SETUP to do essentially the same thing, but only for V4, I would be quite happy-- we get the same end result without V3 and V2 compatibility issues.
 
I do not want to wait until Portland.  The Whitepaper drafts are due before then and I hope that that meeting will be focused on only critical issues in H.323 and that most of our time will be spent on further development of Annexes and perhaps forward thinking on V5 :-)
 
Paul
 
----- Original Message -----
From: Francois Audet
To: ITU-SG16@mailbag.cps.intel.com
Sent: Thursday, June 01, 2000 8:33 AM
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. ;^)

> -----Original Message-----
> From: Orit Levin [mailto:orit@RADVISION.COM]
> Sent: Wednesday, May 31, 2000 8:32 AM
> To: ITU-SG16@MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Hi Paul and all the others!
> Here it is (and it is not surprising for those, participated in Osaka
> meeting).
> I believe, that it is the last moment to clear the confusion
> in the least
> harmful way (even on the expense of THEORETICAL H.323v.2 "strict"
> implementations).
> RADVision definitely votes for allowing Fast Connect and
> H.245 tunneling in
> Setup, supporting by that TD-26.
> Best Regards,
> Orit Levin
> RADVision Inc.
> 575 Corporate Drive Suite 420
> Mahwah, NJ 07430
> Tel: 1 201 529 4300  (230)
> Fax: 1 201 529 3516
> www.radvision.com
> orit@radvision.com
> -----Original Message-----
> From: Paul E. Jones <paulej@PACKETIZER.COM>
> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM>
> Date: Wednesday, May 31, 2000 1:46 AM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> >Pete,
> >
> >If we could follow such logic, I would agree that this
> procedure would be
> >worth perusing.  Unfortunately, the inclusion of fastStart
> and tunneled
> >H.245 messages in the SETUP message is not defined.  There
> is no way to
> >predict how a V2 device will behave when receiving these
> messages.  I like
> >the idea, but I'm afraid we will compromise backward compatibility by
> >including it.
> >
> >Let's assume a V2 device does *not* recognize the tunneled
> H.245 in SETUP
> >(ignores it), but accepts the Fast Connect proposal. 
> Assume, also, that in
> >the CONNECT message, the endpoint includes the fastStart
> element *and* a
> >tunneled TCS message.  What could the calling endpoint
> *safely* assume?
> >
> >Assume that CONNECT was the first message received following
> the SETUP if
> >that helps complicate matters further for you. :-)
> >
> >I just need further convincing.
> >
> >Paul
> >
> >----- Original Message -----
> >From: "Pete Cordell" <pete@TECH-KNOW-WARE.COM>
> >To: <ITU-SG16@mailbag.cps.intel.com>
> >Sent: Tuesday, May 30, 2000 2:40 PM
> >Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >
> >
> >> RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Hi
> Paul, Francois,
> >and
> >> others,
> >>
> >> I think it is important that we make it work, but as you
> say, it has to
> be
> >> reliable and any burden of insuring backwards
> compatibility has to be
> >placed
> >> on the newer EP.  In this case it is primarily an issue
> for the calling
> >EP.
> >>
> >> As I see it, (and I'm sure you'll correct me if I'm not
> seeing it right!)
> >> when there is H.245 in the SETUP message, then the called
> endpoint can
> >> either ignore the H.245, or accept it.  (It could clear
> the call, but
> I'll
> >> ignore that one for the time being.)  There is also the
> case where it
> >> decides that the H.245 takes precedence over fast start.
> >>
> >> Knowing whether fast start has been accepted is fairly
> straight forward.
> >>
> >> I think the called endpoint has a very good idea of what
> decision was
> >taken
> >> with regard to the H.245 based on the reply from the
> called endpoint.
> >>
> >> - If the reply message in which the fast start information
> is contained
> >> contains H.245, then it can assume that the called EP
> accepted the H.245.
> >> The H.245 state about which channels are open will be
> updated according
> to
> >> the fast start parameters.
> >>
> >> - If the reply message in which the fast start information
> is contained
> >> contains no H.245, then it has probably ignored the H.245.
> >>
> >> --- If H.245 tunneling is enabled, but the calling
> endpoint believes that
> >> the called endpoint ignored its H.245 in the SETUP
> message, then it can
> >> re-transmit its capability set when it becomes OK to do so
> under the
> >normal
> >> fast start/H.245 rules.  (It should probably modify the
> sequence number
> >> before doing this.)
> >>
> >> --- In the case where the called EP actually did accept
> the H.245 but did
> >> not reply as expected, the called EP will receive a second
> capability
> set.
> >> However, endpoints should be able to handle this as this
> is a standard
> >H.245
> >> procedure.
> >>
> >> So as long as V4 endpoints use this kind of logic then I
> think it is safe
> >> for them to combine both H.245 and fast start.
> >>
> >> Perhaps we should document the above more formally for V4,
> and maybe say
> >> that if a V4 EP wants to accept both fast start and H.245
> Cap tunnelling
> >at
> >> the same time then it SHALL put the fast start and H.245
> in the same
> >> message.
> >>
> >> Does this sound in any way reasonable?
> >>
> >> Pete.
> >>
> >> =============================================
> >> Pete Cordell
> >> pete@tech-know-ware.com
> >> =============================================
> >>
> >> ----- Original Message -----
> >> From: Paul E. Jones
> >> To: Francois Audet ; Mailing list for parties associated
> with ITU-T Study
> >> Group 16 ; pete
> >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran
> >> Sent: 30 May 2000 08:20
> >> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >>
> >>
> >> Francois,
> >>
> >> But the possibility exists that a V2 device may accept
> both, reject one
> or
> >> the other, or reject both since a SETUP containing
> fastStart and tunneled
> >> H.245 is "illegal".  Heck, a "strict" endpoint may even
> drop the call,
> but
> >I
> >> suspect that nobody would go that far.
> >>
> >> If fastStart was accepted and the remote end returns the
> tunneling flag
> >set
> >> to TRUE, how do you know if it did or did not process the
> H.245 message
> in
> >> the SETUP?  I'm not convinced that this procedure is going to make
> >everybody
> >> happy.  (Same could be said if fastStart is not accepted,
> I suppose.)
> >>
> >> My concern is that this issue is potentially damaging to some
> >> implementations.  If all of the vendors have no problem
> with this change,
> >> then I can live with it.  Cisco has no objection, but I
> would like to
> >> solicit the input of others-- changes like this, even as
> good as they
> are,
> >> could cause serious problems.
> >>
> >> It appears that we've already made a similar "mistake" by
> allowing H.245
> >> procedures to be done in parallel to fastConnect by
> removing the clause
> >that
> >> says that if we start H.245, fast connect is terminated. 
> That text was
> >> removed, because there was a race condition that could
> occur, which could
> >> result in interoperability problems.  The right solution
> probably should
> >> have been to document the race condition and tell people
> "don't do that".
> >> However, we made the change and now some manufacturers have serious
> >backward
> >> compatibility problems.  I don't want to make the same
> mistake again.
> >>
> >> Comments?
> >>
> >> Paul
> >>
> >> ----- Original Message -----
> >> From: Francois Audet
> >> To: 'Paul E. Jones' ; Mailing list for parties associated
> with ITU-T
> Study
> >> Group 16 ; pete
> >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran
> >> Sent: Monday, May 29, 2000 11:00 PM
> >> Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >>
> >>
> >> Yes, a few comments:
> >> 1 It seems that all current implementations that we could think of
> >>   would simply ignore the tunnelling information if the fastStart
> >>   element is present. This means, that there would be no
> >>   interoperability problems. Fast start would be
> sucessfull, but not
> >>   tunnelling, which would mean that tunnelling would have to happen
> >>   after the SETUP message, as per H.323v2 and v3.
> >> 2 There is a small possibility that an implementation
> would acutally
> >>   give priority to the tunnelling information instead of
> the fastStart
> >>   element (v2 and v3 don't say what would happen if they
> are present,
> they
> >>   just say not to do it). In that particular case, the
> fastStart would
> >fail
> >>   but the tunnelling would be successful. So the worst
> case scenario is
> >that
> >>   fastStart fails, but "fast tunnelling" is successful.
> This doesn't seem
> >to
> >>   me to be a real interoperability problem. In any case,
> it seems that
> >case
> >>   1 is much more likely.
> >>
> >>
> >> > -----Original Message-----
> >> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> >> > Sent: Monday, May 29, 2000 7:46 PM
> >> > To: Mailing list for parties associated with ITU-T Study
> >> > Group 16; pete
> >> > Cc: Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha)
> Ruditsky; Dale
> >> > Skran
> >> > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >> >
> >> >
> >> > Pete, Sasha, Francois, Dale, et al,
> >> >
> >> > I have concerns about this document that differ from Pete's.
> >> > However, since
> >> > discussion on this document has started, I thought I might as
> >> > well express
> >> > my concerns now while the material is fresh on people's minds.
> >> >
> >> > The issue has to do with the very first sentence of the
> >> > proposal, which says
> >> > to strike "shall not" and replace it with "may".  So, V2
> >> > devices shall not
> >> > send a fastStart element and an H.245 message in SETUP, but
> >> > V4 may.  This
> >> > seems to be a serious backward compatibility issue.  If a V2
> >> > device were to
> >> > receive a SETUP containing fastStart and an encapsulated
> >> > H.245 message, what
> >> > would it do?  I believe the behavior is not defined.
> >> >
> >> > Would somebody like to comment?
> >> >
> >> > Paul
> >> >
> >> ... cut ...
> >>
> >>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> 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
>