[SR-Users] MESSAGE forking bug(?)

Daniel-Constantin Mierla miconda at gmail.com
Thu Jul 24 15:05:47 CEST 2014


Can you try over tcp? It would be the same case as for tls from forking 
point of view. It will speed up if I get the SIP trace, as I have quite 
loaded schedule for the moment to test it myself.

Cheers,
Daniel

On 24/07/14 01:41, Allen Zhang wrote:
>
> 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:* 'miconda at gmail.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:* 'miconda at gmail.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 at lists.sip-router.org 
> <mailto:sr-users-bounces at lists.sip-router.org> 
> [mailto:sr-users-bounces at 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 at lists.sip-router.org  <mailto:sr-users at 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

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140724/5acdea7a/attachment.html>


More information about the sr-users mailing list