Incorrect Routing

I have one account at Voicepulse with two sets of credentials and one DID on each set of credentials. Both are being routed to one server, where I have two different inbound routes, one for each number. Each route goes to a different time condition and then to separate ring groups which are location in two different locations. Recently however, I have been told that calls are sometimes ringing at the wrong location, even though the two inbound routes lead to two completely different places with no intersecting points after the call reaches the PBX. Could this be happening because all channels are busy on one DID so it automatically routes to to the other location? I am at a loss for what is happening here. Any help would be greatly appreciated.

I have observed that this sometimes happens when you have two accounts coming off the same server. If the provider offers you a choice of servers, try using a different server for each account (try to make sure it’s truly a different server, not two addresses that resolve to the same server).

Also, see How to get the DID of a SIP trunk when the provider doesn’t send it (and why some incoming SIP calls fail) - you might be able to find some difference in the SIP headers sent by the two accounts, that you can then use as a more reliable trigger to set the actual DID.

This is a characteristic(*) of asterisk v1.4.25 (and earlier), not freepbx, when two (2) or more sip PEER (or FRIEND) registrations are in effect with the same provider such that YOUR IP:PORT and THEIR IP:PORT are the same for the registrations, then ALL inbound calls – from the provider to your asterisk – will present on the LAST to register PEER’s/FRIEND’s context. The last to register is typically the last provider-relevant PEER/FRIEND in the /etc/asterisk/sip_additional.conf

Since asterisk will “listen” on one – and one only – local UDP port at a time (default 5060), it is NOT currently (v1.4.25) possible to alter on a per PEER/FRIEND-basis your IP:PORT pair.

In your TRUNK’s dial plan context=<your trunk’s context>, you can test for the actual sip PEER/FRIEND ID (account), it will be correct, per your provider’s DID/account assignments, and you can then route (re-route) accordingly (e.g. GotoIf(…?account1-context,${EXTEN},1).

Good luck,

(*) calling it a “bug” seems to be up for debate in the support forums.

Thanks for the response. That seems to make sense. So this is not the case is 1.4.26 and up?

I recently accepted the YUM UPDATE on my asterisknow 1.5 (release). It bumped me to asterisk 1.4.26. from My inbound’s are still ringing on the second trunk (last to register).

On the advise of my VSP’s tech support, a while back, I popped a virtual machine with the TRIXBOX/ASTERISK v1.6 – with the same results. But I didn’t spend too much time with it.

So AFAIK, and I’m still a tadpole too, I don’t think this is, in fact, “resolved.” As mentioned before, “resolved” means “bug” and I don’t think it’s been accepted as a “bug.” Technically at the SIP layer, in a NAT topology on a like-to-like IP:PORT-to-IP:PORT coupling, it’s working. Just that, for some (you and formerly me), it is presenting admin/accounting challenges that are otherwise testable and solvable with some “extra” dialplan work.

Depending on whether to need to do this little (e.g dial plan work) or big (e.g. install a Kamailio (OpenSER) edge router) it is solvable without asterisk code “fixes.”


This is simply not true. We have 5060-5063 on our PEER definitions to simplify gateway registrations through NAT.

If I’m not mistaken, you are defining the far-side’s sip peer port (port=<>), thusly “speaking to,” not yourself (bindport=<>) which is “listening on.”

Per-peer basis port=<> works.

Everything I’ve read and tried says you can only listen (bindport=<>) on one port as defined in the sip [general] section, not the peer section.

I’d be glad to receive the *.conf files supporting multiply defined bindport=<> ports.


So this can all be solved by getting an asterisk friendly router?

I could have been mistaken for a very long time. If port in the peer sets the destination port not target.

I thought we programmed our ATA’s for port 5061 on the second line.

It would work if the remote device listened on that port and then sent to the bindaddr. Now I have to question the config in the ATA’s

Something I need to research before opening my mouth again.

I don’t think you’re mistaken, but what do I know? All I know is that EVERY two-line ATA we have on our system uses 5060 and 5061 on the two lines (and we have both ports forwarded to the FreePBX box in the router).

Of course most of us here really are not networking experts, so we do what someone told us to do in the distant past, and then pass those same techniques along to the newbies, whether those techniques are actually needed or not. Give it a few hundred years and networking will have become a religion, with its own rituals that make no sense except that everyone’s afraid not to do them! :wink:

yes, there’s a lot of superstition in computers.

We’re agreeing on the same thing. The ATA’s PORT config relationship to the asterisk config is port=5060 and port=5061. The asterisk port is bindport=5060. My ATA when I used one was like that. My 6-line Grandstream sip phone works similarly – each “line” has its own sip peer sip port (i.e. ext=1000 port=5062, ext=2000 port=5064, … ext=6000 port=5072); however asterisk is still listening on bindport=5060.

As port=<something_or somethings> is not in question, I just looped the following three test settings of this on my box:


In the first two tests the resulting LISTENING port was 5060 ONLY, no 5070. In the third test, the second occurrence of “bindport” set the listening port to 5070, no 5060.


asterisk -rx “sip show settings”

asterisk CLI: sip set debug


Check out forums and you’ll see the others experiencing the same.

As asked before, if someone has the *.conf of a working multiple bindport= setup, there’d be some happy users – here and on

im not sure if any of this answers my question…do I just need to get a voip compatible router to solve this issue?

I don’t know how Voicepulse sends their calls or how they manage multiple DIDs per account. I can tell you that all the discussion would be irrelevant how we do it on the SIPSTATION service if you choose 10 digit DID format as your deliver mechanism.

In that case, the DID that is called is what we use in the INVITE, regardless of how you registered. By doing such, it will always be routed correctly.

The comment made above about ‘the last registration wins’ (so to speak) only occurs when a provider uses the ‘tail end’ of your registration to choose where to send your calls. (e.g. user:[email protected]/DID) then they use ‘DID’. If you don’t have anything there, it’s equivalent to having put ‘/s’ and it would be sent to the ‘s’ extension. In this case, if you have multiple registrations to a provider, the last one is what they will remember. This is the problem with counting on that format.

I don’t have any idea how VoicePulse does it, so I am not suggesting it is or it is not. I’m just trying to explain the reasoning behind some of the suggestions above. In the same note, you can take it as making design choices in the service we provide with SIPSTATION that comes directly from years of experience seeing all the issues and hoops that users of Asterisk based systems have had to go through and trying to design a service that works as expected in this environment.