On 02/01/14 16:20, Joshua Colp wrote: > Greetings everyone and welcome to 2014! > > Now that Christmas and the holidays have passed I thought I would send > this email out to elicit some feedback. > > I'd like to enable transfers in ARI. You may think to yourself "they > were disabled?" and the answer would be yes. The trouble with enabling > transfers is properly conveying that a transfer has occurred to the > parties interested. This is due to the event in question being published > on the bridge involved instead of on the channels. This can be overcome > for ARI though! Have no fear. > > After going through many ideas I've settled on a somewhat simple > solution: If an ARI application is subscribed to *any* object (such as > the bridge OR any channels) involved in the transfer then it receives > the applicable transfer event (blind or attended). The transfer events > will convey the same information as the AMI ones do and will have a > guarantee that only one transfer event is published to the ARI application. > > Thoughts? It's not quite the question you're asking, but I'll weigh in anyway. When implementing this, please bear those writing billing engines in mind. For example, imagine a call comes in from the PSTN to a toll-free number (so the inbound call must be billed). The caller listens to an IVR for 10 seconds, then talks to a person on a locally registered SIP handset for a further 20 seconds. That person then blind transfers them out to a cell phone (and the outbound call must be billed). They talk to the cell phone user for 30 seconds, who uses the # key to attended transfer them to a different cell phone (which is a separate billable outbound call), with the first cell phone user talking to the second for 15 seconds during the attended transfer. The original caller talks to the second cell phone for 2 minutes, then hangs up. The inbound call must be billed for 3:15, the first outbound for 0:45, and the second outbound for 2:15 (ignoring ring times on the outbound calls). Of course, you don't need to implement this logic in Asterisk, but please keep the model of the channels consistent enough that someone writing a billing engine can figure out exactly what call legs they need to bill, and for how long, and when transfers occur which endpoint did the transfer and how. AGI suffered from billable call legs appearing to hang up when transferred (even though they stayed up), making it very difficult to piece together exactly what billable calls occurred when. It would be good to avoid this in ARI. -- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 http://integrics.com/
