please forgive my ignorance and lateness to the thread : one of the worries that I always have with using something like ARI to do billing etc is that there is always a possibility of the ARI application being down when such events occur. Can ARI events be logged to a database (much like the cdr and manager events can) internally within asterisk ? If there were multiple ARI listeners or db loggers (for redundancy purposes), does an ARI event contain a unique id / guid so we can tell if that event has been already processed ? Julian On 3 January 2014 02:56, Joshua Colp <jcolp at digium.com> wrote: > Alistair Cunningham wrote: >> >> >> 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. > > > From the perspective of the transfer events you'll get full details about > everything involved. Who did the transfer, what type, the bridge involved, > the channels transferred, where. The ARI application can interpret these and > do what it wants with them. > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: www.digium.com & www.asterisk.org > > _______________________________________________ > asterisk-app-dev mailing list > asterisk-app-dev at lists.digium.com > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev -- Julian Lyndon-Smith IT Director, Dot R Limited "I don?t care if it works on your machine! We are not shipping your machine!? The kangaroo dances: http://www.youtube.com/watch?v=MAWl5iYOaUg
