RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Francois,
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.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com