[Serusers] t_on_retransmission route
Greger V. Teigre
greger at teigre.com
Wed Sep 27 09:38:53 CEST 2006
Hi Hendrik,
First: I cross-post to serdev. Andrei does not follow serusers too
closely and he should have a chance to comment.
Comment: You can change timers before you send to the GW, maybe not all
you need, but why not make sure SER does not spend a long time timing
out or resending INVITEs? I would assume it is better to handle dead
peers in a unified manner in failure route?
g-)
Hendrik Scholz wrote:
> Hi!
>
> We were poking the idea around of having an optional route
> that would be invoked upon a retransmission.
> The fr timers all fire way too late if you'd have to implement
> some sort of fallback if your peering partner or PSTN gateway died.
>
> I magine a routing mechanism much like t_on_failure() / failure_route()
> to allow something like this:
>
> - set transmission timer via AVP / t_set_fr() like
> - t_on_retransmission(1);
> - t_relay_to_udp()
>
> and then you'd have something like
>
> retransmission_route[1] {
> # select new gateway
> t_relay_to_udp()
> }
>
> The retransmission route should be invoked if no provisional (i.e.
> 100 Trying) nor final response was received within the given interval.
> I'm not sure about how to handle TCP connections, though. A simple
> TCP ACK might be enough to assume the other side is up and happy
> to answer our request.
>
> This would allow for redirecting traffic without having to wait for
> a final response (408 timeout).
> The timer value would be fr_timer - fr_inv_timer starting at the same
> time as fr_timer itself.
>
> Last but not least I'm not sure about the impact of having quite
> a lot of timers firing after a couple of msecs.
>
> If anybody thinks this would make sense I'd give it a try ;)
>
> Cheers,
> Hendrik
>
More information about the sr-users
mailing list