Hello, jumping in to address some topic that was not explicitly addressed from the initial mail -- see it inline, at the end.
On 21.02.23 18:13, Alex Balashov wrote: > There are innumerable ways to do that. If going with your chosen AMQP broker > approach, just do it in an async fashion, using either this, > > https://kamailio.org/docs/modules/5.6.x/modules/async.html > > or this: > > https://kamailio.org/docs/modules/5.6.x/modules/rtimer.html > https://kamailio.org/docs/modules/5.6.x/modules/mqueue.html > > Using this kind of approach: > > https://www.mail-archive.com/sr-users@lists.kamailio.org/msg18436.html > https://www.mail-archive.com/sr-users@lists.kamailio.org/msg18437.html > > In essence, you kick your CDR events and interactions with your AMQP broker > to push them to it over to an outside set of worker processes that do not > block SIP workers that process SIP messages. Therefore, this will not > interfere with call processing. Most sensible call accounting mechanisms are > async because generating CDRs (call detail records) is not in the critical > path of call setup and does not need to be wired in series. > > -- Alex > >> On Feb 21, 2023, at 10:55 AM, Anthony Wittig <awit...@mangovoice.com> wrote: >> >> Hello, >> >> I'd like to start tracking a call history/log as soon as I receive a call. >> I'd like the customer to be able to see that there's an incoming call to one >> of their numbers in real time. >> >> I'm thinking of using the RABBITMQ Module to manually emit an event from my >> main route when I receive an INVITE. Is that a bad idea? What if the broker >> isn't located on the same host (latency/availability)? I don't want to >> negatively affect the call processing. >> >> I was looking at the Dialog Module and it has three event routes: >> * event_route[dialog:start] >> * event_route[dialog:end] >> * event_route[dialog:failed] >> >> It's really close to what I want, but I'd like to capture the dialog before >> it starts (Unconfirmed or Early). There are no event routes from dialog module because of its design that completes the internal structures when the dialog is answered, but also dialog processing can be initiated later in config processing. But, coming back to unconfirmed/early states, these correspond to processing of initial INVITE in request_route or provisional (100-199) replies in reply_route/onreply_route. >> Maybe another option is to scan the Dialog table with an external process >> and emit events from there. >> >> Has anyone had success in creating a realtime call history? Is there a >> better way to go about doing so? I did it many times, even without dialog module, just have to think what is the sip request/response corresponding to various states of a dialog, if you do record-routing, all of them come Kamailio. Alex has good point on trying to push out asynchronously, a decision that matters a lot in relation with the latency expected to the backend (eg., database, http api server, ...) and desired processing capacity. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
