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