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@xxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
