Reps and interrupted dinners
hlt at zurich.ibm.com
hlt at zurich.ibm.com
Wed Feb 3 11:36:13 EST 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 at Madge.com> on 03.02.99 16:49:50
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 (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: 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