Wrong UDP destination port in response message after failover within proxied SIP call

[posfaig]

When executing the following SIP flow, the destination port of the last 200 OK response is set incorrectly:

INVITE ----------> 100 <---------- 180 <---------- 200 <---------- Pause [ 300ms] ACK ----------> Pause [ 20.0s] BYE ----------> 200 <----------

The scenario if the following: requests from the sender go to a load balancer which dispatches the request to a SIP proxy, which forwards the request to the receiver. At the second pause, there is a failover at the server: the used proxy node is stopped and a new proxy node takes over. The BYE request is already forwarded by the new proxy node(, with new port number), and the Via header also seems to be correctly set to the port of the new node. However, the last 200 OK response is still directed to the port of the original proxy node.

Please find attached the screenshot of the trace. The port number of the original proxy node is 5280, and the port of the new proxy node which takes over after failover is 5080. As can be seen in the SIP messages: the BYE message is forwarded to the receiver leg through the new 5080 port, and the Via header of the BYE message also contains port 5080, but the 200 OK is sent to the 5280 destination port.

[nshopik]

We seen same behavior, if BYE come from different port than original INVITE when dialog created it will send 200 OK to old port.

From my understanding Via header completely ignored and datagram sent to original dialog creator in my tests, we are using uac and uas scenarios.

[carlosrav]

Hi, there are not fix for this? I have the same problem, if BYE it´s send from other port( not the Invite port) then the VIA it´s ignored

[nshopik]

@wdoekes Any chance you could help tracking this issue? I wonder whatever this parsing issue or sipp just doesn't keep track of remote port at all

[wdoekes]

As far as I'm aware, SIPp never changes the destination. It will update the [next_url] when using rrs=true, but at the socket layer, nothing changes. And as for responses, I don't think it does anything with a changed source port/ip.

[Maratk1n]

I use SIPp as UAS, and have the same issue. In my opinion after ACK/BYE SIPp should send the last 200 OK response to port 5061.

[rkday]

You should be able to work around this with setdest (https://sipp.readthedocs.io/en/v3.6.1/scenarios/actions.html#setdest) which is currently the only way to change the destination of an active call.

It's possible that we could do something more automatic, but there are edge cases, e.g:

• receive INVITE
• receive CANCEL
• send 487 to INVITE
• send 200 to CANCEL

where you don't just want to be setting the destination of the response based on the Via of the last received message - so I think manual control of this with setdest is probably reasonable.