[OpenSIPS-Users] Bad ACK to negative reply
Ben.Newlin at genesys.com
Tue Mar 26 08:45:44 EDT 2019
That is good to know, but if that is the case then can you see any reason why the ACK would not be recognized? I am trying to gather debug logs from OpenSIPS for an occurrence but it is very intermittent.
Out of curiousity, what functionality is the “i” param being inserted for?
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Tuesday, March 26, 2019 at 3:27 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] Bad ACK to negative reply
OpenSIPS, when doing transaction matching with VIA hdr, is checking the branch, transport, host and port parts only , so the "i" param will be ignored.
OpenSIPS Founder and Developer
OpenSIPS Summit 2019
On 03/22/2019 04:34 PM, Ben Newlin wrote:
I am seeing some strange behavior handling hop-by-hop ACKs to negative replies. A trace of my scenario can be found here: https://pastebin.com/Ve8rnYnu<https://pastebin.com/Ve8rnYnu>
The problem is that intermittently the OpenSIPS instance receiving the ACK is not recognizing. t_check_trans is returning false for this ACK.
The only thing I can see I that the Via header in the ACK is not the same as in the INVITE, which is required by the RFC. The ACK is missing the “i=03ba9232” parameter that was on the Via for the initial INVITE. This parameter was not on the initial INVITE and is being added by the OpenSIPS instance that is forwarding the INVITE. What is this parameter for? Shouldn’t it be included on the ACK? Can anyone see any other reason the ACK would not match?
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users