APC-1524 Uploaded

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Wed Feb 10 13:21:59 EST 1999


Dear all,
I read H.450.8 and I have to agree with Linh. It is not clear why we
need another method to create a conference. If there are problems in the
current method we can fix it. The benefit of the H.323 method is that
you do not need to support h4501SupplementaryService APDUs to create an
ad hoc conference and it achieves the same purpose.
Thanks
Roni Even

**********************************************
Roni Even
VP Product Marketing
Accord Video Telecommunication
Email: roni_e at accord.co.il
Tel: +972-3-9251412
Fax: +972-3-9211571
***************************************************

> -----Original Message-----
> From: Truong Hong-Linh [SMTP:ctNotes at ZURICH.IBM.COM]
> Sent: Wednesday, February 10, 1999 3:02 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      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
> 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



More information about the sg16-avd mailing list