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.