Incoming trunks - help

I noticed something odd today…

I have two totally separate accounts with voip.ms for two separate companies that both hit the same server. The server is setup with both trunks (trunk A and trunk B), and there are two inbound routes, one with each CID that route the calls to extensions depending on which company the call is for.

This works great… but for some reason when I look at the FOP or the asterisk CLI it shows all calls coming in on trunk A! I can confirm by checking the CDR’s at voip.ms that the calls are being billed out the separate trunks as they should, but for some reason asterisk just throws all incoming calls in the same trunk and lets the incoming route sort it out.

I tried trunk incoming settings that are blank, and allowing anonymous SIP connections, and I tried no anonymous and setting the incoming user details… no difference.

How can I fix this? It’s not a problem except when you look at the FOP and all calls are coming in the same trunk.

You might want to contact Nicolás Gudiño. He wrote FOP. If you go to
http://www.asternic.org/

There is a chat link in the lower right. He will probably want to know what version of FOP you have.

To find Flash Operator Panel version:

Find where op_server.pl is located:
[email protected]:/ $ find / -name op_server.pl
/usr/src/freepbx/amp_conf/htdocs_panel/op_server.pl
/var/www/html/panel/op_server.pl
/var/www/html/admin/modules/fw_fop/htdocs_panel/op_server.pl

Goto that directory:

[email protected]:/ $ cd /var/www/html/admin/modules/fw_fop/htdocs_panel

And run the command below:

[email protected]:/var/www/html/admin/modules/fw_fop/htdocs_panel $ ./op_server.pl -v

The result will look something like this:

    op_server.pl version 0.30

Question: you are operating from behind a firewall and utilizing NAT, right?

If so, this is an asterisk sip issue. asterisk can only listen on ONE (1) IP ADDRESS/PORT pair. From voip.ms’ point of view, both your trunks are 1.2.3.4:xxxxx. You need 1.2.3.4:aaaaa and 1.2.3.4:bbbbb, and asterisk does NOT work that way.

You can build logic into the dial plan so that it branches on the DID or the ACCTCODE, but you need to author it into the dial plan manually.

/S