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

Horvath Ernst ernst.horvath at SIEMENS.AT
Thu Mar 22 10:57:42 EST 2001

Frank, Roni et al.,

I like Roni's summary. In my opinion the procedures (in section 8) are clear
enough. But section 6.2 talks about terminal functionality, and this got out
of line with new options added over time. How about the following guidelines
for improving on the text in 6.2.8:

1. All terminals shall support H.245 control, as far as required by the
terminal type (e.g. annex-F-SETs need only a subset for fastStart).

2. Except for SETs, a terminal shall be "able" to open an H.245 control
channel at any time during a call.

3. Encapsulation/tunneling may be used instead of the H.245 control channel
if supported at both ends.

4. The terminal shall associate exactly one H.245 "session" with each call,
but the transport method for the H.245 control information can be chosen as
desired and also changed during a call (fastStart / tunnel / H.245 control
channel - the rules for switching from one method to another are given in
section 8).

Ernst Horvath
Siemens AG

> -----Ursprüngliche Nachricht-----
> Von: Frank Derks [mailto:frank.derks at PHILIPS.COM]
> Gesendet am: Donnerstag, 22. März 2001 15:03
> An: ITU-SG16 at mailbag.cps.INTEL.COM
> Betreff: Re: Conflicting text in H.323 concerning the requirement for
> esta blishing a H.245 control channel??
> 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
> 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 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. 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) (
> 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

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list