Dear Karl,
Thanks for putting together draft H.450.8. In the editors note of section 8.3.3 you re-produced only your own viewpoints. I'm missing at least the points I've made during the private discussion I've had with you and many others. I therefore take the liberty to repeat them here again.
The main concern I've against H.450.8 is that we will have two different ways of doing conferencing, one defined in H.323 section 8.4.3 and one in H.450.8. The two differ only marginally; almost of the conference service defined by H.450.8 can be performed by using the protocols and procedures defined in the current H.323 version 2 (which I will show later on in going point by point through your list of defiencies). I fear that having two conferencing methods will lead to interoperability problems and confusion of the users.
I acknowledge that you have tried to resolve the interoperability problems between the two methods in introducing a fall-back feature which allows an H.450.8 CSSE to talk to an MCU and in using as much as possible existing H.245 procedures, but I'm not sure whether we oversee some.
The problem of users confusion still remains. How should we explain to them that we need in H.323 two conferencing methods? The items you listed in your editors note in section 8.3.3 are in my opinion of minor importance, since they improve only marginally the performance of the service. However, if you insist on having them, then I think that it is better to add them to the current H.323 method instead of inventing a new method which differs very little from the old one.
Let me now go through the points you made in your editors note.
a) The SETUP message from the endpoint A to the MCU does not tell the MCU how many remote users B, C, ... are going to be re-routed to the MCU. I.e. MCU resources may not be reserved appropriately.
I do not see the need for that. The PBX I use here in Zurich (BTW it's a HiCom :-) ) does not require me to input that information any time I start a conference. And I'd feel annoying if I have to. Furthermore, how can I know a-priori how many participants I'll have in my ad-hoc conference?
b) The SETUP message from the endpoint A to the MCU does not tell the MCU the addresses of the parties to be re-routed. The MCU may have to accept any re-routed call (security issue ?).
If security is really a concern, then I'd use other means e.g. H.235 to protect my conference instead of sending an unprotected list to the CUSE. BTW if you don't like or have problems with the FACILITY "re-routeToMC", then you can still let the endpoint which wants to create the conference INVITES the participants (using H.323 clauses 8.4.3.2 and 8.4.3.5). You will then end up with exactely what you want to achieve in H.450.8!
c) The served user A does not get feedback from the MCU in CONNECT message whether the intended feature can be supported by the MCU (no acknowledgement in CONNECT).
Which intended feature you are talking about here?
d) Although FACILITY message itself is mandatory in H.225.0, not every endpoint may support the "Facility re-route to MC" method and thus, not every endpoint may participate in SS-CoC as remote endpoint. A remote endpoint may intentionally block Facility re-route messages in general for e.g. security reasons.
e) With H.450.8, the remote endpoints receive incoming H.323 calls from the MCU (i.e. the MCU establishes the calls). With H.450.8 the remote endpoints do not necessarily have to support H.450.8 and can still participate in SS-CoC (i.e. the confEstablish Invoke APDU may be ignored).
Again, if you don't like the FACILITY message, you can use the already defined H.323 INVITATION method to add the participants to the conference. In this case -as you wish- the remote endpoints do not have to support FACILITY "re-routeToMC". And in addition to that you even do not have to implement H.450.8 to create a conference. You just need to implement H.323 version 2!
f) If the "Facility re-route to MC" is supported by the remote endpoint, H.323 clause 8.4.3.7 allows different options, e.g. to immediately clear the call to the served endpoint A. g) If the remote endpoint immediately clears the call, the served endpoint A would not receive any feedback whether the remote endpoint
can support the request.
h) If the remote endpoint immediately clears the call, the served endpoint A would not receive any information about a possible unsuccessful call establishment from the remote endpoint to the MCU, and thus the call may be lost. i) If the remote endpoint B would NOT immediately clear the call and the call establishment from the remote endpoint to the MCU fails, there is not signal in H.225.0 to inform the served endpoint A.
I don't see the need for an explicit confirmation in all of the cases above.
From an user's point of view, he/she will get from the MC the information of
who are on the conference and therefore can derive out of that information which calls have failed. And if the H.323 invitation method is used, the information on whether the invitation succeeds or not is more than explicit.
j) It is the remote endpoint and not the remote endpoint user - that establishes the call to the MCU. This may result in the remote endpoint being charged for the call (which may not be acceptable to the remote endpoint user).
The invitation method could be used to avoid that. But, as discussed within our private conversation, the charging issue is an important one and also affects the transfer feature defined in H.450.2. I don't agree that we can resolve the charging issue in just letting the MCU establishing the calls. There are situations in which I don't want to pay for the others just because I'm the one who calls the conference. I believe we need to think and discuss more carefully about that issue and all of its impact, and not only for the conference service but also for the other ones.
k) The MCU does not provide detailed conference notification information to the endpoints. In H.450.8, conference notification (conferenceIndication Invoke APDU) is provided to all conference participants (containing e.g. alias addresses, names, endpoint types,
status, etc.).
The alias addresses can be requested from the MC using H.245 Terminal ID Request. For the other information, I don't understand why do you need them. What are you going to do with them? And if needed, why can't we add them to the H.245 MC Terminal ID response?
l) A terminal has to ask for receiving a list of conference participants (H.245 terminalListRequest). In ISDN and PBX networking, it is the entity containing the conference bridge (i.e. the CUSE) that provides information about the conference participants. Due to this different function split interworking with SCN may be more difficult.
But it eases the interworking with other H.32x conferencing systems. It is my understanding the H.245 is designed for that aim.
m) Missing signalling elements as identified in different items above could be added to H.225.0 or H.245. However, this would create new versions of these standards. The endpoints participating in SS- CoC would have to be of a certain H.323/H.225.0/H.245 version (backwards compatibility problem). Still, there would be the problem of not all endpoints supporting the "Facility re-route to MC" method.
See my comments above on the missing items. Also, why is adding something to H.323/H.225/H.245 causing backward compability problem? The items you want to add can be ignored by an endpoint that do not understand them, but we still can convene a conference.
n) With H.450.8, the base standards H.323, H.225.0 and H.245 are not
affected.
With H.323 version 2 we can already do conferencing, even the way you want to have. We do not need H.450.8.
Regards, Linh ---------------------------------------------------------------------------- ------------------------------------------------------------------- TRUONG Hong Linh hlt@zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955