I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start. However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed. Possible solutions are: 1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.) 2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored. Which ever option is chosen, it would also be nice to have a picture for it also! Pete ============================================= Pete Cordell pete@tech-know-ware.com ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Pete, This is already covered in H.323, so there is no need to say it again or in another way. Do you think that the text, below, is deficient in some way? Seems pretty clear to me. 8.2.2/H.323v3: "...intermediate entities shall ensure that H.245 messages encapsulated in Q.931 messages are forwarded to the other endpoint even if the Q.931 message in which the H.245 message is encapsulated would be consumed and not forwarded to the other endpoint. This is accomplished by transferring the encapsulated H.245 message into a Facility message with the h323-message-body set to empty." Paul Long Smith Micro Software, Inc. -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Saturday, May 20, 2000 12:57 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start. However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed. Possible solutions are: 1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.) 2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored. Which ever option is chosen, it would also be nice to have a picture for it also! Pete ============================================= Pete Cordell pete@tech-know-ware.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
Pete,
This is already covered in H.323, so there is no need to say it again or in another way. Do you think that the text, below, is deficient in some way? Seems pretty clear to me.
8.2.2/H.323v3: "...intermediate entities shall ensure that H.245 messages encapsulated in Q.931 messages are forwarded to the other endpoint even if the Q.931 message in which the H.245 message is encapsulated would be consumed and not forwarded to the other endpoint. This is accomplished by transferring the encapsulated H.245 message into a Facility message with
Paul, Francois, I stand corrected... I thought I read an e-mail a while back that didn't allow you to send facility before a certain stage in the call setup process. After searching I can't find it, and the context might have been different anyway (i.e. Sending SETUP and then SENDING Facility, rather than sending SETUP and then RECEIVING Facility.) I'm happy now! Pete ============================================= Pete Cordell pete@tech-know-ware.com ============================================= ----- Original Message ----- From: Paul Long <Plong@SMITHMICRO.COM> To: <ITU-SG16@MAILBAG.INTEL.COM> Sent: 21 May 2000 01:21 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 the
h323-message-body set to empty."
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Saturday, May 20, 2000 12:57 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4
I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start.
However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed.
Possible solutions are:
1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.)
2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored.
Which ever option is chosen, it would also be nice to have a picture for it also!
Pete
============================================= Pete Cordell pete@tech-know-ware.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
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 ----- Original Message ----- From: "Pete Cordell" <pete@TECH-KNOW-WARE.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Saturday, May 20, 2000 1:57 PM Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4
I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start.
However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed.
Possible solutions are:
1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.)
2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored.
Which ever option is chosen, it would also be nice to have a picture for it also!
Pete
============================================= Pete Cordell pete@tech-know-ware.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, The behavior is NOT not defined. In fact, an H.323v2 or v3 EP receiving a Setup message containing both a fastStart and h245Control component _shall_ respond with ReleaseComplete, thus terminating the call. This is defined in Q.931 (see below) and not otherwise countermanded by H.225.0 or H.323. Further, it follows that an EP which does not terminate the call is not compliant. Since the calling EP cannot know the version of the called EP before it sends Setup, I recommend that this v4 "feature" be removed from the Recommendation or at least deprecated and that it not be implemented. 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, a RELEASE COMPLETE message with cause No. 100, “invalid information element contents” shall be returned." Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, May 29, 2000 9:46 PM To: ITU-SG16@MAILBAG.INTEL.COM 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Paul E. Jones -
Paul Long -
Pete Cordell