Comments to draft H.450.8

[Truong Hong-Linh]

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 at zurich.ibm.com
IBM Zurich Research Laboratory        tel  : +41 1 724 8434
CH-8803 Rueschlikon / Switzerland   fax  : +41 1 724 8955