- From: RJ Auburn <rj@voxeo.com>
- Date: Thu, 27 May 2004 07:57:21 -0700
- To: "Emeka Mosanya" <emeka.mosanya@ubicall.com>
- Cc: <www-voice@w3.org>
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 UTC