Hi John,
According to RFC 3261§ 18.1.1:
For unreliable unicast transports, the client transport MUST be
prepared to receive responses on the source IP address from which the
request is sent (as responses are sent back to the source address)
and the port number in the "sent-by" field. Furthermore, as with
reliable transports, in certain cases the response will be sent
elsewhere. The client MUST be prepared to receive responses on any
address and port that would be selected by a server based on the
procedures described in Section 5 of [4].
Here is a possible scenario which mandates the above:
Suppose, by absurd, that there is an added 600 ms UDP delay between your UAC
and its proxy. This will lead to two INVITEs: one from source port 59500,
and a retransmission from source port 5062 (which is now the only "real"
accepted return port from the UAC's perspective). Next, suppose UDP
INVITE #2
gets lost on the way, along with any additional 5 retransmissions, and
OpenSIPS never
gets a chance to learn about source port 5062. It will naturally respond to
source port 59500, along with pushing all other UDP replies to it. A port
which has already been invalidated by some unknown reason -- the proxy
cannot
do anything to help the UA in this case. It's completely their fault.
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 25.06.2018 20:08, John Quick wrote:
Is it permissible according to the relevant RFC's for the address and/or
port where responses are sent to change during a transaction?
[I assume it must be okay within a dialogue, such as if a re-INVITE is
sent?].
This is why I am asking:
I have been checking through a pcap capture for a UAC device that is sending
INVITE requests to OpenSIPS.
The topmost Via has the rport parameter present - this tells OpenSIPS to
respond to the source port of the request.
There are some configuration issues which mean the response fails to reach
the UAC.
So the UAC sends the same INVITE request again, but this time it sends from
a different port.
OpenSIPS continues to send responses to the source port of the first INVITE
and ignores the source port of the second INVITE.
UAC port 59500 ---- INVITE -------> OpenSIPS Proxy
UAC port 59500 <--- 100 Trying --- OpenSIPS Proxy
UAC port 5062 ---- INVITE -------> OpenSIPS Proxy
UAC port 59500 <--- 100 Trying --- OpenSIPS Proxy
The CSeq and Call-ID on both INVITE requests are identical - only the source
port changed. Is this why the second INVITE has no impact on where the
responses are sent?
Or is there something special about the first request in a transaction that
fixes the destination address/port for all subsequent responses?
The OpenSIPS Proxy in my pcap example uses topology hiding which could, I
suppose, be relevant. It is OpenSIPS v 1.9.
Thanks.
John Quick
Smartvox Limited
Web: www.smartvox.co.uk
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
