[bug]: chan_pjsip uses wrong IP in SIP messages if at least two ip addresses are configured
thaeger71 opened this issue · comments
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
I assume you are referring to SIP messages using PJSIP. What is the transport configuration?
Additionally, res_hep is community supported.
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
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 ?
If the underlying cause appears to be that, then you can edit this issue if you wish.
@thaeger71 Are you specifying "transport" on the endpoints sending the requests? Can you include the full endpoint configuration?
Also, you should include the netmask in the transport "local_net" parameters otherwise it defaults to 255.255.255.255.
This issue has been marked stale because it has been open 7 days with no feedback. Please provide feedback within 7 days or this issue will be closed.
Hello,
meanwhile I discovered that the problem was caused by the fact that the second IP (192.168.2.1) was on a virtual interface (eth0:1). In this case chan_pjsip or res_hep_pjsip.so takes the wrong address. Now I have a real dedicated NIC and it works.
Feel free to investigate this further, or closes this. I think it must be a very little bug, but I have a working solution now.
This issue has been marked stale because it has been open 7 days with no feedback. Please provide feedback within 7 days or this issue will be closed.