[Serusers] invite timer & calls to PSTN

Jiri Kuthan jiri at iptel.org
Sun Aug 22 00:08:41 CEST 2004


At 11:49 PM 8/21/2004, O'Shaughnessy Evans wrote:
>Jiri Kuthan <jiri at 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 




More information about the sr-users mailing list