| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter.
Scott
I notice that when repro adds a Via to a request, it includes the rport
parameter
When repro makes a TCP (or TLS) connection to another application, the
source port is not the port where repro listens for incoming connections.
Consequently, when other applications try to send a request back to
repro, if the original TCP/TLS connection is no longer active, they try
to open a new connection to the rport rather than the real TCP/TLS port
where repro is listening. Such connections obviously can't succeed.
The rport parameter is automatically added in the Via constructor. DUM
has an option in the UserProfile to disable rport. I couldn't see any
option in repro.config to stop it adding rport.
I see a few possible ways forward here:
- completely stop adding rport in Via from repro
- add a parameter to repro.config
- make repro use (and all of reSIProcate) use the listening port as the
source port for outgoing TCP/TLS connections (SO_REUSEADDR, re-use
listening socket for making new outgoing connections)
Does anybody depend on the existing behavior or can anybody comment on
cases where it is desirable?
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate- devel