Hi
Using the dialog module to generate CDR for billing.
We have this situation:
Kamailio 'routing' instance, where dialog is used and billing happens. Kamailio 'register' instance.
IC is connected to the routing instance. Customers register to the register instance.
Call originates from 'A' via IC through routing instance to register instance and rings customer 'B'. This times out and 'call forwarding' is engaged by sending the call back to the routing instance with a new RURI containing the call forwarding destination 'C'. An appropriate 'no-answer' Diversion Header is added.
Now we need two different CDR for this scenario (add more CDR if the call is forwarded multiple times)
One from the A to B leg to bill termination fee to the IC carrier. One from B to C to bill the forwarded call with destination 'C' to customer B.
The issue I now face is that I only get the kamailio routing instance to generates one dialogue from B to C despite handling two separate connections.
How could that challenge be solved?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
Kamailio is not a B2BUA. So, the dialog module will only track the early dialog and then later update its to a "normal" dialog. After the end of the dialog the acc module will create the CDR, I think. Just to list some suggestions:
- use a B2BUA (obviously) - add some dialog variables to the CDR to track the call forwarding - switch to transaction-based forwarding and have another component to generate CDRs from those records - of course also the modules could be extended, but this probably needs a bit more discussions
Cheers,
Henning
Hi Henning
Thank you for your help.
Kamailio is not a B2BUA. So, the dialog module will only track the early dialog and then later update its to a "normal" dialog. After the end of the dialog the acc module will create the CDR, I think. Just to list some suggestions:
- use a B2BUA (obviously)
Yes, obviously, but we would love to keep our voice platform simple. We are switching away from a commercial solution supplier which turned out to be very limited in flexibility and unable to solve obvious bugs to an open source solution which we can extend matching our needs. So far very happy with kamailio.
- add some dialog variables to the CDR to track the call forwarding
I was thinking about that. I can successfully count the legs of a call with:
set_dlg_profile("legcounter","$ci"); get_profile_size("legcounter","$ci","$var(legcounter)"); xlog("L_INFO", "$cfg(route): DIALOGUE $ci Leg Counter: $var(legcounter)\n");
So I am indeed considering the possibility to embedd a CDR in a CDR by adding information from each leg to a coma separated string which I keep appending to a dlg_var for each leg.
Then in post-processing of the CDR I could extract that/those embedded CDR and create a propper CDR for each legs.
But I am not sure about the lenght restriction of dlg_var and this sound quite adventurous.
- switch to transaction-based forwarding and have another component
to generate CDRs from those records
Been there, attempted to catch all situation of call forwarding with for example T.38 re-invites and fallbacks from the far side etc. Yes it is looks somehow possible but extremely complicated to correctly match all transaction and reply acc events. As I also need to count and limit the number of concurrent calls per customer, we switched to dialog.
- of course also the modules could be extended, but this probably
needs a bit more discussions
As kamailio is widely used by TSP. I guess I'm not the first facing that requirement. So my hope was that I missed some module or way to accomplish this.