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(a)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