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).
Regards, Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] Gesendet am: Donnerstag, 22. März 2001 15:03 An: ITU-SG16@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@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 13:55:44 Please respond to Roni_e@ACCORD.CO.IL@SMTP Sent by: ITU-SG16@MAILBAG.INTEL.COM To: ITU-SG16@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com