Hello, all. I have a problem I'm trying to work out: when a stateful call goes out from the proxy to the PSTN, the fr_inv_timer will eventually trigger a failure. The thing is, I don't want calls going outside my SIP proxy to have any timer associated with them. I need it for calls to local users so they can fall back to voicemail, but I don't need it for anything else. E.g. if one of my SIP users calls out to a PSTN number and, for whatever reason, wants that call to ring 300 times, the timer in the SIP proxy shouldn't inhibit that ability.
I can get around this by using forward(), but if the SIP user is coming from a NAT'd device, I have to use a t_relay() instead and then I'm stuck with the timer running.
Is there a way around this? Thanks for your help.
At 03:34 AM 8/21/2004, O'Shaughnessy Evans wrote:
Hello, all. I have a problem I'm trying to work out: when a stateful call goes out from the proxy to the PSTN, the fr_inv_timer will eventually trigger a failure. The thing is, I don't want calls going outside my SIP proxy to have any timer associated with them. I need it for calls to local users so they can fall back to voicemail, but I don't need it for anything else. E.g. if one of my SIP users calls out to a PSTN number and, for whatever reason, wants that call to ring 300 times, the timer in the SIP proxy shouldn't inhibit that ability.
I can get around this by using forward(), but if the SIP user is coming from a NAT'd device, I have to use a t_relay() instead and then I'm stuck with the timer running.
Is there a way around this? Thanks for your help.
a trivial workaroud is to drive the inv_fr_timer excessively high.
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured: - noisy_ctimer config option is explicitley turned on - forking - failure_route set up
-jiri
Thanks, Jiri.
Jiri Kuthan jiri@iptel.org wrote: [...]
I can get around this by using forward(), but if the SIP user is coming from a NAT'd device, I have to use a t_relay() instead and then I'm stuck with the timer running.
Is there a way around this? Thanks for your help.
a trivial workaroud is to drive the inv_fr_timer excessively high.
Ah, but that breaks failover to voicemail, no? (within a reasonable time)
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured:
- noisy_ctimer config option is explicitley turned on
- forking
- failure_route set up
Yeah, the failure_route for voicemail would be turning that off.
I'm still confused, though. I need to be able to forward calls to the PSTN and let them ring indefinitely, leaving any call resolution to the remote end (say, the PSTN user's PBX, voicemail, whatever). forward() works great for that, but if my caller is going through NAT I have to use t_relay. A high fr_inv_timer means incoming calls can't fall back to voicemail in a reasonable time, though it does fix the problem for outgoing PSTN calls.
So I guess one option would be to run 2 instances of ser, one for incoming and another for outgoing. Seems like a lot of administrative overhead just to fix this one minor problem. But if that's what I gotta do, that's what I'll do. I believe I saw someone mention a solution like this in an archived list thread. Has anyone done any work on making the module parameters settable from within the route blocks? That would make this a whole lot easier -- I could just turn the timer off in the NAT -> PSTN instance and everything would be good.
Thanks again for your help, and best regards.
At 08:58 PM 8/21/2004, O'Shaughnessy Evans wrote:
Thanks, Jiri.
Jiri Kuthan jiri@iptel.org wrote: [...]
I can get around this by using forward(), but if the SIP user is coming from a NAT'd device, I have to use a t_relay() instead and then I'm stuck with the timer running.
Is there a way around this? Thanks for your help.
a trivial workaroud is to drive the inv_fr_timer excessively high.
Ah, but that breaks failover to voicemail, no? (within a reasonable time)
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured:
- noisy_ctimer config option is explicitley turned on
- forking
- failure_route set up
Yeah, the failure_route for voicemail would be turning that off.
I'm confused too ;) -- do you wish the calls to ring indefinitely or do you wish a timeout to strike and fall back to voicemail? Note you may have different routes processed statefuly but with or without failure_route and consequently with or without "silent timer".
I'm still confused, though. I need to be able to forward calls to the PSTN and let them ring indefinitely, leaving any call resolution to the remote end (say, the PSTN user's PBX, voicemail, whatever). forward() works great for that, but if my caller is going through NAT I have to use t_relay. A high fr_inv_timer means incoming calls can't fall back to voicemail in a reasonable time, though it does fix the problem for outgoing PSTN calls.
So I guess one option would be to run 2 instances of ser, one for incoming and another for outgoing. Seems like a lot of administrative overhead just to fix this one minor problem. But if that's what I gotta do, that's what I'll do.
I recall some people did that out of desperation too.
I believe I saw someone mention a solution like this in an archived list thread. Has anyone done any work on making the module parameters settable from within the route blocks? That would make this a whole lot easier -- I could just turn the timer off in the NAT -> PSTN instance and everything would be good.
Perhaps the possibility I mentioned above would help out -- don't set failure_route for the calls to PSTN. You also need to make sure other conditions for rhis route don't trigger the timer-driven cancellation. These include forking (not that urgently needed for PSTN), accounting (perhaps you will be accounting from gateway?), use of failure_route (then retrying with another gateway if first fails is hard).
That all sounds quite burdensome -- I guess a quick hack with two SER instances could make it better. In long-term, we will be striving for configurable timers.
-jiri
Thanks again for your help, and best regards.
-- = o'shaughnessy evans = = sys admin @ (aloha|kona|myworld).net = "We've got a lot of suppliers. We already know some of them are pretty good and some of them are idiots. We don't expect the Y2K problem to change this." -- http://www.hartscientific.com/y2k.htm
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan jiri@iptel.org wrote:
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured:
[...]
Yeah, the failure_route for voicemail would be turning that off.
I'm confused too ;) -- do you wish the calls to ring indefinitely or do you wish a timeout to strike and fall back to voicemail? Note you may have different routes processed statefuly but with or without failure_route and consequently with or without "silent timer".
Oops. I mistated -- there's no failure_route defined when routing to the PSTN. The fr_inv_timer is still triggering a failure, though.
I wish calls to remote endpoints over which I have no control (in this case, PSTN destinations) to ring as long as the remote system determines. Only local calls should fall back to voicemail.
Here's the nitty gritty of the problem. I have fr_inv_timer set to some normal value, like 30-45 seconds, so that if a local user doesn't pick up his phone within, say, 6 rings or so, the call will fail over to his voicemail box. t_on_failure is only set in this route. That works great.
In a different route, I send calls to the PSTN. If the caller isn't coming from a NAT device, I can use forward(). No need to do a stateful relay because I'm not doing any accounting. I just want to hand off the call and forget about it. But if the caller *is* coming via NAT, I need to force_rtp_proxy, which thus means t_relay instead, right? And since I'm using the tm module, the fr_inv_timer triggers after 45 seconds and I get a busy signal (since there's no failure_route defined).
Is there a way to avoid that bogus fr_inv_timer failure? I don't know enough about call routing to say, but from this perspective it seems to me that if there's no failure_route defined, the fr_inv_timer should never go off.
Anyway, thanks again for your help, everyone.
At 11:49 PM 8/21/2004, O'Shaughnessy Evans wrote:
Jiri Kuthan jiri@iptel.org wrote:
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured:
[...]
Yeah, the failure_route for voicemail would be turning that off.
I'm confused too ;) -- do you wish the calls to ring indefinitely or do you wish a timeout to strike and fall back to voicemail? Note you may have different routes processed statefuly but with or without failure_route and consequently with or without "silent timer".
Oops. I mistated -- there's no failure_route defined when routing to the PSTN. The fr_inv_timer is still triggering a failure, though.
I wish calls to remote endpoints over which I have no control (in this case, PSTN destinations) to ring as long as the remote system determines. Only local calls should fall back to voicemail.
Here's the nitty gritty of the problem. I have fr_inv_timer set to some normal value, like 30-45 seconds, so that if a local user doesn't pick up his phone within, say, 6 rings or so, the call will fail over to his voicemail box. t_on_failure is only set in this route. That works great.
In a different route, I send calls to the PSTN. If the caller isn't coming from a NAT device, I can use forward(). No need to do a stateful relay because I'm not doing any accounting. I just want to hand off the call and forget about it. But if the caller *is* coming via NAT, I need to force_rtp_proxy, which thus means t_relay instead, right? And since I'm using the tm module, the fr_inv_timer triggers after 45 seconds and I get a busy signal (since there's no failure_route defined).
My suggestion for this route has been use t_relay but do not set up failure_route. Unless there is other condition prohibiting that (such as forking/accounting), expired FR timer will not cause the call to be cancelled. You just need to make sure none of these conditions occurs. Since you are fine with stateless forwarding (i.e., don't use accounting, forking, failure_route for this route) it should be feasible.
Is there a way to avoid that bogus fr_inv_timer failure? I don't know enough about call routing to say, but from this perspective it seems to me that if there's no failure_route defined, the fr_inv_timer should never go off.
As mentioned in the previous emails, there are more conditions. The timer always goes off. Only and only if SER is certain there is no action to take, it drops transaction state silently without CANCEL. For example with forking, it can't simply drop the transaction state because replies to all branches would hit a very surprised client. Also, if some callbackes are set (like accounting), SER does not know if it is safe to drop the transaction silently and will cancel it explicitely.
-jiri
O'Shaughnessy Evans wrote:
Jiri Kuthan jiri@iptel.org wrote:
Other option is to enable silent timer -- i.e., SER not sending 408 and CANCEL, just trashing the transaction from memory. This option is actually turned on by default, but is disabled in run-time if some of many conditions occured:
[...]
Yeah, the failure_route for voicemail would be turning that off.
I'm confused too ;) -- do you wish the calls to ring indefinitely or do you wish a timeout to strike and fall back to voicemail? Note you may have different routes processed statefuly but with or without failure_route and consequently with or without "silent timer".
Oops. I mistated -- there's no failure_route defined when routing to the PSTN. The fr_inv_timer is still triggering a failure, though.
I wish calls to remote endpoints over which I have no control (in this case, PSTN destinations) to ring as long as the remote system determines. Only local calls should fall back to voicemail.
Here's the nitty gritty of the problem. I have fr_inv_timer set to some normal value, like 30-45 seconds, so that if a local user doesn't pick up his phone within, say, 6 rings or so, the call will fail over to his voicemail box. t_on_failure is only set in this route. That works great.
In a different route, I send calls to the PSTN. If the caller isn't coming from a NAT device, I can use forward(). No need to do a stateful relay because I'm not doing any accounting. I just want to hand off the call and forget about it. But if the caller *is* coming via NAT, I need to force_rtp_proxy, which thus means t_relay instead, right? And since I'm using the tm module, the fr_inv_timer triggers after 45 seconds and I get a busy signal (since there's no failure_route defined).
Is there a way to avoid that bogus fr_inv_timer failure? I don't know enough about call routing to say, but from this perspective it seems to me that if there's no failure_route defined, the fr_inv_timer should never go off.
We have several instances of SER running for just this purpose. One instance with a specific value for fr_inv_timer for inbound calls that need to goto SEMS after 4 rings. A different instance for outbound calls where fr_inv_timer is set to 45 seconds to handle the range of called devices and their resective "answer" times. This works pretty well.
Anyway, thanks again for your help, everyone.
At 01:08 PM 8/22/2004, Steve Blair wrote:
Is there a way to avoid that bogus fr_inv_timer failure? I don't know enough about call routing to say, but from this perspective it seems to me that if there's no failure_route defined, the fr_inv_timer should never go off.
That is not doable -- the timer must be there and it must hit, otherwise the server would become storage of transaction memory, subject to very quick memory exhaustion and increased DoS vulnerability. The only think we can do is not to initial CANCEL on the timer, which is not always doable (see my previous email).
We have several instances of SER running for just this purpose. One instance with a specific value for fr_inv_timer for inbound calls that need to goto SEMS after 4 rings. A different instance for outbound calls where fr_inv_timer is set to 45 seconds to handle the range of called devices and their resective "answer" times. This works pretty well.
That may be a reasonable remedy. Having multiple proxy servers may also provide some additional bonus points. In particular, if you deploy a simple PSTN gateway-guarding proxy, which does not do a lot (for example resolve DNS), the simpler logic will be harder to circumvent.
-jiri
-
Jiri Kuthan -
O'Shaughnessy Evans -
Steve Blair