Heheh. I SO can't take credit for it, I'm afraid. I was having serious issues
with the timer only on the Snom phones and someone else in the list pointed out that that
could be a possibility. Lo and behold, that was the issue.
N.
On Tue, 20 Jun 2006 21:23:57 +0200, Greger V. Teigre wrote
Excellent bugtracking!
g-)
sip wrote: Olivier,
I actually had this problem as well, and what it turned out to be wasthat, by default,
the inv_timer resets every time it gets a provisionalreply. Some of my phones (Snom
phones) were sending a lot ofprovisional replies, meaning that the timer never seemed to
expire. Ihad 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 areply.
See if that helps.
Incidentally, I worked out a way (with some very good pointers in theright direction) on
allowing users to set their own timers, storingthem 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 andnotusing another
proxy, it seems that the timer is never hits and Uascontinue ringing until Uac send a
cancel.
> When I forward the call to Pstn, the other proxy(Pstn with timeoutsetto 60 seconds)
send a cancel, that's why I never find a 408 and alwayshave a CANCEL.
>
> Any idea on why the timer doesn't react?
>
> Olivier
>
> Greger V. Teigre a écrit : Youare talking about a CANCEL, not a 487. The 487 is the
response to aCANCEL. 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 theresponse it gives you
when caller cancelled the call. Hence, 487 shouldnot be handled in your failure route
(just break;). However, you areprobably looking for 408 No answer, which should result in
forwardingor voicemail or whatever the user has set up.
>
> Bottom line: The 487 you see before you reach 60 seconds isgeneratedby the caller
(or the gateway). And yes, a stateful proxy is alsoallowed to send a CANCEL, so if you
have a proxy between you and thecaller, it might be that the timer in that proxy is set to
lower.
> g-)
>
> olivier.taylor wrote:
> 487 is checked,
> How do you make the difference between a 487 issued by the callerand a487 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 : MaybeIam stupid again, but 60000 or 6000000000000000000000
doesn'tchange the problem, the callee still send a 487 before any timeout onSER.
>
> And i don't find a way to distinguish a 487 set by the callee froma487 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@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
-----------------------------------------------------------------------
_______________________________________________Serusers mailing
listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
>
-----------------------------------------------------------------------
_______________________________________________Serusers mailing
listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
-----------------------------------------------------------------------
_______________________________________________Serusers mailing
listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
-----------------------------------------------------------------------
_______________________________________________Serusers mailing
listSerusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers