[OpenSIPS-Users] Source port changing during a transaction

[Bogdan-Andrei Iancu]

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 <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