Bad ACK to negative reply

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bad ACK to negative reply

Ben Newlin

Hi,

 

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

 

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?

 

Thanks,

 

Ben Newlin


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Bad ACK to negative reply

Bogdan-Andrei Iancu-2
Hi Ben,

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.

Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/
On 03/22/2019 04:34 PM, Ben Newlin wrote:

Hi,

 

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

 

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?

 

Thanks,

 

Ben Newlin



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Bad ACK to negative reply

Ben Newlin

Bogdan,

 

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?

 

Ben Newlin

 

From: Bogdan-Andrei Iancu <[hidden email]>
Date: Tuesday, March 26, 2019 at 3:27 AM
To: OpenSIPS users mailling list <[hidden email]>, Ben Newlin <[hidden email]>
Subject: Re: [OpenSIPS-Users] Bad ACK to negative reply

 

Hi Ben,

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.

Regards,

Bogdan-Andrei Iancu
 
OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 03/22/2019 04:34 PM, Ben Newlin wrote:

Hi,

 

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

 

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?

 

Thanks,

 

Ben Newlin




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users