[OpenSIPS-Users] Source port changing during a transaction
John Quick
john.quick at smartvox.co.uk
Tue Jun 26 12:16:27 EDT 2018
Hi Bogdan,
Thanks for responding.
In this case, the issue is not about info in the Contact or Record-Route headers. It is about the topmost Via header.
The source port for the first INVITE is 59500. 'rport' is present so OpenSIPS sends the "100 Trying" to port 59500. [The script also calls force_rport()]
Then the UAC sends the same INVITE again (a duplicate, not strictly a re-INVITE), but it sends it from port 5062.
OpenSIPS continues to send responses to port 59500 and ignores the new source port.
I suspect this is because it sees the second INVITE as a duplicate and discards it as unnecessary, but it made me think about the wider issues and what the RFC's tell us about this topic.
In my opinion, the UAC in this example is badly behaved because it sent a different port (5062) in the Via but it also sent the 'rport' parameter. The latter would take precedence over the former. However, we can see that the UAC really wanted us to send all responses to port 5062. So it should not be sending 'rport' at all and also my script should not be calling force_rport().
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: 26 June 2018 15:21
To: john.quick at smartvox.co.uk; OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Source port changing during a transaction
Hi John,
According to RFC3261, a re-INVITE or UPDATE can change only the remote contacts (the end point contacts), but not the Record-Route hops.
In order to properly reflect the change of the port at network level, of course, the SIP contact URI has to be changes (via re-INVITE or UPDATE).
You say that OpenSIPS with dialog + TH does not obey this ? (it might be true :D)
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 06/25/2018 08:08 PM, 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
More information about the Users
mailing list