Greetings,
I have an issue where a client doesn't get the responses to the INVITE sent and as such keeps sending me retransmissions of the INVITE.
While the transaction is still up, Kamailio does its job. However, when the transaction is closed Kamailio processes the request again as a first request (Doing Routing and Dispatcher operations again).
In order to avoid the issue i've made the following code :
// If it's the first INVITE if( is_method("INVITE") && !has_totag() ) { if(t_check_trans()) { xnotice("TRANS - INVITE Retransmission"); } else if ( is_known_dlg()) { xerr("KamTAG: INVITE in dialog without To Tag "); exit; } }
Is this a good solution and still compliant with the SIP rules?
Best Regards
I would look to learn more about the ultimate cause of retransmissions arriving beyond the life cycle of the transaction in Kamailio, as it seems to possibly portend of a bigger problem.
However, if the issue is one of retransmissions arriving just beyond the expiration of Kamailio's transaction lifetime holddown timers, you can tweak those:
https://kamailio.org/docs/modules/5.3.x/modules/tm.html#tm.p.wt_timer
https://kamailio.org/docs/modules/5.3.x/modules/tm.html#tm.p.max_inv_lifetim...
-- Alex
On Tue, May 12, 2020 at 05:15:15PM +0100, Duarte Rocha wrote:
Alex' suggestions about investigating further the cause are good.
What I wanted to say is the if dialog module is used only for this purpose, then you can look at implementing a similar check with htable, the key can be:
$ci:$cs:$ft
respectively the call id, cseq and from tag. Of course guarded to see it is an invite with no to-tag.
If you want to be even more strict, in case of parallel forking from upstream, you can add top via branch to the key.
Cheers, Daniel
On 13.05.20 04:29, Alex Balashov wrote:
Hello Alex and Daniel,
Thank you for your answers.
This happened when a client had some network problems and couldn't received my packets. The problem is that after some time and the transaction is dead,since Kamailio does a new dispatcher, my accounting system counts this as two calls and that's the behaviour i want to avoid. Since in this case the client has network issues and won't probably get the SIP replies, i don't think raising the timers will be very helpfull.
Also, i already use Dialog module for other functionalities so i don't think there's a need to go to hash tables.
Thanks for the help.
A terça, 12/05/2020, 17:15, Duarte Rocha duarterocha91@gmail.com escreveu: