Bug 137 - tries to use wrong port when opening stream-oriented connections for sending responses
Summary: tries to use wrong port when opening stream-oriented connections for sending ...
Status: NEW
Alias: None
Product: resiprocate
Classification: Unclassified
Component: stack (libresip) (show other bugs)
Version: unspecified
Hardware: All All
: P1 major
Assignee: Owner of all unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-05 03:34 CST by Daniel Pocock
Modified: 2016-12-05 03:34 CST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pocock 2016-12-05 03:34:23 CST
RFC 3261 s18.2.2 specifies the procedure to select a port for sending a response:
https://tools.ietf.org/html/rfc3261#section-18.2.2

Behavior observed:
- if the request was received over a reliable transport with rport in the Via header the stack correctly sends the response over the same connection
- if the connection has dropped, however, the stack tries to open a new connection to the rport instead of the port advertised by the sender in the Via header

The rport should only be used for unreliable transports (UDP)
http://list.resiprocate.org/archive/resiprocate-devel/msg09277.html

TransportSelector.cxx:1115 onwards tries to work out where to send the response (which transport and port to use), maybe it should do a check to see if the connection is still active or not?

In TcpBaseTransport::processAllWriteRequests
TcpBaseTransport:345
the stack checks if the connection has gone away and at this point it tries to use data->destination (including the port number of the original connection from the peer) and doesn't try to revise the port number.

Helper::getPortForReply() appears to correctly decide the preferred port number for those cases where the original connection is still active.