[Spce-user] fr_timer ignored

[Oleg]

Hello,

It seems that the fr_timer equivalent for outbound calls should be set 
through /etc/ngcp-config/config.yml, namely sems.sbc.outbound. Indeed it 
is set to '6000' by default.

This sets up 'sip_timer_b' and 'sip_timer_f' in sems.conf. However, I've 
noticed that sems only accepts this configuration if the timer types are 
indicated with uppercase letters: sip_timer_B and sip_timer_F.

I've tried to confirm this, but found contradictory information in sems 
sources.

- 
https://github.com/sems-server/sems/blob/master/core/etc/sems.conf.sample, 
indeed gives examples with sip_timer_b and sip_timer_f
- 
https://github.com/sems-server/sems/blob/master/core/sip/sip_timers.cpp, 
however, shows _timer_name_lookup list only with uppercase letters

I had to apply the following to sems.conf.tt2 in order to have 6 seconds 
timeout failover respected for outbound calls through 'ghost' Peerings 
(not responding no INVITES):

----  customtt patch ------
--- /etc/ngcp-config/templates/etc/ngcp-sems/sems.conf.tt2	2017-04-21 
18:03:58.591145946 +0200
+++ 
/etc/ngcp-config/templates/etc/ngcp-sems/sems.conf.customtt.tt2	2017-04-21 
18:04:16.107177799 +0200
@@ -42,8 +42,8 @@
  unhandled_reply_loglevel=info
  accept_fr_without_totag=yes
  wait_for_bye_transaction=yes
-sip_timer_b=[% sems.sbc.outbound_timeout %]
-sip_timer_f=[% sems.sbc.outbound_timeout %]
+sip_timer_B=[% sems.sbc.outbound_timeout %]
+sip_timer_F=[% sems.sbc.outbound_timeout %]
  [% IF sems.debug == "yes" -%]
  # This is for kamailio-config-tests scenarios
  sip_timer_e=8000
----- end ------------------

All this, while possible, seems a bit awkward to me. Can anyone test 
sems sip_timers and confirm this?

Regards,

Oleg


> Hello,
> 
> I'm setting fr_timer in /etc/ngcp-config/config.yml, but it seems
> kamailio-proxy is ignoring it. Timeout-408 when terminating to a not
> responding gateway only comes up after 32s.
> 
> Any other setting one must set to have shorter failover time on not
> receiving response to INVITES?
> 
> Thanks.
> 
> Oleg