[Spce-user] peer timeouts and

[Andreas Granig]

Hi Skyler,

On 04/30/2012 03:41 PM, Skyler wrote:
>  I came across a scenario where the upstream gateway did respond with
> 100 Trying but then no further response. The result was that all calls
> to this gateway would hang with 'dead air' until the end-user hung-up
> the call.
> 
>  Would sip_timer_b=3500 also handle this scenario?

No, for that you'd need to set the fr_inv_timer in the proxy config e.g.
in ROUTE_PSTN. However, there is no distinction between a 100 and other
provisional 1xx replies in the state machine, so it'd also hit in even
if you get a 18x, which means you've to tweak it in REPLY_ROUTE_NAT and
REPLY_ROUTE_STD as well.

To sum it up, you'd need something like this:

route[ROUTE_PSTN] {
  # ...
  $(avp(s:callee_fr_inv_timer)[*]) = 10000; # in ms
  t_set_fr("$avp(s:callee_fr_inv_timer)"); # or directly t_set_fr(10000)
  $(avp(s:to_pstn_flag)[*]) = 1;
}

route[REPLY_ROUTE_NAT] { # same for REPLY_ROUTE_STD
  # ...
  if(status =~ "18[03]" && $avp(s:to_pstn_flag) == 1) {
    t_set_fr(300000);
  }
}

But there is more to that. Since we also do serial hunting since v2.5,
you'd need to measure the time until you got the 18x, subtract it from
the hunting time for that destination and set the timer accordingly
instead of just to 5min like in the example above.

Looks like kind of a rabbit hole if you don't want to break anything else :)

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20120430/ef21b9ad/attachment-0001.asc>