[SR-Users] No CDR is written when dialog timeouts
miconda at gmail.com
Wed Apr 15 17:44:33 CEST 2015
Actually there is nothing special to rely on what so ever prerogatives
in this case. Writing cdrs based on dialog module was added by 1&1 long
time ago (iirc) and they have couple of millions of subscribers and tons
of calls, so this approach might have been better for them from various
reasons. In big telcos, cdrs are aggregated from many sources, and a lot
of nodes collect CDRs just for statistics or monitoring.
The fact is that the dialog can be discarded on timeout without sending
bye, being the default behaviour -- in this case the cdr is produced.
When enabling to send bye, the cdr is not produced -- it doesn't seem to
be anything more clear that this is a bug.
I rely on transaction accounting (acc alone), finding it more flexible
to store various events, even during the call. I guess most of the
people do the same in a proxy. On the other hand, dialog module adds a
call-stateful proxy layer, which I use extensively for limiting active
call as well as terminating on timeout with byes. But like you, I write
the stop event for cdrs from tm local request event.
On 15/04/15 17:25, Alex Balashov wrote:
> Fair enough. It is your prerogative to take a definitive stance on the
> issue. I was just voicing personal view that truly complete accounting
> can only be done from SIP message-oriented perspective in software
> that does not formally have a dialog layer.
> Alex Balashov | Principal | Evariste Systems LLC
> 303 Perimeter Center North, Suite 300
> Atlanta, GA 30346
> United States
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> Sent from my BlackBerry.
> *From: *Daniel-Constantin Mierla
> *Sent: *Wednesday, April 15, 2015 10:59
> *To: *Kamailio (SER) - Users Mailing List
> *Reply To: *miconda at gmail.com
> *Subject: *Re: [SR-Users] No CDR is written when dialog timeouts
> Looks like the topic diverged in side discussion, irrelevant to the issue.
> The report was related to the fact that the dialog+acc is not
> recording the CDRs when sending the BYE on timeout. That is obviously
> an issue because there is dedicated functionality for this case. I am
> not the original developer of the feature, but it appears that it
> covered the case when dialog was not configured to send the BYE on
> timeout, just silenty discard the associated structure. So this has to
> be fixed. It is no relation with what proxy can do or not, sending BYE
> at the end of the dialog is not breaking anything in the existing
> dialog, it just terminates it on both sides.
> On 15/04/15 16:45, Alex Balashov wrote:
>> Hook, route, whatever you want to call it. The bottom line is that
>> you cannot rely on the proxy's dialog layer, already a tenuous
>> concept inasmuch as it's implemented strictly on top of transaction
>> state specifically and derived solely from SIP signalling generally,
>> to expose to you all conceivable outcomes, including outcomes that do
>> not conform to a standard transition of dialog states.
>> The dialog module is just a tool. It cannot replace the fundamentals.
>> Alex Balashov | Principal | Evariste Systems LLC
>> 303 Perimeter Center North, Suite 300
>> Atlanta, GA 30346
>> United States
>> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>> Sent from my BlackBerry.
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio World Conference, May 27-29, 2015
> Berlin, Germany - http://www.kamailioworld.com
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users