[asterisk-app-dev] ARI + Call Transfers

[Naftoli Gugenheim]

It would be in interesting if the events endpoint would be similar to
couchdb's changes endpoint, where IIRC you can ask for all the events since
a given point in time.
 On Jan 3, 2014 12:51 AM, "Julian Lyndon-Smith" <asterisk at dotr.com> wrote:

> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140106/7b350602/attachment.html>