[OpenSIPS-Users] cdr accounting on opensips restart
Jayesh Nambiar
jayesh.voip at gmail.com
Tue Dec 6 15:09:26 CET 2011
Hi Razvan,
I am not able to patch. I get the following:
patching file dlg_db_handler.c
Hunk #1 FAILED at 789.
Hunk #2 FAILED at 796.
2 out of 2 hunks FAILED -- saving rejects to file dlg_db_handler.c.rej.
This is what I see in dlg_db_handler.c.rej:
--- dlg_db_handler.c (revision 8586)
+++ dlg_db_handler.c (working copy)
@@ -789,6 +789,9 @@
{
int i,j;
+ LM_DBG("Dumping var name: <%.*s> value: <%.*s>\n",
+ name->len, name->s, val->len, val->s);
+
for( i=0,j=0 ; i<name->len ; i++) {
if (name->s[i]=='|' || name->s[i]=='#' || name->s[i]=='\\')
b[j++] = '\\';
I must admit that earlier also I was not able to patch properly but looking
at the patch file I just added the line:
LM_DBG("Dumping var name: <%.*s> value: <%.*s>\n",
name->len, name->s, val->len, val->s);
after int i,j at line 790 in file dlg_db_handler.c and then recompiled.
Anything else I can do for the patch to work properly.
--- Jayesh
On Tue, Dec 6, 2011 at 7:19 PM, Razvan Crainea
<razvancrainea at opensips.org>wrote:
> Hi, Jayesh!
>
> Something is really weird there. I've attached attached a new patch done
> against a fresh copy. Can you please try this one?
>
> Thanks and regards!
>
> --
> Răzvan Crainea
> OpenSIPS Developer
>
>
> On 12/06/2011 01:52 PM, Jayesh Nambiar wrote:
>
> Hi Razvan,
> Here are the logs with Dumping var name:
>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]:
> DBG:dialog:dialog_update_db: inserting new dialog 0x7fa29f2d0708
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <accX_flags> value: <#026>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <accX_db> value: <(>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <accX_leg> value: <>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <accX_core> value: <#006>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <accX_created> value: <G#002ÃN>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]:
> DBG:dialog:write_dialog_vars: var string is <accX_flags##026>(481)
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <carrierChannels> value: <1002>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <carrierChannels> value: <1003>
> Dec 6 17:24:13 dev /usr/local/sbin/opensips[1958]: DBG:dialog:write_pair:
> Dumping var name: <carrierChannels> value: <1007>
>
> Let me know if this helps.
>
> Thanks,
>
> --- Jayesh
>
>
> On Tue, Dec 6, 2011 at 4:32 PM, Razvan Crainea <razvancrainea at opensips.org
> > wrote:
>
>> Hi, Jayesh!
>>
>> Can you please apply the patch I've attached? And then mail me back the
>> log, but this time taken just after OpenSIPS shuts down with an active
>> dialog. The log should contain the following strings:
>>
>> "Dumping var name: "
>>
>> and
>>
>> "var string is <"
>>
>> They should appear before OpenSIPS stops with an active dialog, so
>>
>> --
>> Răzvan Crainea
>> OpenSIPS Developer
>>
>>
>> On 12/06/2011 12:13 PM, Jayesh Nambiar wrote:
>>
>> Hi Razvan,
>> The logs with debug level 9 are pasted here:
>>
>> After restarting I disconnected the call, the dialog matched perfectly
>> but no CDR record.
>>
>> --- Jayesh
>>
>>
>> On Tue, Dec 6, 2011 at 2:50 PM, Razvan Crainea <
>> razvancrainea at opensips.org> wrote:
>>
>>> Hi, Jayesh!
>>>
>>> Yes, I will need extra debugging to see what's happening. Can you
>>> send[1] the log in full debugging, taken after OpenSIPS is restarted?
>>>
>>> [1] pastebin.com
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Răzvan Crainea
>>> OpenSIPS Developer
>>>
>>>
>>> On 12/06/2011 08:13 AM, Jayesh Nambiar wrote:
>>>
>>> Hi Razvan,
>>> The dialogs are definitely loaded on startup and it also matches with
>>> existing dialog. I use this to make sure the dialog is matched in my
>>> script. So even after a restart, I see the Dialog Matched in my syslog.
>>>
>>> if(has_totag()) {
>>> if(match_dialog()) {
>>> log(1, "Dialog Matched");
>>> route(default_relay);
>>> exit;
>>> }
>>> }
>>>
>>> But it is just that the cdr insert does not take place after the restart
>>> !!
>>> My debug level was at 3. Do you want more detailed logs to check??
>>>
>>> Thanks,
>>>
>>> --- Jayesh
>>>
>>> On Mon, Dec 5, 2011 at 7:12 PM, Razvan Crainea <
>>> razvancrainea at opensips.org> wrote:
>>>
>>>> Hi Jayesh,
>>>>
>>>> Can you please check if the dialogs are loaded back after a restart.
>>>> Also, do you see any errors in your log?
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Răzvan Crainea
>>>> OpenSIPS Developer
>>>>
>>>>
>>>> On 12/05/2011 02:31 PM, Bogdan-Andrei Iancu wrote:
>>>>
>>>> Hi Jayesh,
>>>>
>>>> Razvan is checking the code for you and running some tests.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> On 12/03/2011 02:49 PM, Jayesh Nambiar wrote:
>>>>
>>>> Hi Bogdan,
>>>> Just writing to ask if you got a chance to check if this is a bug or
>>>> some error in my config !!
>>>>
>>>> Thanks,
>>>>
>>>> --- Jayesh
>>>>
>>>> On Fri, Dec 2, 2011 at 11:23 AM, Jayesh Nambiar <jayesh.voip at gmail.com>wrote:
>>>>
>>>>> Hi Bogdan,
>>>>> The exact version used is 1.7.1 stable release compiled from src.
>>>>> Output of opensips -V is:
>>>>> version: opensips 1.7.1-notls (x86_64/linux)
>>>>> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
>>>>> SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535
>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>>>> svnrevision: unknown
>>>>> @(#) $Id: main.c 8537 2011-11-08 17:02:11Z bogdan_iancu $
>>>>> main.c compiled on 16:59:52 Dec 1 2011 with gcc 4.4.5
>>>>>
>>>>> The CDR does not survive a restart. Anything else to be enabled or
>>>>> added in the script or to be looked at?
>>>>> Thanks,
>>>>>
>>>>> --- Jayesh
>>>>>
>>>>>
>>>>> On Thu, Dec 1, 2011 at 10:35 PM, Bogdan-Andrei Iancu <
>>>>> bogdan at opensips.org> wrote:
>>>>>
>>>>>> Hi Jayesh,
>>>>>>
>>>>>> If dialog module has restart persistence ( db modes 1, 2 and 3) the
>>>>>> CDRs should survive across a restart. If this is not the case for you, let
>>>>>> me know the exact version of opensips you are running (do "opensips -V").
>>>>>>
>>>>>> Regards,
>>>>>> Bogdan
>>>>>>
>>>>>>
>>>>>> On 12/01/2011 12:28 PM, Jayesh Nambiar wrote:
>>>>>>
>>>>>> Hello All,
>>>>>> I am planning to use CDR accounting in my script starting from
>>>>>> version 1.7 and it looks fine and working as expected. Although I had one
>>>>>> doubt, how do I make sure the CDR accounting still happens if the opensips
>>>>>> is restarted and BYE comes after the restart. I have tried db_mode 3 for
>>>>>> dialog module so that it dumps all the dialogs while shutdown and on start
>>>>>> it fetches the dialog from the DB. This method makes sure the dialog is
>>>>>> matched when BYE comes after the restart but the CDR record is not entered.
>>>>>> Is there any flag or dialog variable that I should set to insert that
>>>>>> value in the table for all dialogs when opensips shuts off so that opensips
>>>>>> knows that the CDR flag was set for this dialog when started again and it
>>>>>> has to insert the record?
>>>>>> Do let me know for any pointers or ideas to get this done.
>>>>>> Thanks in advance.
>>>>>>
>>>>>> --- Jayesh
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bogdan-Andrei Iancu
>>>>>> OpenSIPS Founder and Developer
>>>>>> OpenSIPS solutions and "know-how"
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developer
>>>> OpenSIPS solutions and "know-how"
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20111206/a2fcbb10/attachment-0001.htm>
More information about the Users
mailing list