Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pre Script: Sorry for the previous mail Hi All, As far as my understanding goes, the purpose of prohibiting both fastStart and H.245 tunnel in SETUP was to avoid race conditions in two tunnels (fastStart can also be considered as a H.245 tunnel with different procedures). Here we are adding a new tunnel which will lead to more such race scenarios until proper care is taken in defining the procedures. The decision on this should not be like a voice vote in Congress. The procedures should be clearly documented and circulated over the reflector and let people argue on those concrete documented steps. Let us see, can we fix the problem introduced by introduction of fastStart? Regards, Jane Hua Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868 Paul Long wrote:
Bob,
H.323 only says that fastStart and h245Control cannot both be included in _Setup_, so it could indeed be included in the Setup-UUIE type.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, June 06, 2000 10:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Jane, I suspect that TD-26 has the procedural issues addressed-- it will just be a matter of specifying the usage of a different field. I'll have to review what is written there, but the most obvious way to prevent race conditions is to specify that channels may not be opened via H.245 until Fast Connect is accepted, explicitly refused, or implicitly refused by not receiving a fastStart element up to and including CONNECT. Paul ----- Original Message ----- From: "Jane Hua" <huajane@YAHOO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, June 07, 2000 2:18 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pre Script: Sorry for the previous mail
Hi All,
As far as my understanding goes, the purpose of prohibiting both fastStart and H.245 tunnel in SETUP was to avoid race conditions in two tunnels (fastStart can also be considered as a H.245 tunnel with different procedures). Here we are adding a new tunnel which will lead to more such race scenarios until proper care is taken in defining the procedures.
The decision on this should not be like a voice vote in Congress. The procedures should be clearly documented and circulated over the reflector and let people argue on those concrete documented steps.
Let us see, can we fix the problem introduced by introduction of fastStart?
Regards, Jane Hua
Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
Paul Long wrote:
Bob,
H.323 only says that fastStart and h245Control cannot both be included
in
_Setup_, so it could indeed be included in the Setup-UUIE type.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, June 06, 2000 10:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
Paul, While you're at it, I would like to propose these (hopefully) uncontroversial corrections and a clarification to TD-26a. Here are my recommendations. 1. However rare, an EP may have a valid reason to reject TCS or MSD. Therefore, we cannot require that the called EP always respond with TCSAck and MSDAck. Replace this passage: "... it shall include the fastStart element and the h245Control element including both the TerminalCapabilitySetAck for the calling endpoint, the TerminalCapabilitySet for the called endpoint and the MasterSlaveDeterminationAck in the same H.225.0 message." with this: "... it shall encode the fastStart element and the h245Control element in the same call-signalling message. This h245Control element shall contain the TerminalCapabilitySet for the called endpoint and the called endpoint's responses to the calling endpoint's TerminalCapabilitySet and MasterSlaveDetermination." 2. Likewise, replace this: "If the h245Control element with the TerminalCapabilitySetAck for the calling endpoint, the TerminalCapabilitySet for the called endpoint and MasterSlaveDeterminationAck are not received in the same message as fastStart (e.g., because the called endpoint is pre-H.323v4), the fast start procedures shall be completed, but not the Terminal Capability Set negotiation and the Master/Slave Determination procedures." with this: "If the h245Control element with the called endpoint's TerminalCapabilitySet and the called endpoint's responses to the calling endpoint's TerminalCapabilitySet and MasterSlaveDetermination are not received in the same message as fastStart (e.g., because the called endpoint is pre-H.323v4), the fast start procedures shall be completed, but not the Terminal Capability Set negotiation and the Master/Slave Determination procedures." 3. It's not a big deal, but I'd like to make the disposition of the MSD and TCS procedures clearer by adding this to the end of the above sentence: ", as if they had never been initiated by the calling endpoint" Paul Long Smith Micro Software, Inc. "Primum non nocere" -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, June 07, 2000 2:59 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Jane, I suspect that TD-26 has the procedural issues addressed-- it will just be a matter of specifying the usage of a different field. I'll have to review what is written there, but the most obvious way to prevent race conditions is to specify that channels may not be opened via H.245 until Fast Connect is accepted, explicitly refused, or implicitly refused by not receiving a fastStart element up to and including CONNECT. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul, A couple of other things regarding TD-26a. 1. We need to say something about the H.245 timers for the Setup-tunneled TCS and MSD messages. Since the responses could be delayed well beyond the normal H.245 timers or not even received at all, we need to effectively disable the timers for these messages. Otherwise, the H.245 procedures could require the calling EP to declare a protocol error. This just cleans up some loose ends. How about adding the following sentence to the end of 8.2.1? "For the TerminalCapabilitySet and MasterSlaveDetermination messages tunneled in Setup, the corresponding H.245 timers, T101 and T106, shall not expire." Note that the behavior associated with the H.245 MSDSE N100 counter stays the same. I guess we don't need to mention this, though. 2. Besides rewording, replace "it is recommended" in the following sentence with "should." Before: "In order to expedite the Terminal Capability Set negotiation and Master/Slave Determination, it is recommended to tunnel the H.245 TerminalCapabilitySet and MasterSlaveDetermination in the Setup message in h245Control." After: "The calling endpoint should tunnel the H.245 messages, TerminalCapabilitySet and MasterSlaveDetermination, in the Setup message. If the called endpoint acknowledges these H.245 messages, the H.245 session can be available to the calling endpoint one round-trip delay sooner than if the calling endpoint did not tunnel these messages." Paul Long Smith Micro Software, Inc. "Primum non nocere" -----Original Message----- From: Paul Long [mailto:Plong@smithmicro.com] Sent: Wednesday, June 07, 2000 10:50 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, While you're at it, I would like to propose these (hopefully) uncontroversial corrections and a clarification to TD-26a. Here are my recommendations. 1. However rare, an EP may have a valid reason to reject TCS or MSD. Therefore, we cannot require that the called EP always respond with TCSAck and MSDAck. Replace this passage: "... it shall include the fastStart element and the h245Control element including both the TerminalCapabilitySetAck for the calling endpoint, the TerminalCapabilitySet for the called endpoint and the MasterSlaveDeterminationAck in the same H.225.0 message." with this: "... it shall encode the fastStart element and the h245Control element in the same call-signalling message. This h245Control element shall contain the TerminalCapabilitySet for the called endpoint and the called endpoint's responses to the calling endpoint's TerminalCapabilitySet and MasterSlaveDetermination." 2. Likewise, replace this: "If the h245Control element with the TerminalCapabilitySetAck for the calling endpoint, the TerminalCapabilitySet for the called endpoint and MasterSlaveDeterminationAck are not received in the same message as fastStart (e.g., because the called endpoint is pre-H.323v4), the fast start procedures shall be completed, but not the Terminal Capability Set negotiation and the Master/Slave Determination procedures." with this: "If the h245Control element with the called endpoint's TerminalCapabilitySet and the called endpoint's responses to the calling endpoint's TerminalCapabilitySet and MasterSlaveDetermination are not received in the same message as fastStart (e.g., because the called endpoint is pre-H.323v4), the fast start procedures shall be completed, but not the Terminal Capability Set negotiation and the Master/Slave Determination procedures." 3. It's not a big deal, but I'd like to make the disposition of the MSD and TCS procedures clearer by adding this to the end of the above sentence: ", as if they had never been initiated by the calling endpoint" Paul Long Smith Micro Software, Inc. "Primum non nocere" -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, June 07, 2000 2:59 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Jane, I suspect that TD-26 has the procedural issues addressed-- it will just be a matter of specifying the usage of a different field. I'll have to review what is written there, but the most obvious way to prevent race conditions is to specify that channels may not be opened via H.245 until Fast Connect is accepted, explicitly refused, or implicitly refused by not receiving a fastStart element up to and including CONNECT. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
participants (3)
-
Jane Hua -
Paul E. Jones -
Paul Long