Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??

Frank Derks frank.derks at PHILIPS.COM
Thu Mar 22 09:03:24 EST 2001


Roni (et al.),

I would say that what you are saying is pretty much how I initially thought
things were supposed to work (before I started this discussion;-0). The
downside is that this brings us back to square one, and I do not want to
restart the discussion.

I would like to ask Paul and Chris to come up with how we're going to avoid
future confusion. Would it be a good idea to change the wording in 6.2.8 to:

"The endpoint shall establish at most one H.245 Control Channel for each call
that the endpoint is participating in."

Regards,

Frank





Roni_e at ACCORD.CO.IL@SMTP at MAILBAG.INTEL.COM on 22-03-2001 13:55:44
Please respond to Roni_e at ACCORD.CO.IL@SMTP
Sent by:        ITU-SG16 at MAILBAG.INTEL.COM
To:     ITU-SG16 at MAILBAG.INTEL.COM@SMTP
cc:
Subject:        Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Classification:

all,

I will try to give my view and history of the H.245.
Before fast connect the issue of H.245 was simple. It is mandatory and after
call setup the H.245 process with Master-slave and caps exchange was the
only way. Annex F gave an option for a simple terminal with no h.245
mandatory support. This is the text in 6.2.8. When we added fast connect we
opened the door for simple calls that finished the connection and
establishment of media channels and did not need any more control to delay
or skip H.245 and described in 8.1.7.2. Any side can initiate the opening of
H.245 during the call. I have to agree that 6.2.8 is very strong about H.245
channel establishment. The reason for having it this way is to prevent
implementers from understanding that an H.323 compliant endpoint can be
implemented without support of H.245 if they are doing fast connect!!!.

Call termination, before fast connect, was done through H.245. The call
signaling channel can be closed before but H.245 must stay open during the
call. 8.1.7.2 explain what to do if H.245 was not open (call signaling must
stay open until call finish or opening of a separate H.245 channel) (
8.1.7.2 2nd paragraph "When a call is established using the Fast Connect
procedure, both endpoints shall keep the Q.931 Call Signaling Channel open
until either the call is terminated or, for compatibility with older
endpoints, until a separate H.245 connection is established.")

I think that is what H.323 says. If you feel that this is not clear from the
text give me a suggestion how to change it. It can be submitted to the next
meeting (I am the new editor for H.323 V5).
Regards
Roni Even

-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at isdn-comms.co.uk]
Sent: Thursday, March 22, 2001 1:27 PM
To: Roni Even; Paul Jones
Cc: ITU-SG16 at mailbag.cps.INTEL.COM
Subject: Re: Conflicting text in H.323 concerning the requirement for
esta blishing a H.245 control channel??


Roni, Frank, Paul Jones et al,

Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right

all along in saying there is a conflict.  8.1.7.2 saying that a device "may"

establish an H.245 session at any point during a call is, I would argue,
clearly at odds with 6.2.8 stating that such a session "shall" be
established.  After all, having not bothered to bring one up until an
instant before the end of the call (clearly permitted by 8.1.7.2), why
create one at that stage (except because 6.2.8 tells you to...)?

There is an alternative reading: the implication of 6.2.8 is that some sort
of H.245 session should start immediately (the start and end are the only
"special" times in an ordinary call, so if you must start one it's pretty
well a requirement to do it immediately).  What I don't recall is whether
it's permitted to drop an H.245 session during a call.  I think it is.  So
is there an alternative reading, saying "start the H.245 channel at the
beginning of the call, but you may drop and restart it as you like during
the call"?
I don't like this reading, though, it's probably the worst of all worlds.

However I don't like the delay of setting up an H.245 session being added to

the time taken to transmit the first DTMF tone in a call either...

Paul,

I think this really needs tidying up one way or another - I think it's a job

for the implementors guide...  Consensus currently seems to be against me,
and to be that we should dump the relevant text in 6.2.8.

Regards,
Chris

Roni Even wrote:

> Chris,
> About your comments
>
> 1. B can make A start H.245 by using facility message with reason
> startH.245. See H.323 8.2.3   Switching to a separate H.245 connection.
> 2. About 6.2.8 I agree that it states the H.245 shall be established, it
> does not say when. The when is mentioned  in 8.1.7.2.
> Roni Even
>
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> Sent: Wednesday, March 21, 2001 3:31 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Conflicting text in H.323 concerning the requirement for
> esta blishing a H.245 control channel??
>
>
> Roni,
>
>
>
>> H.323 mandates the support of H.245 for end points that comply with the
>> standard. It does not mean, when using fast connect that it must be open
>> immediately but can be opened at a later stage by any side.
>
> Except that it states exactly the opposite in the section under
discussion.
>
> Also, consider the following scenario:
> Two endpoints, A and B.  B does not support tunnelled H.245.  A calls B,
> without giving any H.245 address in its Setup message.  B accepts the call
> on the basis of fastStart.  No H.245 channel is set up, as you suggest.
> Suppose now B wishes to send a UII (or any H.245 message) to A.  It can't.
> It can't set up the H.245 channel.  A could set it up, but doesn't see the
> need.
>
>
>> The reason for
>> mandating H.245 is to supply a control channel and is important for
>
> gateways
>
>> and MCUs as well as for control functions in point to point calls such as
>> Video fast updates. H.323 annex F defines a simple end point that has
>
> H.245
>
>> support as optional.
>> I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you
>> have to support it but not to actually open it as in simple fast connect
>> calls.
>
> But 6.2.8 does not mean that.  It clearly states that an H.245 channel
SHALL
> be opened.
>
>
>> As for DTMF you can use the DTMF RTP payload to have it in band instead
of
>> H.245.
>
> If the person you're talking to happens to support this.  Of course you
> don't know whether or not it does if you haven't exchanged TCS.
>
> Please let's not break this!
>
> Regards,
> Chris
>
>
>
>> -----Original Message-----
>> From: Agboh, Charles [mailto:charles.agboh at EBONE.COM]
>> Sent: Tuesday, March 20, 2001 6:59 PM
>> To: ITU-SG16 at MAILBAG.INTEL.COM
>> Subject: 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 at ISDN-COMMS.CO.UK]
>>> Sent: Tuesday, March 20, 2001 5:47 PM
>>> To: ITU-SG16 at 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 at PHILIPS.COM]
>>>>> Sent: Tuesday, March 20, 2001 4:40 PM
>>>>> To: ITU-SG16 at 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 at isdn-comms.co.uk on 20-03-2001 15:17:14
>>>>> To:     Frank Derks/HVS/BE/PHILIPS at EMEA2
>>>>> cc:     ITU-SG16 at 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 at mailbag.intel.com
>>>>>
>>>>
>>>>
>>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>>> For help on this mail list, send "HELP ITU-SG16" in a message to
>>>> listserv at 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 at mailbag.intel.com
>>>
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> For help on this mail list, send "HELP ITU-SG16" in a message to
>> listserv at mailbag.intel.com
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> For help on this mail list, send "HELP ITU-SG16" in a message to
>> listserv at 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 at 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 at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list