Hi, In my openser, I had to not relay any provisional which is < 180. I used drop in reply route to do this. No provisional < 180 is sent to caller. Unfortunately, dropping 100 seems to make the transaction module not disarming its fr_timer.

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.

But this first destinaion failed to establish the call, so the request was serial forked to another destination, sending another 101 sdp, then 180 sdp and 200 sdp which are relayed to caller. The problem is that caller did not take into account the next sdp but stay stucked to initial one (the one that failed). When tm timer triggers, there is a CANCEL which is sent to initial destination right ?

Well, maybe 100 does not change timers from fr to fr_inv, and I did not notice before as 180 was coming very fast ? I checked the source, but the test in t_reply before updating the timer is not obvoious to see wether timer are canceled on 100 or 180 :-) One thing is sure. If you drop the reply, timer will not be changed.

The destination was a mobile device on PSTN. 180 may be really delayed, and I am not even sure they are mandatory ! Aurelien > klaus > > Aurelien Grimaud wrote: > >> Daniel-Constantin Mierla a écrit : >> >>> Hello, >>> >>> On 12/18/08 13:18, Aurelien Grimaud wrote: >>> >>>> Hi, >>>> In my openser, I had to not relay any provisional which is < 180. >>>> I used drop in reply route to do this. >>>> No provisional < 180 is sent to caller. >>>> >>>> Unfortunately, dropping 100 seems to make the transaction >>>> module not disarming its fr_timer. >>>> >>> 100 is disabling the retransmission timer. fr_timer is the >>> duration to wait until a final response is received, not related >>> to retransmission and 100 reply. >>> >>> >> - fr_timer is armed when INVITE is t_relayed and disarmed *only* >> when a final response is received. >> - fr_inv_timer is armed whenever a provisional (100 - 199) is >> received, disarmed on final response . >> Well, fr_timer also has to be disarmed when fr_inv_timer is armed >> right ? >> >> So any provisional (100-199) disarm fr_timer and arm fr_inv_timer. >> But you have not to drop it in reply_route. >> >> In my case, the reply_route I set drops any provisional < 180. >> This means that the 100 response will not make tm module switch >> fr_timer to fr_inv_timer as it would be if not dropped. >> >> Well this is not a problem, I only dropped provisional from 101 >> to 180, and all went back to normal. >> Since 100 is not forwarded (because of t_relay already generated >> one), this makes no difference for end users. >> >> I did not expect drop() statement to change anything for timers. >> >> Thanks. >> Aurelien >> >> >>> Cheers, >>> Daniel >>> >>> >>>> The 180 has been waited for more time than my fr_timer so >>>> request failed and failure_route was called. >>>> In fact, there is no 180, only a 200 ok. >>>> >>>> Can anyone confirm that disarming timer is *not* done if 100 is >>>> dropped ? >>>> >>>> This is openser 1.2.1 >>>> >>>> Regards. >>>> Aurelien >>>> >>>> >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel(a)lists.kamailio.org >>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >>>> >>>> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >> _______________________________________________ Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

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.

It contains really early sdp. I thought it smart. I am not so sure now !