Module: sip-router Branch: kamailio_3.0 Commit: 5ff3c06aa9c216ef9b2168c0163f00017eb4718d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5ff3c06a...
Author: Daniel-Constantin Mierla miconda@gmail.com Committer: Daniel-Constantin Mierla miconda@gmail.com Date: Fri Dec 11 10:33:33 2009 +0100
tm: unlock replies in case of drop
- needed after yesterday fix from Andrei
---
modules/tm/t_reply.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c index 5be259c..24fad6f 100644 --- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -2024,6 +2024,10 @@ int reply_received( struct sip_msg *p_msg ) replies_locked=1; run_top_route(onreply_rt.rlist[t->on_reply], p_msg, &ctx); if ((ctx.run_flags&DROP_R_F) && (msg_status<200)) { + if (unlikely(replies_locked)) { + replies_locked = 0; + UNLOCK_REPLIES( t ); + } goto done; } /* transfer current message context back to t */
Hello,
On 12/11/09 10:47 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
tm: unlock replies in case of drop
- needed after yesterday fix from Andrei
daniel,
was this a bug in andrei's fix? should it be picked to sr_3.0?
this does not affect SR AFAIK.
In K 3.0 this is related to the feature of dropping provisional replies in tm onreply_route upon calling drop.
Cheers, Daniel
Daniel-Constantin Mierla writes:
this does not affect SR AFAIK.
In K 3.0 this is related to the feature of dropping provisional replies in tm onreply_route upon calling drop.
in sr, provisional replies can be dropped in onreply_route by 'return 0'. are you saying that 'return 0' is not affected, but 'drop' is?
it is very bad and confusing that we ended up having two different cores.
-- juha
On Dec 11, 2009 at 11:58, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
this does not affect SR AFAIK.
In K 3.0 this is related to the feature of dropping provisional replies in tm onreply_route upon calling drop.
in sr, provisional replies can be dropped in onreply_route by 'return 0'. are you saying that 'return 0' is not affected, but 'drop' is?
it is very bad and confusing that we ended up having two different cores.
We should review the differences before the release. For example I think the drop stuff should be in sr_3.0 too.
BTW: a quick way to see the different commits (commits on k_3.0 that are not on sr_3.0) is: git log --oneline --left-right --cherry-pick origin/sr_3.0...origin/kamailio_3.0 |grep "^>"
(the simpler git log --oneline origin/sr_3.0..origin/kamailio_3.0 cannot be used because k was updated with cherry-pick and not with merge)
Andrei
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com