Hi John,
Oh, I see, it is not at dialog level, but transaction level. Now, when
you say "UAC sends the same INVITE again", you mean a retransmission ?
IF so, indeed, the retransmission is discarded without any impact on the
existing transaction.
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/26/2018 07:16 PM, John Quick wrote:
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 <[email protected]>
Sent: 26 June 2018 15:21
To: [email protected]; OpenSIPS users mailling list
<[email protected]>
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
[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
