Daniel-Constantin Mierla a écrit :
On 12/28/08 23:56, Aurelien Grimaud wrote:
Daniel-Constantin Mierla a écrit :
On 12/20/08 14:09, Aurelien Grimaud wrote:
Daniel-Constantin Mierla a écrit :
On 12/19/08 10:10, Aurelien Grimaud wrote:
Klaus Darilion a écrit :
> Strange! > > Nevertheless there is no need to drop 100 as 100 is never relayed. > Yep, my mistake !
The first destination chosen for serial forking was sending a 101 with sdp, which was relayed to caller.
101 - I haven't heard of such reply so far ... what is the reason phrase?
Well, this is a home made reply from a pstn gateway. The pstn gateway sens request to a pstn network equipement. As soon as the pstn equipements answers a Progress, a 101 is relayed to openser.
ok, i understand.
It contains really early sdp. I thought it smart. I am not so sure now !
If you want to get to tm but not relayed upstream, you should drop it in an onreply_route armed via tm (t_on_reply(...) call), not the default onreply_route.
Well, actually I dropped the message in an onreply_route armed via tm and timer were not canceled. Correct me if I'm wrong, but I think that the timer processing is *after* the reply_route execution.
retransmission timers are reset before executing the tm onreply route.
Yes sure, retransmission timers are reset before executing the tm onreply route.
Ok too : fr_timer is disabled on final reply.
/* stop final response timer only if I got a final response */ if ( msg_status >= 200 ) { reset_timer( &uac->request.fr_timer); }
But, fr_timer is switched to fr_inv_timer after executing onreply_route. So, If all provisional are dropped, the fr_timer is not changed to fr_inv_timer.
Should not fr_timer be changed to fr_inv_timer even if message is dropped ?
I mean, my fr_timer is 10 seconds. fr_inv_timer is 120 seconds. I expect it to work this way :
relay INVITE to destination A. A does not answer anything : fr_timer is triggered (A is probably down, or unreachable) failure route : serial forking to destination B
or
relay INVITE to destination A A answers 180, fr_timer is switched to fr_inv_timer (A is processing the call) No final reply for fr_inv_timer seconds (A does not answer anymore : network problem, host down) failure_route : serial forking to destination B
If 180 is dropped, then the behavior is as follow
relay INVITE to destination A A answers 180 which is dropped. after 10 seconds (fr_timer) : failure route because of fr_timer. This is a wrong failure report. A is processing the call, serial forking should not occur.
Documentation says :
Timer which hits if no final reply for an INVITE arrives after a
provisional message was received (in seconds). *This timer is started after the first provisional response.* Thus, fast failover (no 100 trying from gateway) can be achieved by setting fr_timer to low values.
No warning on dropped messages.
You talk about this with one of the patches I sent or before that?
The problem occurred with openser 1.2.1, but the svn source code has the same issue imho.
Regards. Aurelien
Cheers, Daniel