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.