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(a)intel.com> on 03.02.99 19:05:03
To: Hong Linh Truong/Zurich/IBM, Klaghofer Karl ICN IB NL IP 7
<Karl.Klaghofer(a)vs.siemens.de>, Korpi Markku USA
<markku.korpi(a)icn.siemens.com>, "'wiryaman santo (VideoServer)'"
<swiryaman(a)VideoServer.com>, "Kumar, Vineet"
<vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>,
"'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, "'Ruditsky Sasha
(RadVision)'" <sasha(a)radvision.rad.co.il>, Chris Purvis
<CPurvis(a)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(a)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(a)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(a)vs.siemens.de> on 03.02.99
18:33:35
To: "'Chris Purvis'" <CPurvis(a)Madge.com>, Hong Linh Truong/Zurich/IBM,
Korpi Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo
(VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar Vineet (Intel)'"
<vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>,
"'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, "'Ruditsky Sasha
(RadVision)'" <sasha(a)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(a)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:
> 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(a)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(a)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(a)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(a)VideoServer.com> on 02.02.99 17:02:55
> >
> > To: Klaghofer Karl ICN IB NL IP 7
> > <Karl.Klaghofer(a)vs.siemens.de>, Korpi
> > Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo
> > (VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar
> > Vineet (Intel)'"
> > <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>,
> > "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>,
> > "'Ruditsky Sasha
> > (RadVision)'" <sasha(a)radvision.rad.co.il>, Hong Linh
> > Truong/Zurich/IBM, Chris Purvis <CPurvis(a)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:
> >
> > 1. I am at home eating my dinner
> > 2. 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(a)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(a)vs.siemens.de
> > >
> > >
> > > << File: H4508comments990201.doc >>
> >
> >
