Thanks Logan,
The patch was already uploaded on SVN trunk and stable.
Regards,
Bogdan
logan wrote:
Bogdan, I've applied the patch you provided and initial testing has
been successful. I'll keep you posted on the rest of my tests. Thank
you for your attention to this!
Hi Logan,
The first number is the hash ID (of the internal hash table) of the hash
where the address is cached. Pure internal info, completely useless for
external purposes.
Regards,
Bogdan
logan wrote:
I'm seeing something odd with the address table loading in 1.6.3
The scenario is that
Perhaps there is another cause for this behavior then, the duplicated hash id was the first thing that popped out at me. But if they're useless than that's not it.However I have a scenario here that I can replicate 100% of the time when the two different IPs in question are present in the address
Found an issue - please try the attached patch to see if it solves your
problem.
Regards,
Bogdan
logan wrote:
Perhaps there is another cause for this behavior then, the duplicated
hash id was the first thing that popped out at me. But if they're
useless than that's not it.
However I have
Bogdan, I've applied the patch you provided and initial testing has been successful. I'll keep you posted on the rest of my tests. Thank you for your attention to this!
___
Users mailing list
Users@lists.opensips.org
I'm seeing something odd with the address table loading in 1.6.3The scenario is that I'm writing values directly into the address table then running a script periodically that runs an opensipsctl fifo address_reload command.When I do a dump I see something like this: 35 1.1.1.1,32, 0, 0, ^sip:.*$,
