Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Chris,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If that is the case, then the extract from H.323v2 below is misleading(I believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection."
BR, Charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
Control Channel for each call that the endpoint is
participating in."
8.1.7/H.323 never states that when Fast Connect is being
used such a
control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245
procedures.
It would seem that section 6.2.8 should be rephrased to
make clear that
the H.245 control channel shall only be established when
"normal" H.245
procedures are being followed and not in the fast connect case.
Frank
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
>> 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
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
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
Charles,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If that is the case, then the extract from H.323v2 below is misleading(I believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection."
I don't see a conflict between that quotation and what I said. You have a basic point-to-point call quickly. Media flow. Then you set up the H.245 session with all reasonable speed WHILE MEDIA ARE FLOWING. So you get your media channels set up as a result of fastConnect, and THEN negotiate other capabilities, master-slave etc.
Oh, and there's no need for a second TCP connection anyway - use H.245 tunnelling.
Regards, Chris
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
Control Channel for each call that the endpoint is
participating in."
8.1.7/H.323 never states that when Fast Connect is being
used such a
control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245
procedures.
It would seem that section 6.2.8 should be rephrased to
make clear that
the H.245 control channel shall only be established when
"normal" H.245
procedures are being followed and not in the fast connect case.
Frank
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
>> 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
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Frank, Chris, Charles, et al,
I've been involved in discussions like these many times in the past. There are a few things I can recommend, but the most important is: follow what is stated in H.323v4 :-)
H.323v4 still contains ambiguities, I am quite sure. However, we tried to tighten what an endpoint should do. In particular, things like H.245 tunneling is *strongly* recommended. We also have a means of doing Fast Connect and H.245 capability exchange in parallel-- they don't have to follow each other. V4 endpoints are now required to set canMapAlias to true, etc. Of course, we have to support older behavior for backward compatibility, but at the current pace, I expect that V2 devices will be phased out of existence over the next few years: it's always best to look to the newest version of H.323 to get some idea of the "best current practice". While H.323 offers a number of options, we tried to make it clearer in some cases as to what should be done.
I suppose this doesn't necessarily answer any of the questions, but I did want to try to encourage people to look toward version 4. Even if you implement a V2 device, it's wise to consult V4 to make sure that we did not change behavior in V4 that will introduce backward compatibility concerns. Theoretically, there shouldn't be any, but I would hate to see somebody implement H.323v2 *today* and not consider what V4 says about tunneling, fast connect, mapping aliases, etc. There are known race conditions in Fast Connect and H.245. We put language into H.323v4 as advisory text to prevent implementers from making the wrong choice. We carefully crafted that text to ensure that all known endpoints would operate properly, but it would be very bad to see new H.323v2 endpoints enter the market that break the rules spelled out in v4.
In summary, I'd encourage people to read or consult v4-- even if not implementing v4. If there are ambiguities in v4, I'll be more than happy to try to get those clarified.
Paul
----- Original Message ----- From: "Chris Wayman Purvis" cwp@ISDN-COMMS.CO.UK To: ITU-SG16@mailbag.cps.INTEL.COM Sent: Tuesday, March 20, 2001 12:25 PM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If
that
is the case, then the extract from H.323v2 below is misleading(I
believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a
basic
point-to-point call with as few as one round-trip message exchange,
enabling
immediate media stream delivery upon call connection."
I don't see a conflict between that quotation and what I said. You have a basic point-to-point call quickly. Media flow. Then you set up the H.245 session with all reasonable speed WHILE MEDIA ARE FLOWING. So you get
your
media channels set up as a result of fastConnect, and THEN negotiate other capabilities, master-slave etc.
Oh, and there's no need for a second TCP connection anyway - use H.245 tunnelling.
Regards, Chris
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
Control Channel for each call that the endpoint is
participating in."
8.1.7/H.323 never states that when Fast Connect is being
used such a
control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245
procedures.
It would seem that section 6.2.8 should be rephrased to
make clear that
the H.245 control channel shall only be established when
"normal" H.245
procedures are being followed and not in the fast connect case.
Frank
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
>> 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
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
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)
-
Agboh, Charles -
Chris Wayman Purvis -
Paul E. Jones