Santo's problem and H.450.2

hlt at zurich.ibm.com hlt at zurich.ibm.com
Thu Feb 4 02:21:17 EST 1999



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 at intel.com> on 03.02.99 19:05:03

To:   Hong Linh Truong/Zurich/IBM, Klaghofer Karl ICN IB NL IP 7
      <Karl.Klaghofer at vs.siemens.de>, Korpi Markku USA
      <markku.korpi at icn.siemens.com>, "'wiryaman santo (VideoServer)'"
      <swiryaman at VideoServer.com>, "Kumar, Vineet"
      <vineet.kumar at intel.com>, "'Freundlich Glen'" <ggf at lucent.com>,
      "'Walker Dave (Mitel)'" <dave_walker at mitel.com>, "'Ruditsky Sasha
      (RadVision)'" <sasha at radvision.rad.co.il>, Chris Purvis
      <CPurvis at 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 at zurich.ibm.com [mailto:hlt at 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 at 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 at vs.siemens.de> on 03.02.99
18:33:35

To:   "'Chris Purvis'" <CPurvis at Madge.com>, Hong Linh Truong/Zurich/IBM,
      Korpi Markku USA <markku.korpi at icn.siemens.com>, "'wiryaman santo
      (VideoServer)'" <swiryaman at VideoServer.com>, "'Kumar Vineet (Intel)'"
      <vineet.kumar at intel.com>, "'Freundlich Glen'" <ggf at lucent.com>,
      "'Walker Dave (Mitel)'" <dave_walker at mitel.com>, "'Ruditsky Sasha
      (RadVision)'" <sasha at radvision.rad.co.il>
cc:

Subject:  AW: Reps and interrupted dinners


-------------- next part --------------


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 at Madge.com]
> Gesendet am: Mittwoch, 3. Februar 1999 16:50
> An:     'hlt at 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 at zurich.ibm.com [mailto:hlt at 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 at 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 at 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 at VideoServer.com> on 02.02.99 17:02:55
> >
> > To:   Klaghofer Karl ICN IB NL IP 7
> > <Karl.Klaghofer at vs.siemens.de>, Korpi
> >       Markku USA <markku.korpi at icn.siemens.com>, "'wiryaman santo
> >       (VideoServer)'" <swiryaman at VideoServer.com>, "'Kumar
> > Vineet (Intel)'"
> >       <vineet.kumar at intel.com>, "'Freundlich Glen'" <ggf at lucent.com>,
> >       "'Walker Dave (Mitel)'" <dave_walker at mitel.com>,
> > "'Ruditsky Sasha
> >       (RadVision)'" <sasha at radvision.rad.co.il>, Hong Linh
> >       Truong/Zurich/IBM, Chris Purvis <CPurvis at 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 at 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 at 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 at vs.siemens.de
> > >
> > >
> > >  << File: H4508comments990201.doc >>
> >
> >



More information about the sg16-avd mailing list