[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