[Serusers] I must be stupid... but

[sip]

Yes... I think we're talking about different things. :) 

In the onsip.org doc, you set the invite timer using the avp, but it's not
dynamic. It's hard-coded into the config.  I've got it coded into the DB, so
each user can have his own timer setting (NO one seems to like a default...
some people think it's too long, some people think it's too short). 

At least, that's the way it is in the version of the getting started doc I have. 

N.


On Tue, 20 Jun 2006 22:48:11 +0700, Andrey Kouprianov wrote
> Configuration script on how to use avops for INVITE timers is shown
> (!) in the "getting started" document (am I talking about the same
> things as you guys?)
> 
> On 6/20/06, sip <sip at arcdiv.com> 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:
> >
> > > 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> > _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> >
> > > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
> >
> >
> > > 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:
> >
> > > 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> > _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> >
> > > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> > ________________________________
> >
> _______________________________________________
> Serusers
> > mailing
> > list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers