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

Paul,

Like I said before, H.323 clearly states that a Setup cannot contain both a fastStart and h245Control component. Period. 8.2.1/H.323v3: "The calling endpoint >>>shall not<<< include both a fastStart element and encapsulated H.245 messages in h245Control in the same Setup message..." What part are people having trouble understanding?

That covers it for the calling EP. Q.931 is equally clear about what the called EP is required to do. 5.8.6.2/Q.931: "When a SETUP or RELEASE message is received which has one or more mandatory information elements with invalid content [e.g., fastStart and h245Control both present], a RELEASE COMPLETE message with cause No. 100, 'invalid information element contents' shall be returned."

If a calling EP had some way to determine which version the called EP was before it sent Setup, we could make this version-specific behavior (which has its own problems, remember), but since Setup is the first message, we cannot do this.

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, May 31, 2000 12:29 AM To: ITU-SG16@MAILBAG.INTEL.COM 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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com