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(a)gmail.com'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(a)gmail.com'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