[OpenSIPS-Users] CDRTool Prepaid and Radius don't match
Douglas Lane
doug at wd.co.za
Mon May 10 21:23:33 CEST 2010
Hi Adrian,
Think I found one of the bugs.
My failure_route block was looking at the response codes, and if it
didn't meet a certain list of codes, the logic went on to call
end_media_session(), and exit the logic. I've put in another if
statement to check if 491 is received, and if so, to just exit, rather
than calling end_media_session().
I'm hoping this will solve the issues.
Your input would be greatly appreciated.
Thanks
Doug
On 2010/05/09 8:18 PM, Adrian Georgescu wrote:
> The best direction would be to investigate the behavior of the dialog
> module, call control relies on it. It could be that there are cases
> incorrectly dealt with by their combination or maybe is simply your
> configuration or network topology, hard to tell.
>
> Adrian
>
> On May 9, 2010, at 7:32 PM, Douglas Lane wrote:
>
>
>> Hi Adrian,
>>
>> Log file is around 3GB per day.
>>
>> I've made a change to the library/rating.php file for the specific
>> prepaid user will fall under the $force argument, and if the
>> active_sessions don't match, will still debit the balance accordingly.
>> That seems to have fixed things (although I have to have a process
>> running at the end of each day that populates the blank information
>> from
>> the session that didn't exist in active_sessions).
>>
>> Anyway, what I've now noticed is I'm still getting a few calls in
>> radius
>> but not in prepaid_history, but all these calls have double INVITEs.
>>
>> What I mean by this is, the log file will show the first invite, and
>> opensips does its thing, then while opensips is waiting for the call
>> setup from the pstn, the client's system resends the same invite
>> again,
>> opensips then replies with a 491 - session already in progress.
>>
>> I have a funny feeling this is causing things to go a bit wonky, as
>> then
>> naturally the UA will CANCEL the second invite, while the first is
>> being
>> connected. I think this is why CDRTool doesn't know about it, as it
>> gets
>> a call from opensips telling it that the session has been cancelled.
>>
>> Correct me if I'm wrong here? If I am correct, what might be the best
>> way to combat this? I think once this is fixed, it might fix the other
>> issue that I had to hack rating.php for.
>>
>> I appreciate the input.
>>
>> Thanks
>> Doug
>>
>>
>> On 2010/05/07 9:02 AM, Adrian Georgescu wrote:
>>
>>> Can you send me the entire syslog entries for those calls from
>>> opensips and cdrtool machine logs to my email address ag at ag-projects.com
>>>
>>> Adrian
>>>
>>> On May 6, 2010, at 8:40 PM, Douglas Lane wrote:
>>>
>>>
>>>
>>>> Hi Adrian,
>>>>
>>>> Any further suggestions on this? I just don't know where to look,
>>>> as I
>>>> can't see any errors being generated other than the dialog
>>>> expiring and
>>>> cdrtool failing to execute the debitbalance call.
>>>>
>>>> What else shall I provide you to diagnose further? Or where else
>>>> can I
>>>> look to understand whats failing?
>>>>
>>>> Thanks
>>>> Doug
>>>>
>>>>
>>>> On 2010/05/05 6:11 PM, Adrian Georgescu wrote:
>>>>
>>>>
>>>>> Are you also using MediaProxy to close the calls that have RTP
>>>>> timeout?
>>>>>
>>>>> Adrian
>>>>>
>>>>> On May 5, 2010, at 6:05 PM, Douglas Lane wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Adrian,
>>>>>>
>>>>>> Below is a log from our billing server - the server that runs
>>>>>> cdrtool,
>>>>>> freeradius and mysql:
>>>>>> May 5 09:29:40 billing cdrtool[17219]: Maximum duration for
>>>>>> session
>>>>>> 4885f4b54051459e714848e243ecd742 at domain.com of telefusion at domain.com
>>>>>> to
>>>>>> destination 2783 having balance=15060.9566 is 3190
>>>>>> May 5 09:29:43 billing cdrtool[17219]: Session
>>>>>> 4885f4b54051459e714848e243ecd742 at domain.com for telefusion at domain.com
>>>>>> has expired since 121 seconds May 5 09:40:45 billing
>>>>>> cdrtool[17219]:
>>>>>> DebitBalance Duration=1075.50027394
>>>>>> CallId=4885f4b54051459e714848e243ecd742 at domain.com
>>>>>> From=sip:telefusion at domain.com Gateway=1.2.3.4 To=sip:0837256524 at domain.com
>>>>>> May 5 09:40:45 billing cdrtool[17219]: ConnectFee=0.0000
>>>>>> CallId=4885f4b54051459e714848e243ecd742 at domain.com Span=1
>>>>>> Duration=1075
>>>>>> DestId=2783 subscriber=telefusion at domain.com
>>>>>> Profile=telefusion_spl_wkday Period=weekday
>>>>>> Rate=telefusion_spl_peak
>>>>>> Interval=7-19 Cost=1.0500/60 Price=18.8125 PriceIn=17.9167
>>>>>> May 5 09:40:45 billing cdrtool[17219]: Error: session
>>>>>> 4885f4b54051459e714848e243ecd742 at domain.com of telefusion at domain.com
>>>>>> does not exist
>>>>>> May 5 09:45:02 billing cdrtool[20233]: ConnectFee=0.0000
>>>>>> CallId=4885f4b54051459e714848e243ecd742 at domain.com Span=1
>>>>>> Duration=1075
>>>>>> DestId=2783 subscriber=telefusion at domain.com
>>>>>> Profile=telefusion_spl_wkday Period=weekday
>>>>>> Rate=telefusion_spl_peak
>>>>>> Interval=7-19 Cost=1.0500/60 Price=18.8125 PriceIn=17.9167
>>>>>>
>>>>>>
>>>>>> And below is the log extract from OpenSIPS:
>>>>>> May 5 09:40:46 sbc1 call-control[4358]: warning: Rating engine
>>>>>> failed
>>>>>> query: DebitBalance Duration=1075.50027394
>>>>>> CallId=4885f4b54051459e714848e243ecd742 at domain.com
>>>>>> From=sip:telefusion at domain.com Gate
>>>>>> way=1.2.3.4 To=sip:0837256524 at domain.com
>>>>>> May 5 09:40:46 sbc1 call-control[4358]: Could not debit balance
>>>>>> for
>>>>>> call id 4885f4b54051459e714848e243ecd742 at domain.com of
>>>>>> telefusion at domain.com to sip:0837256524 at domain.com
>>>>>> May 5 09:40:46 sbc1 /opt/opensips/sbin/opensips[27232]:
>>>>>> DBG:dialog:destroy_dlg: dlg expired or not in list - dlg
>>>>>> 0x7f529edae8c8
>>>>>> [2773:299621302] with clid '4885f4b54051459e714848e243ecd742 at domain.com
>>>>>> ' an
>>>>>> d tags 'as4b9756d1' 'as2e1a01fc'
>>>>>>
>>>>>> Now my concern is why this is happening. About 80% of all calls
>>>>>> on this
>>>>>> account are fine, its just these odd calls that don't get billed
>>>>>> correctly by the prepaid service.
>>>>>>
>>>>>> Any ideas on this?
>>>>>>
>>>>>> Thanks
>>>>>> Doug
>>>>>>
>>>>>>
>>>>>> On 2010/04/26 9:19 PM, Adrian Georgescu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Prepaid history is updated when DebitBalance is called by Call
>>>>>>> control
>>>>>>> module from OpenSIPS.
>>>>>>>
>>>>>>> If this function is called when the call ends (for which you must
>>>>>>> properly configure OpenSIPS and MediaProxy ) than you do not lose
>>>>>>> money but rather your simply have duplicated radius records
>>>>>>> likely
>>>>>>> caused by multiple messages being retransmitted or wrong
>>>>>>> configuration
>>>>>>> of the accounting part.
>>>>>>>
>>>>>>> You can check the syslog on OpenSIPS and CallControl for the
>>>>>>> calls in
>>>>>>> question (namely when they start and when they stop) and match
>>>>>>> them
>>>>>>> against the syslog entries for MaxSessionTime and DebitBalance in
>>>>>>> CDRTool rating engine. The Call Id is the key that can be
>>>>>>> matched in
>>>>>>> all logs.
>>>>>>>
>>>>>>> Than you have a better picture of what happens, if you loose or
>>>>>>> not
>>>>>>> any records in prepaid table.
>>>>>>>
>>>>>>> Adrian
>>>>>>>
>>>>>>> On Apr 26, 2010, at 9:09 PM, Douglas Lane wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hey Guys,
>>>>>>>>
>>>>>>>> Sorry for all the dumb questions lately, been trying to work
>>>>>>>> out whats
>>>>>>>> going wrong.
>>>>>>>>
>>>>>>>> I make use of the prepaid_history table in CDRTool to
>>>>>>>> calculate the
>>>>>>>> daily usage for clients, and then email them a summary as well
>>>>>>>> as
>>>>>>>> their
>>>>>>>> remaining balance. What I've recently noticed when doing an
>>>>>>>> LEFT JOIN
>>>>>>>> between Radius and prepaid_history, is that radius has a load
>>>>>>>> more
>>>>>>>> callid entries that prepaid_history does for the same user
>>>>>>>> (and yes I
>>>>>>>> did a filter on SipMethod = 200) This concerns me as
>>>>>>>> technically,
>>>>>>>> cdrtool is not updating the prepaid_history database
>>>>>>>> correctly, and
>>>>>>>> therefore is actually loosing money.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Anyone else having the same issues, or perhaps can point me in
>>>>>>>> the
>>>>>>>> direction I need to troubleshoot at. I've check the logs and
>>>>>>>> there is
>>>>>>>> nothing for mysql errors. Every call I've checked has a debit
>>>>>>>> balance
>>>>>>>> request, but my concern is that some of them are not updating
>>>>>>>> the
>>>>>>>> table.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Doug
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
More information about the Users
mailing list