[bug]: chan_pjsip uses wrong IP in SIP messages if at least two ip addresses are configured

[thaeger71]

Severity

Major

Versions

18.20.2

Components/Modules

chan_pjsip.so

Operating Environment

freePBX/RHEL

Frequency of Occurrence

Constant

Issue Description

If freePBX/asterisk has two source IP addresses, for example 192.168.1.100 and 192.168.2.100 (even in this order), asterisk uses 192.168.2.100 as source address in SIP message text, for example server part in CONTACT header, even it was sent from 192.168.1.100 in reality.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

[jcolp]

I assume you are referring to SIP messages using PJSIP. What is the transport configuration?

Additionally, res_hep is community supported.

[thaeger71]

yes, it's PJSIP. So the problem ist maybe located in res_hep_pjsip.so
Transport doesn't matter, I tried UDP and TLS.

Transport configuration looks like this:

;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. ;
;--------------------------------------------------------------------------------;
; For information on adding additional paramaters to this file, please visit the ;
; FreePBX.org wiki page, or ask on IRC. This file was created by the new FreePBX ;
; BMO - Big Module Object. Any similarity in naming with BMO from Adventure Time ;
; is totally deliberate. ;
;--------------------------------------------------------------------------------;
#include pjsip.transports_custom.conf

[192.168.1.100-udp]
type=transport
protocol=udp
bind=192.168.1.100
allow_reload=no
tos=cs3
cos=3
local_net=192.168.1.0

[192.168.2.100-udp]
type=transport
protocol=udp
bind=192.168.2.100
external_media_address=85.215.175.45
external_signaling_address=85.215.175.45
allow_reload=no
tos=cs3
cos=3
local_net=192.168.2.0

[192.168.1.100-tcp]
type=transport
protocol=tcp
bind=192.168.1.100
allow_reload=no
tos=cs3
cos=3
local_net=192.168.1.0

[192.168.2.100-tcp]
type=transport
protocol=tcp
bind=192.168.2.100
external_media_address=85.215.175.45
external_signaling_address=85.215.175.45
allow_reload=no
tos=cs3
cos=3
local_net=192.168.2.0

[192.168.1.100-tls]
type=transport
protocol=tls
bind=192.168.1.100
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
cert_file=/etc/asterisk/keys/testlab.1und1.net-fullchain.crt
priv_key_file=/etc/asterisk/keys/testlab.1und1.net.key
method=tlsv1_2
verify_client=no
verify_server=no
allow_reload=no
tos=cs3
cos=3
local_net=192.168.1.0

[192.168.2.100-tls]
type=transport
protocol=tls
bind=192.168.2.100
external_media_address=85.215.175.45
external_signaling_address=85.215.175.45
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
cert_file=/etc/asterisk/keys/testlab.1und1.net-fullchain.crt
priv_key_file=/etc/asterisk/keys/testlab.1und1.net.key
method=tlsv1_2
verify_client=no
verify_server=no
allow_reload=no
tos=cs3
cos=3
local_net=192.168.2.0

[thaeger71]

Hi,
I have news about this issue. The problem seems not be res_hep or res_hep_pjsip, the problem seems to be in asterisk or chan_pjsip. I traced a SIP registration from an account which is definitively bound to ip 192.168.1.100. In the trace, the package was even send from 192.168.1.100. But, in the REGISTER message, the contact field contains the second ip 192.168.2.100.

Should we close this case and open a new one ?

[jcolp]

If the underlying cause appears to be that, then you can edit this issue if you wish.