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 [email protected] >>> >>> 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 >>>>>> [email protected] of [email protected] >>>>>> to >>>>>> destination 2783 having balance=15060.9566 is 3190 >>>>>> May 5 09:29:43 billing cdrtool[17219]: Session >>>>>> [email protected] for [email protected] >>>>>> has expired since 121 seconds May 5 09:40:45 billing >>>>>> cdrtool[17219]: >>>>>> DebitBalance Duration=1075.50027394 >>>>>> [email protected] >>>>>> From=sip:[email protected] Gateway=1.2.3.4 >>>>>> To=sip:[email protected] >>>>>> May 5 09:40:45 billing cdrtool[17219]: ConnectFee=0.0000 >>>>>> [email protected] Span=1 >>>>>> Duration=1075 >>>>>> DestId=2783 [email protected] >>>>>> 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 >>>>>> [email protected] of [email protected] >>>>>> does not exist >>>>>> May 5 09:45:02 billing cdrtool[20233]: ConnectFee=0.0000 >>>>>> [email protected] Span=1 >>>>>> Duration=1075 >>>>>> DestId=2783 [email protected] >>>>>> 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 >>>>>> [email protected] >>>>>> From=sip:[email protected] Gate >>>>>> way=1.2.3.4 To=sip:[email protected] >>>>>> May 5 09:40:46 sbc1 call-control[4358]: Could not debit balance >>>>>> for >>>>>> call id [email protected] of >>>>>> [email protected] to sip:[email protected] >>>>>> 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 '[email protected] >>>>>> ' 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 >>>>>>>> [email protected] >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
