One more reason for string after t_relay is, If t_relay failed then we don't
need to save in the location table.
Thanks
Jijo
On Sun, Feb 20, 2011 at 12:53 PM, Jijo wrote:
> Yes this happens in a testing environment..
> I got your point, we saved after t-relay to send the message faster as db
>
Yes this happens in a testing environment..
I got your point, we saved after t-relay to send the message faster as db save
can cause delay.
We will make the changes as per your suggestion .
Thanks
Jijo
On Feb 18, 2011, at 4:11 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> is any particular
Hello,
is any particular reason to do the processing after t_relay() ? You can
do the save before, since it is the same register message.
Also, are you getting this in a testing environment while using tools
like sipp to simulate traffic?
Starting with 3.0, the AVPs (which are associated wi
Hi Daniel,
Please find the code and corresponding error trace. This happens only for 1
subscriber randomly out of 2000 subscribers. This can be reproduced
consistently also.
route(1)
{
:
:
:
# -
# Registration handl
Hello,
it is not clear for me what you tried to do. Can you paste here the
parts of the config file that are relevant for the case? Do you relay
the REGISTER?
Cheers,
Daniel
On 2/16/11 1:17 AM, Jijo wrote:
Hi All,
On register we store the contact in an avp variable and do a
t_relay(). Aft
Hi All,
On register we store the contact in an avp variable and do a t_relay().
After t_relay() the $avp variable becomes null.
I printed the value before after t_relay() to determine this behavior.
This happens only on registration load test around 2000 subcribers with ( 4
REGISTER/sec). This ha
