[Serusers] invite timer & calls to PSTN

[Jiri Kuthan]

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

--
Jiri Kuthan            http://iptel.org/~jiri/