Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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
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
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
Bob (Jane?),
H.323 allows the message that carries the accepted FC channels, e.g., Alerting, to also carry tunneled H.245 messages. What you may be thinking of is that 8.2.1/H.323v3 (see below) says that an EP cannot tunnel H.245 _prior_ to the call-signaling message that carries the accepted FC channels. It's okay to do it in the same message, though.
"The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures."
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Wednesday, June 07, 2000 12:51 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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
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
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
And to re-emphasize...
"The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a
Q.931
message containing fastStart by the called endpoint terminates the Fast Connect procedures."
This sentence has been removed from H.323.
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Folks,
A few days ago, I posted a notice that the ASN.1 in H.323v3 was changing. (See the e-mail dated June 2 to this list by me.)
This change relates to fields "supportsAnnexECallSignaling" and "useAnnexECallSignaling".
I received one e-mail expressing concern, but the company is investigating whether they will have an impact. If I have not heard any concerns expressed by the end of this week, I will assume that the agreed change does not effect any current implementations in production and that this change will be put forward for acceptance by the ITU.
It is absolutely critical that we have agreement on this issue now, rather than later, so that we can prevent interoperability problems as people roll out H.323v3 products later this year.
Best Regards, Paul E. Jones Editor, H.323
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
I can see that from the words you can deduce that fastConnect and H.245 can be present in the same reply, but are we sure that that is the intent of the authors, and also how implementors will read it?
Also, it would be interesting to know whether the restrictions were in the original text or placed in later. If they were put in later, the text may well be fudged somewhat in its accuracy, as quite often such fixes are put in in panic and not so well thought through.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Paul Long Plong@SMITHMICRO.COM To: ITU-SG16@MAILBAG.INTEL.COM Sent: 07 June 2000 07:36 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Bob (Jane?),
H.323 allows the message that carries the accepted FC channels, e.g., Alerting, to also carry tunneled H.245 messages. What you may be thinking
of
is that 8.2.1/H.323v3 (see below) says that an EP cannot tunnel H.245 _prior_ to the call-signaling message that carries the accepted FC
channels.
It's okay to do it in the same message, though.
"The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a
Q.931
message containing fastStart by the called endpoint terminates the Fast Connect procedures."
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Wednesday, June 07, 2000 12:51 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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
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
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
Paul- What I was thinking of was the possibility, under TD-26, that the called endpoint responded to the initial TCS message in the H.245 channel before it replied to the fastStart element. If it could use the early H.245 tunnel, the receiver (originator) would know the difference and wait for CONNECT or fastStart. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
Paul Long wrote:
Bob (Jane?),
H.323 allows the message that carries the accepted FC channels, e.g., Alerting, to also carry tunneled H.245 messages. What you may be thinking of is that 8.2.1/H.323v3 (see below) says that an EP cannot tunnel H.245 _prior_ to the call-signaling message that carries the accepted FC channels. It's okay to do it in the same message, though.
"The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures."
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Wednesday, June 07, 2000 12:51 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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
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
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
Bob,
But TD-26a says that this can't happen ("... the called endpoint ... shall include the fastStart element and the h245Control element ... in the same H.225.0 message".) Are you saying that you'd _like_ to respond to TCS+MSD in one message, e.g., Alerting, and then return fastStart in a subsequent one, e.g., Connect?
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Bob Gilman [mailto:rrg@LUCENT.COM] Sent: Wednesday, June 07, 2000 2:59 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul- What I was thinking of was the possibility, under TD-26, that the called endpoint responded to the initial TCS message in the H.245 channel before it replied to the fastStart element. If it could use the early H.245 tunnel, the receiver (originator) would know the difference and wait for CONNECT or fastStart. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Bob Gilman -
Jane Hua -
Paul E. Jones -
Paul Long -
Pete Cordell