W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2004

Re: HOLD, RETRIEVE, Explicit Call Transfer

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 27 May 2004 07:57:21 -0700
Message-Id: <2835B0D2-AFEE-11D8-88FC-000D932A0CEC@voxeo.com>
Cc: <www-voice@w3.org>
To: "Emeka Mosanya" <emeka.mosanya@ubicall.com>

Emeka,

Thanks for these comments. The working group has recorded these and 
will be reviewing them in an upcoming teleconference.

Thanks for the feedback,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800


On May 19, 2004, at 05:51, Emeka Mosanya wrote:

>
> Dear all,
>
> After reviewing CCXML Version 1.0 Last Call Working Draft,
> I was surprised to not find any construction for the call
> OnHold and Retrieve call control functionality.
>
> This functionality is largely used in directory dialing
> application where we want to put the caller on hold while
> we are dialoging with the called party, for example during
> interactive call filtering IVR.
>
> Without OnHold and Retrieve functionality, we are forced
> to use the first port to play the waiting music and open
> a new port to contact the called party, using two often
> expensive port, when only one would be required.  This
> correspond to the Personal Assistant example (11.3).
>
> Moreover, again in directory dialer applications, if the
> called party accept the call, we must connect the caller
> and the called party, and release corresponding telephony
> resources.  Therefore, no telephony resources are used when
> the two call party are talking to each other (excepted switch
> or PBX resources). This correspond to the call transfer part.
>
> Current CCXML model assume that all everything works using
> tromboning/bridging.  In my experience, our customers are
> very sensitive when we talk about the quantity of used port.
> Often, they do not like tromboning.
>
> Proposition:
>
> One could express the OnHold, Retrieve, and Explicit Call
> Transfer by allowing several Connection to share the same
> media resource. This can be expressed in ccxml by adding
> the notion of hold group (Other term than "hold group" could
> fit).
>
> Now, by adding few attribute to existing <unjoin>,
> and <createcall>, and by extending the semantic of join, we
> have the required behaviour.
>
> <unjoin>
>   hold: optional boolean that indicate if the Connection that is
>         unjoined should be put on hold.  Note: this correspond to
>         the hook-flash function you may encounter on your handset
>   holdid: optional id that identifies the "hold group".
>
> <createcall>
>   holdid: optional reference to an existing "hold group" id that
>           indicate that the new call will share the unique media
>           resource associated with this "hold group".  Note: this
>           correspond to dialing a new correpondant after you have
>           made a hook-flash, for example. The on-hold connection
>           and the newly created connection share the same telephony
>           resource.
>
> <join>
>   Added semantic:
>     - if the two Connections belong to the same "hold group",
>       then join the two connections at switch/PBX level (no bridging).
>       The two connections are considered as disconnected at ccxml
>       engine level.
>     - if the two Connections do not share the same telephony resource,
>       retrieve the Connection(s) that are on-hold and join them as
> usually.
>
>
> Hold, Retrieve and Transfer are feature that are really important to
> company building directory dialer.  Without them, ccxml loose most of
> its interest.
>
>
> Best regards,
>
>
> Emeka Mosanya
> ---
> Emeka Mosanya, Ph.D               Ubicall Communication s.a.
> VP Engineering                    http://www.ubicall.com
> mobile: +32 477877372             fixed: +32 65 321534
>
>
>
>
>
>
>
>
Received on Thursday, 27 May 2004 10:57:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:59 GMT