20 Jun
2006
20 Jun
'06
9:23 p.m.
Excellent bugtracking!
g-)
sip wrote:
Olivier,
I actually had this problem as well, and what it turned out to be was
that, by default, the inv_timer resets every time it gets a
provisional reply. Some of my phones (Snom phones) were sending a lot
of provisional replies, meaning that the timer never seemed to
expire. I had to add a modparam to keep this behaviour from occurring.
modparam("tm", "restart_fr_on_each_reply",0)
Basically telling it not to restart the timer each time it gets a reply.
See if that helps.
Incidentally, I worked out a way (with some very good pointers in the
right direction) on allowing users to set their own timers, storing
them in the DB, and accessing them via AVPops if you're interested.
N.
*
On Tue, 20 Jun 2006 14:02:06 +0200, olivier.taylor wrote*
Hi Greger,
Thanks for the answer :)
Ok you right I am talking about Cancel.
But I think i have found the problem...
I have
modparam("tm", "fr_inv_timer", 45)
When i make a call between 2 Ua registered on the same server and
not using
another proxy, it seems that the timer is never hits and Uas
continue ringing until Uac send a cancel.
When I forward the call to Pstn, the other
proxy(Pstn with timeout
set to 60 seconds) send a cancel, that's why I never
find a 408 and
always have a CANCEL.
Any idea on why the timer doesn't react?
Olivier
Greger V. Teigre a écrit :
You are talking about a CANCEL, not a 487. The 487 is the response to
a CANCEL. Only the UAC (the caller) is allowed to send a CANCEL, the
UAS (callee) should not. Thus, the 487 you see from the callee is the
response it gives you when caller cancelled the call. Hence, 487
should not be handled in your failure route (just break;). However,
you are probably looking for 408 No answer, which should result in
forwarding or voicemail or whatever the user has set up.
Bottom line: The 487 you see before you reach 60 seconds is
generated by the
caller (or the gateway). And yes, a stateful proxy
is also allowed to send a CANCEL, so if you have a proxy between you
and the caller, it might be that the timer in that proxy is set to
lower.
g-)
olivier.taylor wrote:
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
487 is checked,
How do you make the difference between a 487 issued by the caller
and a 487
issued by the callee, that's the question?
Ok, I must be stupid, once again :(
Olivier
Xavier TRENTIN a écrit :
Check if reply status is not 487 in the failure route.
>
> Xavier.
>
> olivier.taylor a écrit :
> Maybe I am stupid again, but 60000 or 6000000000000000000000
> doesn't change the problem, the callee still send a 487 before any
> timeout on SER.
> >
> > And i don't find a way to distinguish a 487 set by the callee
> from a 487 sent by the caller.
> > My mind is that those values are in seconds, not in miliseconds...
> >
> > Hey Greger, any idea?
> >
> > Olivier
> >
> > Weiter Leiter a écrit :
>> Try with 60000. After last timers update, those values are in ms.
>>
>> olivier.taylor wrote:
>>
>>> hi all,
>>>
>>> I have
>>>
>>> modparam("tm", "fr_inv_timer", 60)
>>>
>>> when a callee doesn't anwer, he often send a 487 (cancelled) before 60
>>> seconds...
>>>
>>> It means timeout in fact or no answer...
>>> If the caller stop the call, I also get a 487...
>>>
>>> How to make the difference on a 487 generated by the caller and by the
>>> callee?
>>>
>>> It makes difference, if it's generated by the callee, I will forward
>>> the call to voicemail or another number, if it's generated by the
>>> caller, I will do nothing.
>>>
>>> When I set fr_inv_timer to 15, I always get a timeout and it's ok, but
>>> my customers dislikes that as well as the callees who needs to be
>>> better than Ben Jonhson for the 100meters :(
>>>
>>> Does exists a parameter to be send to the callee to tell him to wait
>>> 60 seconds + 1 before sending me a Cancel?
>>>
>>> Regards,
>>>
>>> Olivier
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers