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. 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
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.
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Strange!
Nevertheless there is no need to drop 100 as 100 is never relayed.
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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?
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 ?
Yes.
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.
If you dropped it in default onreply route then tm does not get it.
Cheers, Daniel
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Users mailing list Users@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 !
Aurelien
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 ?
Yes.
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.
If you dropped it in default onreply route then tm does not get it.
Cheers, Daniel
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
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.
Cheers, Daniel
Aurelien
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 ?
Yes.
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.
If you dropped it in default onreply route then tm does not get it.
Cheers, Daniel
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@lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel > >
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
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.
Regards, Aurelien
Cheers, Daniel
Aurelien
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 ?
Yes.
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.
If you dropped it in default onreply route then tm does not get it.
Cheers, Daniel
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@lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >> >>
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
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.
You talk about this with one of the patches I sent or before that?
Cheers, Daniel
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
-
Aurelien Grimaud -
Daniel-Constantin Mierla -
Klaus Darilion