I've done this with RabbitMQ. I don't send any messages until the 180 ringing comes through (and then in dialog:start and dialog:end), but there's no reason why you couldn't do it on the initial INVITE.

Although the advice you received to do it asynchronously is absolutely spot-on, I currently don't in one of my clusters, and it works fine inline. AMQP is quick, and the server will acknowledge the message as soon as it is received from Kamailio, whether or not it has been processed on the remote end, so there isn't much delay added.

You do of course want to make sure the AMQP server is available if you aren't taking advantage of async processing. I use a 3 node RabbitMQ cluster for high availability, and it is actually on a different continent than one of my Kamailio proxies. That of course does add some additional latency, but it still works fine.

I should change it to asynchronous though.

Ruel Tmeizeh RuhNet Consulting https://ruhnet.co

From: Anthony Wittig awittig@mangovoice.com Sent: Dienstag, 21. Februar 2023 16:56 To: sr-users@lists.kamailio.org Subject: [SR-Users] Call History

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). 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?

Thanks!

Anthony Wittig Mango Voice Developer

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

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 awittig@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