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