FW: [OpenH323]Fast Connect & H245 tunneling: do they really work?
-----Original Message----- From: Alain Daigle [mailto:daiglea@memotec.com] Sent: Tuesday, June 19, 2001 3:14 PM To: openh323@openh323.org Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work?
Hi,
H.323v2 seems to indicate that with faststart, the opening of a H245 channel is optional. Like in the following sections:
8.1.7.2 Switching to H.245 Procedures After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures.
8.2.3 Switching to a Separate H.245 Connection When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time.
And in the H323 implementation guide (from packetizer), there is a section on how a fastconnect call with no h245 channel should be terminated.
Call Termination 2a. The following is how a call shall be terminated if the control channel is not open (Fast Connect was used and no control channel was ever established) but the call-signaling channel is open. Note that, in this case, only the initiating side is required to send ReleaseComplete. I assume that it is an oversight that the two cases are not consistent. I also assume that the remote EP will close the call-signaling channel upon receipt of ReleaseComplete and consider the call terminated.
But if the remote is asking for a h245 channel (separate or tunneled) after the call is established, it's mandatory to support that...
Alain Daigle
----- Original Message ----- From: "Chris Wayman Purvis" chriswaymanpurvis@hotmail.com To: openh323@openh323.org Sent: Tuesday, June 19, 2001 5:11 AM Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work?
Nicola,
(2). We partially overcame the problem modifying the Openh323 GK in order to force h245Tunneling = TRUE in any case. Everything seems to be working fine, with both H.245 Tunnelling capable terminals (e.g. openphone) and H.245 Tunneling non-capable terminals (e.g. Netmeeting). Now, we hoped to experience some call setups based on the Fast Connect only, but even the supposed Fast Connect capable terminals (e.g. ohphone & openphone) try to perform a (tunneled) H.245 negotiation... even if some capabilieties seems to be agreed by using the fastStart field... ==>Did anyone experience a TRUE Fast Connect setup (with no additional FACILITY messages for H.245 tunneling)? With which terminals?
If you find a device that does no H.245 negotiation at all, that device is not compliant with H.323. FastStart is a hack to get media flowing as soon as possible; it is not a substitute for H.245.
Regards, Chris _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------
------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Charles,
Is this a question to us or an FYI?
To answer the question: 1. An endpoint shall support H.245. 2. An endpoint is not required to initiate H.245 if it does Fast Connect (though it must perform H.245 if the other side initiates H.245) 3. There is text in H.323 that says if one does FC and no H.245, then ReleaseComplete terminates the call. What IG is being referenced? (There is one or more for every version of H.323.)
Paul
----- Original Message ----- From: "Agboh, Charles" Charles.Agboh@EBONE.COM To: ITU-SG16@mailbag.cps.INTEL.COM Sent: Sunday, June 24, 2001 3:05 PM Subject: FW: [OpenH323]Fast Connect & H245 tunneling: do they really work?
-----Original Message----- From: Alain Daigle [mailto:daiglea@memotec.com] Sent: Tuesday, June 19, 2001 3:14 PM To: openh323@openh323.org Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work?
Hi,
H.323v2 seems to indicate that with faststart, the opening of a H245
channel
is optional. Like in the following sections:
8.1.7.2 Switching to H.245 Procedures After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures.
8.2.3 Switching to a Separate H.245 Connection When H.245 encapsulation or Fast Connect is being used, either endpoint
may
choose to switch to using the separate H.245 connection at any time.
And in the H323 implementation guide (from packetizer), there is a section on how a fastconnect call with no h245 channel should be terminated.
Call Termination 2a. The following is how a call shall be terminated if the control channel is not open (Fast Connect was used and no control channel was ever established) but the call-signaling channel is open. Note that, in this case, only the initiating side is required to send ReleaseComplete. I
assume
that it is an oversight that the two cases are not consistent. I also
assume
that the remote EP will close the call-signaling channel upon receipt of ReleaseComplete and consider the call terminated.
But if the remote is asking for a h245 channel (separate or tunneled)
after
the call is established, it's mandatory to support that...
Alain Daigle
----- Original Message ----- From: "Chris Wayman Purvis" chriswaymanpurvis@hotmail.com To: openh323@openh323.org Sent: Tuesday, June 19, 2001 5:11 AM Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work?
Nicola,
(2). We partially overcame the problem modifying the Openh323 GK in order to force h245Tunneling = TRUE in any case. Everything seems to be working fine, with both H.245 Tunnelling capable terminals (e.g. openphone) and H.245 Tunneling non-capable terminals (e.g. Netmeeting). Now, we hoped to experience some call setups based on the Fast Connect only, but even the supposed Fast Connect capable terminals (e.g. ohphone & openphone) try to perform a (tunneled) H.245 negotiation... even if some capabilieties
seems
to be agreed by using the fastStart field... ==>Did anyone experience a TRUE Fast Connect setup (with no additional FACILITY messages for H.245 tunneling)? With which terminals?
If you find a device that does no H.245 negotiation at all, that device is not compliant with H.323. FastStart is a hack to get media flowing as
soon
as possible; it is not a substitute for H.245.
Regards, Chris _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
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 (2)
-
Agboh, Charles -
Paul E. Jones