At 08:58 PM 8/21/2004, O'Shaughnessy Evans wrote:
Thanks, Jiri.
Jiri Kuthan <jiri(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan
http://iptel.org/~jiri/