[OpenSIPS-Users] CDRTool - ReloadRatingTables and new destinations
Adrian Georgescu
ag at ag-projects.com
Mon Mar 16 14:03:35 CET 2009
Only the normalization process reinitializes the changed data. If you
run telnet and issue manually the ShowPrice command nothing happens
until a normalization process runs. If you would check for every
ShowOPrice command if a reload is required it will affect the speed
of the engine.
Adrian
On Mar 16, 2009, at 1:44 PM, Dan-Cristian Bogos wrote:
> I understand that, but I did not normalize anything in my actions. I
> just played with the ShowPrice over telnet (adding and deleting
> destinations directly from the database, and then running ReloadTables
> over telnet interface).
>
> DanB
>
> On Mon, 2009-03-16 at 13:39 +0100, Adrian Georgescu wrote:
>> A call once normalized is stored in the radiust table and remains
>> unchanged unless you re-normalize the calls that you wish to have
>> updated. So changing rating tables does not have any influence upon
>> previously normalized calls, they remain with the previous values.
>>
>>
>> Adrian
>>
>>
>>
>>
>> On Mar 16, 2009, at 12:21 PM, Dan-Cristian Bogos wrote:
>>
>>>
>>> Adrian,
>>>
>>> On Mon, 2009-03-16 at 11:50 +0100, Adrian Georgescu wrote:
>>>> This is a problem unrelated to the destinations reload. Most
>>>> likely
>>>> you did not create the correct rating table data.
>>>
>>> I am not sure if it is due to correct rating table data (should see
>>> no
>>> Span price in that case I think), so bear with me to read the logs.
>>>
>>> Here comes a more detailed usage scenario:
>>>
>>> I have added a new number inside destination table (like you said,
>>> no
>>> rating defined, just the destination one).
>>>
>>> * First query will identify maybe correctly the destination 31
>>> (since
>>> the reload of rating tables was not yet done and the new destination
>>> is
>>> not yet in the memory).
>>>
>>> ShowPrice from=dan at itsyscom.com gateway=10.10.10.1 Duration=59
>>> To=0031676000008
>>> 0.1200
>>> Duration: 60 s
>>> App: audio
>>> Destination: 31
>>> Customer: default
>>> Increment: 60 s
>>> Connect: 0.0000
>>> StartTime: 2009-03-16 10:08:45
>>> --
>>> Span: 1
>>> Duration: 60 s
>>> ProfileId: DEFAULT / weekday
>>> RateId: DEFAULT / 0-24h
>>> Rate: 0.1200 / 60 s
>>> Price: 0.1200
>>>
>>> reloadratingtables
>>> 1
>>>
>>> * Second and third attempt are after reloadratingtables succeed -
>>> saw it
>>> in mysql.log. Notice that the destination identified is still 31.
>>>
>>> ShowPrice from=dan at itsyscom.com gateway=10.10.10.1 Duration=59
>>> To=0031676000008
>>> 0.1200
>>> Duration: 60 s
>>> App: audio
>>> Destination: 31
>>> Customer: default
>>> Increment: 60 s
>>> Connect: 0.0000
>>> StartTime: 2009-03-16 10:09:52
>>> --
>>> Span: 1
>>> Duration: 60 s
>>> ProfileId: DEFAULT / weekday
>>> RateId: DEFAULT / 0-24h
>>> Rate: 0.1200 / 60 s
>>> Price: 0.1200
>>>
>>> ShowPrice from=dan at itsyscom.com gateway=10.10.10.1 Duration=59
>>> To=0031676000008
>>> 0.1200
>>> Duration: 60 s
>>> App: audio
>>> Destination: 31
>>> Customer: default
>>> Increment: 60 s
>>> Connect: 0.0000
>>> StartTime: 2009-03-16 10:18:20
>>> --
>>> Span: 1
>>> Duration: 60 s
>>> ProfileId: DEFAULT / weekday
>>> RateId: DEFAULT / 0-24h
>>> Rate: 0.1200 / 60 s
>>> Price: 0.1200
>>>
>>> Connection closed by foreign host.
>>>
>>> * Here I have restarted the cdrtool with /etc/init.d/cdrtool
>>> restart.
>>> Now the destination is correctly identified as 31676000008 (full
>>> length), of course without Span section since I have no rating
>>> defined
>>> yet.
>>>
>>> DellLaptop:/usr/local/src/cdrtool# telnet localhost 9094
>>> Trying 127.0.0.1...
>>> Connected to localhost.
>>> Escape character is '^]'.
>>> ShowPrice from=dan at itsyscom.com gateway=10.10.10.1 Duration=59
>>> To=0031676000008
>>> 0
>>> Duration: 60 s
>>> App: audio
>>> Destination: 31676000008
>>> Customer: default
>>> Increment: 60 s
>>>
>>>
>>> Is my logic broken?
>>> Same thing happens if I simply remove the destination (still showing
>>> it
>>> in ShowPrice even if there is no longer in the database.
>>>
>>> Ta,
>>> DanB
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090316/73cd379e/attachment.htm
More information about the Users
mailing list