[OpenSIPS-Users] CDRTool - ReloadRatingTables and new destinations

[Adrian Georgescu]

Hi Dan,

I have made a change to fix your problem. Pl upgrade to 6.7.4 and let  
me know if you still have problems with reloading the tables.

Regards,
Adrian

On Mar 16, 2009, at 2:16 PM, Dan-Cristian Bogos wrote:

> Adrian,
>
> I understand all these, but I think you don't get me.
>
> Please do me a favor, and let me know if you get the same behavior  
> like
> me in your lab:
>
> 1. Delete a destination from cdrtool.destinations table.
> 2. Issue a ShowPrice command over telnet which should match the
> destination you just deleted. Nothing should happen, I understand  
> until
> you ReloadRatingTables and run normalize.php.
> 3. Issue a ReloadRatingTables and run normalize.php.
> 4. Run the same ShowPrice over telnet and you will see that your
> destination is still showing up in the results (at least this is  
> what is
> happening to me). This scenario you can repeat when adding new
> destinations or modifying the existing ones.
>
> Ta,
> DanB
>
> On Mon, 2009-03-16 at 14:03 +0100, Adrian Georgescu wrote:
>> 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/96ce0277/attachment-0001.htm