Wrong IP used in SIP packets

Hello all.

Have a system running with 2 VLANs and 3 Virtual IP’s.

For example:

vln1:1 = (public) vln1:2 = (local for phones) vln2:1 = (local for provider)

My problem is packets intended for the provider have the public IP address in the VIA and from headers, and they are being rejected.

bindaddr= via dev vln2  src

The OS itself does the routing properly and the INVITE leave through the correct interface with the correct IP address, but the headers are incorrect. > SIP, length: 832
Via: SIP/2.0/UDP;branch=z9hG4bK4ee3a9f6;rport
Max-Forwards: 70
From: “Adnan 2” sip:105@[b][/b];tag=as5ea03b1f
Contact: sip:105@[b][/b]:5060
Call-ID: 1db97133259a8dae6f28baa31b5932c6@
CSeq: 102 INVITE
User-Agent: Asterisk
Date: Mon, 12 Oct 2015 11:31:12 GMT
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 273

Any advice how to get this corrected?

Hi, we have a similar problem with the FROM header using the incorrect IP in an asterisk 13 box with PJSIP 2.4.5. Everything works great with a single NIC (eth0), but we recently added a SIP Trunk connected directly via a second NIC (eth1). There’s a transport bound to each IP with the correct local_net and external IP addresses.
Our SIP phones register to the asterisk box but the FROM header in the replies has the wrong IP address and after a couple seconds contacts appear as unavailable, qualify shows them as unreachable, extensions are never rung from call queues with ringinuse disabled, etc.
The phones IP address and the “private” asterisk IP are in the same subnet (also tried defining static routes, just to be sure). See below:

<— Received SIP request (728 bytes) from UDP: —>
Via: SIP/2.0/UDP;branch=z9hG4bK-852d98d7
From: “7700” sip:7700@>;tag=d3ce0a172a69657fo0
To: “7700” sip:7700@>
Call-ID: ac66b77b-cf67f2aa@
CSeq: 55647 REGISTER
Max-Forwards: 70
Authorization: Digest username=“7700”,realm=“XXXXXXX”,nonce=“1459972607/XXXXXXXXXXXXXXX”,uri=“sip:”,algorithm=MD5,response=“XXXXXXXXXXXX”,opaque=“XXXXXXXXXXXXXXX”,qop=auth,nc=XXXXXXXXX,cnonce="XXXXXXXXXXX"
Contact: “7700” sip:7700@>;expires=3600
User-Agent: Cisco/SPA514G-7.5.2
Content-Length: 0
Supported: replaces

> – Added contact ‘sip:7700@’ to AOR ‘7700’ with expiration of 3600 seconds
> Contact 7700/sip:7700@ has been created
> Endpoint 7700 is now Reachable

Up to here everything looks normal, but the very next packet looks like this:

<— Transmitting SIP request (422 bytes) to UDP: —>
OPTIONS sip:7700@ SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPjb6540303-776b-4bb2-b635-e1d879206dac
From: sip:asterisk@>;tag=8f7f8d5d-70bd-474a-9c49-907c5f48e35e
To: sip:7700@>
Contact: sip:asterisk@>
Call-ID: 4e1f31e8-87a6-4660-b72c-db3a5b50b4a9
Max-Forwards: 70
User-Agent: Newlink Peru PBX
Content-Length: 0

<— Transmitting SIP response (414 bytes) to UDP: —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP;received=;branch=z9hG4bK-852d98d7
Call-ID: ac66b77b-cf67f2aa@
From: “7700” sip:7700@>;tag=d3ce0a172a69657fo0
To: “7700” sip:7700@>;tag=z9hG4bK-852d98d7
CSeq: 55647 REGISTER
Date: Wed, 06 Apr 2016 19:56:47 GMT
Contact: sip:7700@>;expires=3599
Server: Newlink Peru PBX
Content-Length: 0

<— Transmitting SIP request (422 bytes) to UDP: —>
OPTIONS sip:7700@ SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPjb6540303-776b-4bb2-b635-e1d879206dac
From: sip:asterisk@>;tag=8f7f8d5d-70bd-474a-9c49-907c5f48e35e
To: sip:7700@>
Contact: sip:asterisk@>
Call-ID: 4e1f31e8-87a6-4660-b72c-db3a5b50b4a9
Max-Forwards: 70
User-Agent: Newlink Peru PBX
Content-Length: 0

> Contact 7700/sip:7700@ is now Unreachable. RTT: 0.000 msec

What version of Asterisk are you using? A fix recently went in for OPTIONS to ensure it was tied back to an endpoint to ensure all the settings were correct. As well: What is the precise network topology with interfaces?

Hi jcolp, we running Asterisk 13.7.2 on a x86_64 box running Centos 6.

eth0: - default route
eth1: - only traffic destined to SIP Trunk Provider hosts routed here.

Phones reside in the same subnet.

Endpoint: 7700 Unavailable 0 of 1
InAuth: 7700/7700
Aor: 7700 2
Transport: udp-endpoints udp 0 0

ParameterName : ParameterValue

100rel : yes
accountcode : XXXXXXXXXX
aggregate_mwi : true
allow : (ulaw|g729)
allow_subscribe : true
allow_transfer : true
aors : 7700
auth : 7700
call_group :
callerid : Recepci▒n
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
context : from-XXXXXXXXXX
cos_audio : 0
cos_video : 0
device_state_busy_at : 1
direct_media : false
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
force_avp : false
force_rport : false
from_domain :
from_user :
g726_non_standard : false
ice_support : false
identify_by : username
inband_progress : false
language : es
mailboxes :
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_suggest : es
mwi_from_user :
named_call_group : peru
named_pickup_group : peru
one_touch_recording : false
outbound_auth :
outbound_proxy :
pickup_group :
record_off_feature : automixmon
record_on_feature : automixmon
rewrite_contact : true
rpid_immediate : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : false
rtp_timeout : 28800
rtp_timeout_hold : 3600
sdp_owner : -
sdp_session : Asterisk
send_diversion : true
send_pai : true
send_rpid : false
set_var :
srtp_tag_32 : false
sub_min_expiry : 0
t38_udptl : false
t38_udptl_ec : none
t38_udptl_ipv6 : false
t38_udptl_maxdatagram : 0
t38_udptl_nat : false
timers : yes
timers_min_se : 90
timers_sess_expires : 1800
tone_zone :
tos_audio : 0
tos_video : 0
transport : udp-endpoints
trust_id_inbound : true
trust_id_outbound : true
use_avpf : false
use_ptime : false
user_eq_phone : false

  Aor:  7700                                                 2
Contact:  7700/sip:7700@              bb6e7fb6f4 Unavail       0.000

ParameterName : ParameterValue

authenticate_qualify : false
contact : sip:7700@
default_expiration : 3600
mailboxes : 7700@peru
max_contacts : 2
maximum_expiration : 7200
minimum_expiration : 60
outbound_proxy :
qualify_frequency : 60
qualify_timeout : 3.000000
remove_existing : false
support_path : false

nlpehqspbx01*CLI> pjsip show contact 7700/sip:7700@

Contact: 7700/sip:7700@ bb6e7fb6f4 Unavail 0.000

nlpehqspbx01*CLI> pjsip show transports

Transport: udp-endpoints udp 0 0
Transport: udp-trunk udp 0 0

nlpehqspbx01*CLI> pjsip show transport udp-endpoints

Transport: udp-endpoints udp 0 0

ParameterName : ParameterValue

async_operations : 1
bind :
ca_list_file :
ca_list_path :
cert_file :
cipher :
cos : 0
domain :
external_media_address : XXXXXXXXXXXX
external_signaling_address : XXXXXXXXXXXX
external_signaling_port : 5060
local_net :
method : unspecified
password :
priv_key_file :
protocol : udp
require_client_cert : No
tos : 0
verify_client : No
verify_server : No
websocket_write_timeout : 100

nlpehqspbx01*CLI> pjsip show settings

Global Settings:

ParameterName : ParameterValue

debug : no
default_from_user : asterisk
default_outbound_endpoint : default_outbound_endpoint
endpoint_identifier_order : ip,username,anonymous
keep_alive_interval : 0
max_forwards : 70
max_initial_qualify_time : 0
user_agent : Newlink Peru PBX

System Settings:

ParameterName : ParameterValue

compact_headers : false
disable_tcp_switch : false
threadpool_auto_increment : 5
threadpool_idle_timeout : 60
threadpool_initial_size : 0
threadpool_max_size : 50
timer_b : 32000
timer_t1 : 500

I would suggest upgrading to 13.8.0 and trying that. There was a particular change for the OPTIONS generation which may improve this.

I am struggling with a similar issue with a fresh install of 13.10. The box has two interfaces: eth0 (public IP x.x.x.x) and tun3 (OpenVPN to another site, IP

I am trying to connect via the tunnel from a softphone on, which sends SIP packets to just fine. They seem to be ignored though. At the same time, Asterisk is sending SIP packets to which although they are routed correctly, they have a Source address of the public IP x.x.x.x and that IP is also contained inside the SIP packet.

I tried, in sip.conf:

However, in the CLI, sip show settings has only one bind address, the public one x.x.x.x. Also, lsof confirms that sip is binding only to that address. That would explain why - even when sending to an internal (although not local) address, Asterisk is using its public address x.x.x.x

The same scenario (two bind addresses) seems to work fine with IAX.

Is it the case that SIP can only bind to a single address, or to all addresses? That’s a significant limitation…

A few days ago a friend of mine had a simmilar problem, an Asterisk with two trunks coming from the same provider. Only one route was being used all the time, so one of the trunks wouldn’t work.

The routing part I could solve using table routing in the Asterisk machine (running Red Hat Linux).

The basic setup is here:


With table routing you create routing entries at the /etc/iproute2/rt_tables file, populate these tables with the adequate routes and add them to the interfaces configuration file.

The problem is, for this setting work the calls originated from each trunk should have a network address from the same network from the trunk coming from the operator, but all packets were from the network from the same trunk.

The person running the Asterisk configuration said that wasn’t available in Asterisk.

In particular these trunks were from the same provider and SBC, so both entries had the same “host=” parameter.

The customer had to request that the second trunk to come from another SBC in that case.

SIP cannot cope with having parallel trunks. Why should it? There are no physical limits as there would be with circuit switched trunks. SIP was not designed with commercial needs in mind, so assumes that you do things in the most engineering efficient manner.

If you want to distinguish, you must do it on IP address, port (make sure you don’t put insecure=very or insecure=port, as is often done by cookbook users), or you must use type=user, in which case you cannot use From: for Caller ID.

Generally, all of these need help from the ITSP.