Paul, two additional emails on the topic. Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 04.02.99 08:20 ---------------------------
"Kumar, Vineet" vineet.kumar@intel.com on 03.02.99 19:05:03
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" vineet.kumar@intel.com, "'Freundlich Glen'" ggf@lucent.com, "'Walker Dave (Mitel)'" dave_walker@mitel.com, "'Ruditsky Sasha (RadVision)'" sasha@radvision.rad.co.il, Chris Purvis CPurvis@Madge.com cc:
Subject: RE: Santo's problem and H.450.2
The case is: B calls A and a connection is established between A and B. Then A transfers B to C which ends up with a connection between B and C. In this case we agree that things work fine as long as we don't bring in accounting/charging. Since accounting/charging is needed in the real world, we need to bring that in as a new supplementary service. Any ideas ?
Let's look at the charging models in the above case: (i) If B dialed a toll-free number then it is expected that B will not pay for the call even when he is transferred to C. This means that the transferred-to number should also be toll-free. (ii) If B dialed a non toll-free number then the question is whether B should pay for the call when he gets transferred to C. Seems that if A uses a toll-free number to transfer B to C then there is no problem. But if A uses a non toll-free number then atleast the user at B should be informed before the transfer. B can then decide whether to have the call transferred. B can also program his terminal to transfer only local calls as an example here.
My suggestion is that there should be a way to express all these various cases in some document so the accounting model is consistent. But my thinking on this subject is preliminary, so comments are welcome.
vineet
-----Original Message----- From: hlt@zurich.ibm.com [mailto:hlt@zurich.ibm.com] Sent: Wednesday, February 03, 1999 5:44 AM 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: Santo's problem and H.450.2
Dear all,
after having answered Santo's note on the charging problem one may run into when a call is re-routed, it came to my mind that we have the same problem with H.450.2. According to Figures 2 and 8 of H.450.2, if A was calling B and then transfers B to C, then it will ends up with B having to pay for the transferred call B to C!
I don't have time yet to check whether it also the case for H.450.5. Karl and Markku, may be you know immediately the answer?
Regards, Linh
---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 04.02.99 08:20 ---------------------------
Klaghofer Karl ICN IB NL IP 7 Karl.Klaghofer@vs.siemens.de on 03.02.99 18:33:35
To: "'Chris Purvis'" CPurvis@Madge.com, Hong Linh Truong/Zurich/IBM, 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: AW: Reps and interrupted dinners
The issue of charging interactions in conjunction with supplementary services was a complicated topic already in the ISDN and ISO PBX networking. You have to think about charging really on a per supplementary service basis.
For SS-CoC (following H.450.8 approach) it might be the served user (CSSE) that takes over the charges for all calls.
BTW, We actually need a "Advice of Charge" service for H.323, that maps the SCN AOC mesages to H.323 environment for being displayed at the H.323 endpoint to the user.
Regards, Karl
-----Ursprüngliche Nachricht----- Von: Chris Purvis [SMTP:CPurvis@Madge.com] Gesendet am: Mittwoch, 3. Februar 1999 16:50 An: 'hlt@zurich.ibm.com'; Klaghofer Karl ICN IB NL IP 7; Korpi Markku USA; 'wiryaman santo (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha (RadVision)' Betreff: 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:
- 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 >>