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
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
Hi Greger!
Greger V. Teigre wrote:
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?
I thought about reducing the fr_timer for particularly interesting calls but once the timer fires I'll be stuck in a situation where I get a 408 timeout not knowing if there was a 100/180/183 received before.
Over here calls to a cell phone via a SIP->PSTN gateway tend to take 4-5 seconds to the first ringing. Nonetheless the PSTN gateway sends the first response (100 Trying) within a couple of milliseconds thus moving the UAC to the 'Proceeding' state. What I was looking for was a way to trigger various actions (i.e. rerouting traffic) if the transaction didn't advance to the Proceeding state within that small amout of milliseconds no matter how long it takes to receive any final response from the UAS.
Cheers, Hendrik
Hi Hendrik, In a recent thread I described how to use an avpair (set it in on_reply) to test if the 408 is from the GW or locally generated. If the avpair is not set, you never reached onreply and the 408 must be due to a timer. Does that help? g-)
Hendrik Scholz wrote:
Hi Greger!
Greger V. Teigre wrote:
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?
I thought about reducing the fr_timer for particularly interesting calls but once the timer fires I'll be stuck in a situation where I get a 408 timeout not knowing if there was a 100/180/183 received before.
Over here calls to a cell phone via a SIP->PSTN gateway tend to take 4-5 seconds to the first ringing. Nonetheless the PSTN gateway sends the first response (100 Trying) within a couple of milliseconds thus moving the UAC to the 'Proceeding' state. What I was looking for was a way to trigger various actions (i.e. rerouting traffic) if the transaction didn't advance to the Proceeding state within that small amout of milliseconds no matter how long it takes to receive any final response from the UAS.
Cheers, Hendrik
-
Greger V. Teigre -
Hendrik Scholz -
Hendrik Scholz