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-***@public.gmane.org'; '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-***@public.gmane.org'; 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-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org<mailto:sr-users-***@lists.sip-router.org> [mailto:sr-users-bounces-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.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-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org<mailto:sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda