I'm now forwarding the emails relating to that thread to your ITU account. Is that OK for you or do you prefer your Databeam one? Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 03.02.99 17:34 ---------------------------
Chris Purvis CPurvis@Madge.com on 03.02.99 16:49:50
To: Hong Linh Truong/Zurich/IBM, Klaghofer Karl ICN IB NL IP 7 Karl.Klaghofer@vs.siemens.de, Korpi Markku USA markku.korpi@icn.siemens.com, "'wiryaman santo (VideoServer)'" swiryaman@VideoServer.com, "'Kumar Vineet (Intel)'" vineet.kumar@intel.com, "'Freundlich Glen'" ggf@lucent.com, "'Walker Dave (Mitel)'" dave_walker@mitel.com, "'Ruditsky Sasha (RadVision)'" sasha@radvision.rad.co.il cc:
Subject: Reps and interrupted dinners
Santo, Linh et al,
Sorry for the subject line change, but this is a bit of a side-track (however interesting) from the main stream discussion...
My feeling is that I would wish to be able to set up policy for my endpoint that to make it ignore these messages (or at least ask me very nicely) if they were about to involve me in spending large amounts of money. The routeCallToMC FACILITY message is for the express purpose of telling me that the endpoint I've tried to call is already in a conference, and how to join it. Possible ways that I can see of adding extra endpoints to an extant call in Santo's scenario are: 1. Use Linh's method, and allow the man with the interrupted dinner to put the phone down and then ring it again. 2. Something like Karl's H.450.8-proposal that allows us to "replace" one call with another. This would need to be combined with Linh's comments in order to avoid 1. 3. Give the "rep" in that scenario an endpoint containing an MC, or a clever enough gatekeeper (one containing, or "with access to" an MC) that any calls can be made at the rep's expense. In this scenario any call control signalling (H.225 and H.245) to the interrupted-dinner-person are routed via the rep's GK, and these stay open when the GK pulls in the MC.
Of these, 1. is inconvenient to the user, 2. requires some standardisation work, and 3. requires the annoying rep to spend money. Any preferences?
Regards, Chris
-----Original Message----- From: hlt@zurich.ibm.com [mailto:hlt@zurich.ibm.com] Sent: 03 February 1999 1:20 To: Klaghofer Karl ICN IB NL IP 7; Korpi Markku USA; 'wiryaman santo (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha (RadVision)'; hlt@zurich.ibm.com; Chris Purvis Subject: RE: Draft H.450.8 Conference out of Consultation Suppl. Serv. for H.323
My apologies. I forget to cc: to the whole group my reply to Santo. Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 03.02.99 14:18 ---------------------------
From: Hong Linh Truong on 03.02.99 10:00
To: Santo Wiryaman swiryaman@VideoServer.com cc:
Subject: RE: Draft H.450.8 Conference out of Consultation Suppl. Serv. for H.323 (Document link not converted)
Santo,
Although I do not know how the charging model for IP telephony will look like, I do agree with the excellent point you made below. Assuming that in general the calling party has to pay for the call, then any conferencing approach that modifies the setup direction of a call will run into that unacceptable problem. Unfortunately, both conferencing approaches we have identified so far do modify the direction of the calls.
Let me take your scenario and modify it a little bit. Instead the agent conferencing-in his boss, you conference-in your wife. In this case you'd be fine with the Facility "re-route to MC" but not with 450.8. Using 450.8 you'd get a bill at the end of the month ;-).
To solve the above problem, we need an approach that DO NOT modify the setup direction of the calls. Fortunately, we can build such an approach based on the current H.323. Endpoint A (the one that wants to create a conference with B and C) has now to handle a call differently based on whether it is an incoming or an outgoing call (from A's view point). If it was an incoming call, then A will send out a FACILITY "re-route to MC". If it was an outgoing call, then A has to request the MC to invite the corresponding endpoint. H.323 Figure 28 shows how the invitation procedure looks like.
Any other opinions?
Regards,
Linh
Santo Wiryaman swiryaman@VideoServer.com on 02.02.99 17:02:55
To: Klaghofer Karl ICN IB NL IP 7 Karl.Klaghofer@vs.siemens.de, Korpi Markku USA markku.korpi@icn.siemens.com, "'wiryaman santo (VideoServer)'" swiryaman@VideoServer.com, "'Kumar Vineet (Intel)'" vineet.kumar@intel.com, "'Freundlich Glen'" ggf@lucent.com, "'Walker Dave (Mitel)'" dave_walker@mitel.com, "'Ruditsky Sasha (RadVision)'" sasha@radvision.rad.co.il, Hong Linh Truong/Zurich/IBM, Chris Purvis CPurvis@Madge.com cc:
Subject: RE: Draft H.450.8 Conference out of Consultation Suppl. Serv. for H.323
Karl,
I share your concern on the fact that not all endpoints support the H.225.0 FACILITY "re-route to MC". Even though Linh pointed out that this is mandatory, I envision a general deployment problem with these "re-route to SOMETHING" messages.
The problem I see is that the receiver of this message is to make a new call somewhere else, presumably automatically, without the user's consent. I can imagine the following scenario:
- I am at home eating my dinner
- The phone rings and it was a courtesy call from my long
distance carrier to check if I am satisfied with their service 3. My dinner interrupted, I am already somewhat annoyed. However, while the rep is on the phone, I might as well ask if they have special deals for calling Switzerland 4. The rep is not familiar with any, so he conferences-in his manager using the "re-route to MC" message 5. The conference call went OK, but at the end of the month, I got this charge for calling an MCU in the Cayman Island
As an engineer, I can see how the scheme might work, but as a consumer, I would have problem with the above scenario. Even if the endpoint prompts me for authorization to call the MCU, I would probably said no and continued with my dinner.
I can see consumer pressure for an option to block the "re-route to SOMETHING" messages.
Any opinions?
Regards,
Santo Wiryaman VideoServer Inc. +1.781.505.2348
-----Original Message----- From: Klaghofer Karl ICN IB NL IP 7
[SMTP:Karl.Klaghofer@vs.siemens.de]
Sent: Monday, February 01, 1999 11:36 AM To: Korpi Markku USA; 'wiryaman santo (VideoServer)';
'Kumar Vineet
(Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha (RadVision)'; 'hlt@zurich.ibm.com'; Chris Purvis Subject: AW: Draft H.450.8 Conference out of Consultation Suppl. Serv. for H.323
To all "conference participants":
I had not yet answered the last comments/proposals
received on Draft
H.450.8. The attached memo provides a summary.
Thanks for your contributions so far.
Regards, Karl
<<H4508comments990201.doc>>
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@vs.siemens.de
<< File: H4508comments990201.doc >>