Multiple SIP circuit to same SIP provider with difference IP


My setup include one freepbx(freepbx-1) with single NIC.

The NIC has bind to a private IP : with default gateway which is a Cisco ASA doing NAT to SIP provider. All IP phone is on network.

The SIP provider assign an IP address : a.b.c.d. for freepbx-1 to connect to their SIP server w.x.y.z. I must use this IP a.b.c.d to get connection to SIP server w.x.y.z because SIP provider will base on source IP a.b.c.d to accept the CID freepbx-1 send out. This SIP circuit provide 100 public phone number(CID-1) to use.

Current status:
All public phone number is used and I have request another set of 100 public phone number(CID-2). The SIP provider has assign second set of IP address e.f.g.h for freepbx-1 to connect to the same SIP server w.x.y.z for using the additional 100 public phone number(CID-2).

My problem is I can only setup one static route on ASA to the SIP server w.x.y.z via a.b.c.d or e.f.g.h. If I setup via a.b.c.d than SIP server won’t accept CID-2. If I setup via e.f.g.h than SIP server won’t accept CID-1. So I can’t setup 2 static route to the same destination and SIP Provider only has 1 SIP server to use.


  1. Is it possible to setup multiple NIC in freepbx for difference SIP circuit?
  2. How to setup freepbx to pick the correct NIC to use base on CID not IP routing?
  3. Or should I setup a new freepbx server(freepbx-2) for new SIP circuit and route the call from freepbx-1 to freepbx-2?


Correction : All IP phone is on network.

Hi, How is your SIP provider expecting registration.

Some use the SIP telephone number, others the Public IP address and other a username and password.

Also are you able to define your own registration port, i.e. does your SIP provider allow you to change the default UDP 5060 port being used ?

Depending on the registration type and or UDP port being used you could just use your ASA and just create multiple trunks on your PBX all using the same default gateway.

The SIP provider use Public IP address with default UDP 5060.

While there may be a huge hack to fix this, your provider messed up and created a new trunk instead of assigning the DID’s to the existing trunk.

They should be able to resolve this.