Reps and interrupted dinners

3 Feb 1999


      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 >>

hlt＠zurich.ibm.com

tags (0)

participants (1)