AW: Comments to draft H.450.8
Klaghofer Karl ICN IB NL IP 7
Karl.Klaghofer at VS.SIEMENS.DE
Wed Feb 10 14:20:15 EST 1999
H.450.8 is not a new conference. The draft clearly points out that existing
H.245 conference mechanisms are used, once the central conference is in
place (see e.g. clause 1 of the draft).
H.450 only provides an improved procedure for replacing the existing calls
of a consultation scenario (i.e. a held call and a consulted call) by new
calls so that we end up with point to points calls between an MCU and the
involved endpoints (see FIGURE 2/H.450.8).
The deficiencies of using the FACILITY re-route to MC method (compared to
H.450.8 proposal) for doing such a call replacement we have pointed out
already in clause 8.3.3 of APC-1505. Some could life with such
deficiencies (as you indicated) other may not. We have even included
interaction (fallback) procedures for the case where the MCU does not yet
The current "conference invite" method you are referring to for usage in
conference out of consultation requires multiple SETUP messages at SS-CoC
invocation to be sent from the served endpoint to the MCU for each remote
endpoint the served user wants to invite. With the H.450.8 proposal only one
call is established to the MCU/CUSE. The operation included in the SETUP
contains all information the MCU needs to complete the feature. So, H.450.8
is an improvement also in this respect.
You could start modifying H.225.0 to get similar improvements. This requires
a new H.225 version in the involved endpoints.
To use H.450 for new functionality or for an improved functionality has the
advantage that the endpoints can provide this functionality independent of
the version of their base protocols !
Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7
Hofmannstr. 51, D-81359 Munich, Germany
Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
e-mail: karl.klaghofer at vs.siemens.de
> -----Ursprüngliche Nachricht-----
> Von: Truong Hong-Linh [SMTP:ctNotes at ZURICH.IBM.COM]
> Gesendet am: Mittwoch, 10. Februar 1999 14:02
> An: ITU-SG16 at mailbag.cps.intel.com
> Betreff: Comments to draft H.450.8
> 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
> point by point through your list of defiencies). I fear that having two
> conferencing methods will lead to interoperability problems and confusion
> 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
> that we need in H.323 two conferencing methods? The items you listed in
> 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
> 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
> conference. And I'd feel annoying if I have to. Furthermore, how can I
> 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 22.214.171.124 and 126.96.36.199). You
> 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
> 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 188.8.131.52 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
> From an user's point of view, he/she will get from the MC the information
> 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
> >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
> 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
> we need to think and discuss more carefully about that issue and all of
> impact, and not only for the conference service but also for the other
> >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
> What are you going to do with them? And if needed, why can't we add them
> 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
> 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
> With H.323 version 2 we can already do conferencing, even the way you want
> to have. We do not need H.450.8.
> 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
More information about the sg16-avd