I’ve got trunks with a few providers already and all work fine. I’m attempting to add bandwidth.com to the mix, but I can make outbound calls fine, but inbound calls just present a disconnected message. Perhaps it has something to do with the e164 stuff, not sure. Is there anything specific I need to do on my end to get inbound calls flowing from bandwidth?
Ok, I just figured it out…It’s the way they present the call in e164 format, I simply had to add a +1 to the beginning of the DID in the inbound route & my inbound calls started working.
Or you could have used the context from-pstn-e164-us on your trunk.
Thanks Jared. That’s great advise. Let me try it.
I tried context=from-pstn-e164-us
on my incoming side of the trunk, still call wouldn’t pass thru until I added the +1 in front of the DID on the inbound route
Then it’s not true e164, whereby the + is a ‘meta-character’ that is a ‘place-holder’ for the locale specific international dial code, (011 for NANPAland, 001 for most everywhere else).
But that context’s concept is still robust, it attempts to ‘normalize’ all calls inbound to the precise dial pattern your client expects. In US that might be 1NXXNXXXXXX and/or NXXNXXXXXX, (check the front pages of your white pages)
Your phonebooks/directories should look and behave appropriately for your users so you need to symmetrically mangle your outbound trunk dialing , to ensure your locale specific dial expectations are enforced to the various vsps
Often with soft phones, you must bear in mind that they have meta + keys (long press of 0) , most hard phones don’t, cover both scenarios if necessary.
That way, a) the clients are happy, b) so are your vsp’s, which c) makes you happy too. 
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.