[OpenSIPS-Users] Source port changing during a transaction

[Liviu Chircu]

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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users