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>


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

Thanks for the feedback,


RJ Auburn
CTO, Voxeo Corporation

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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:49 UTC