After a second thought: This shouldn’t be a problem since the cleanup_uac_timers( t ); function call should clear the timer on all branches and the local 408 shouldn’t be generated at all. So the problem now is why the local 408 were generated. Allen *From:*Allen Zhang *Sent:* Thursday, 24 July 2014 11:11 a.m. *To:* &#39;miconda(a)gmail.com&#39;com'; 'Kamailio (SER) - Users Mailing List' *Cc:* Shane Harrison *Subject:* RE: [SR-Users] MESSAGE forking bug(?) Found the bug (I believe): In t_reply.c, line 2411 (kamailio 4.0.0): done: tm_ctx_set_branch_index(T_BR_UNDEFINED); /* we are done with the transaction, so _unref_ it - the reference * was incremented by t_check() function -_bogdan_*/ This is true only for INVITEs. After a 200 is received for an INVITE, other branches are cancelled, hence it’s save to unref the transaction. But for MESSAGEs, after a 200 is received, other branches may time out and the transaction needs to be found when locally generated 408 hits the server. Can the author of the TM module suggest a solution, please? In the meantime, I’ll try to patch it myself. Cheers, Allen *From:*Allen Zhang *Sent:* Thursday, 24 July 2014 9:23 a.m. *To:* &#39;miconda(a)gmail.com&#39;com'; Kamailio (SER) - Users Mailing List *Subject:* RE: [SR-Users] MESSAGE forking bug(?) Hi, I have a tcpdump capture but the traffic is encrypted. So it won’t help you. I have a clue how it happened: When the first 200 response was received, kamailio successfully matched a transaction: Jul 23 00:40:14 /usr/sbin/kamailio[570]: DEBUG: tm [t_lookup.c:972]: DEBUG: t_reply_matching: hash 51776 label 624824282 branch 2 Jul 23 00:40:14 /usr/sbin/kamailio[570]: DEBUG: tm [t_lookup.c:1032]: DEBUG: t_reply_matching: reply matched (T=0x7fb52d367f50)! But when the locally generated 408 happened, kamailio failed to match a transaction: Jul 23 00:40:44 /usr/sbin/kamailio[583]: DEBUG: tm [t_lookup.c:972]: DEBUG: t_reply_matching: hash 51776 label 624824282 branch 0 Jul 23 00:40:44 /usr/sbin/kamailio[583]: DEBUG: tm [t_lookup.c:1066]: DEBUG: t_reply_matching: no matching transaction exists Because no transaction was matched, kamailio simply forwarded the response. I’ll modify this behaviour in the source code. After receiving the first final response, there is no reason to keep the fr_timer running on other branches, right? Cheers, Allen *From:*sr-users-bounces@lists.sip-router.org <mailto:sr-users-bounces@lists.sip-router.org> [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Daniel-Constantin Mierla *Sent:* Wednesday, 23 July 2014 10:41 p.m. *To:* Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] MESSAGE forking bug(?) Hello, can you get the sip traffic with ngrep on kamailio server? It can be taken with: ngrep -d any -qt -W byline port 5060 Cheers, Daniel On 23/07/14 03:08, Allen Zhang wrote: Hi, I believe there is a bug on MESSAGE forking. Test scenario: User A has two records in the location table, with different instance ids: 111 and 222. One of user A’s instance is killed, hence 222 is not reachable. User B send a MESSAGE to user A. Kamailio forked the MESSAGE. Kamailio got a ‘200 Message delivered’ response from 111 and forwarded it to user B. The MESSAGE forked to 222 timed out. Kamailio send a ‘408 Time out’ to user B. This violates RFC 3428 section 4. It states that the forking UAS should only send ONE final response to the sender UAC. Forking is done by t_relay(), and the registrar parameter ‘append_branches’ is set to default value 1. Did I do something wrong, or there is a bug? Regards, Allen _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda