[Serusers] I must be stupid... but
Greger V. Teigre
greger at teigre.com
Tue Jun 20 21:21:11 CEST 2006
That's correct, but we're happy to include it as a how-to :-)
g-)
sip wrote:
> 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
>>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060620/b1d97ae7/attachment.htm>
More information about the sr-users
mailing list