IP Trunking and PBX Problem

johncaston_2 · ‎10-18-2006

Hi All,

I'm hoping one of you wizards out there might be able to help me with this one.

I've implemented IP trunking for a client so as to allow them to reduce their toll call costs between 3 sites (least cost routing / toll bypass - whatever you want to call it). Each site has a PBX (2x Philips, 1x NEC) with 2x E1 cards, one to the PSTN and one to my Cisco 2800 router. The PBX's have been configured with steering codes (3 digit prefix added to the number dialed). I have successfully got internal extensions working properly, i.e. one site dials the extension of another site and it goes over the WAN to the remote PBX and to the user. The major problem I have is the toll bypass; the number is correctly routed to my router and traverses the WAN and is passed from the remote router to the remote PBX, unfortunately the call doesn't get out to the PSTN - I would say it's not getting an outside line. The PBX's are managed by contracting 3rd parties and they tell me they have checked the configuration and everything looks fine and have spent a bit of time on this and they're running out of ideas. I don't know anything about PBX's (and don't really want to know) but I wouldn't have expected this to be that difficult - isn't this what PBX's are designed to do; route calls?

We're utilising all 30 E1 channels and I've configured the router to source it's clock from the line. Given that internal calls work fine, I'm of the opinion that the issue is with the PBX configuration. Has anyone any idea of where the problem might lie - is there something I can suggest the contractors do or check on the PBX's.

Any feedback would be warmly welcomed, as this is holding up the whole project and I don't know what to do next

Rob Huffman · ‎10-18-2006

Hi John,

I would agree with you in your assessment that this is likely an issue with the PBX config. Most PBX's are set up to block trunk to trunk connections or to block external to external connections. This is what I would confirm with the 3rd parties to start with. After that you will need to try and do some call traces within the PBX's to see what digits etc. are being sent and received.

Hope this helps!

Rob

Please remember to rate helpful posts.....

dweiner · ‎10-18-2006

debug isdn q931 might help diagnose the problem. It should at least tell why the call is being rejected and who is doing the reject. I've seen isdn switch-type mis-matches allow internal, even local calls but not toll free or LD. Also seen where ISDN plan had to be set to private to get calls out to toll free numbers, but that was on a central-office class switch. More than likely though it's a class of service setting in the PBX on the trunk group that doesn't allow off-premise calls.

Tommer Catlin · ‎10-18-2006

check the COS for the user station that is calling. If the user station or DID does not have the highest COS, it probably can not transfer between trunk to trunk.

johncaston_2 · ‎10-25-2006

Thanks very much for your responses. We double checked those items suggested, which were OK.

We confirmed that the trunks were working OK by having one site ring the other, then transferring them to an external party on the other trunk, which worked fine. This confirmed that the trunks were functioning fine, so it has to be how the dial peers are set up on the PBX's

johncaston_2 · ‎11-05-2006

We've found a work-around to this, unsure why but it's definitely something on the PBX's.

We set up one of the extensions on each site to provide the PSTN trunking, i.e. when a user makes a toll call we prepend a 5 digit extension when we pass it through, once it gets to the other PBX it can get an outside line - go figure.

johncaston_2 · ‎12-29-2006

My Bad

Turns out that I was at fault here and the problem was quite straight forward. What I didn't realise was that in a dial-peer, by default, it strips off anything before the "T" i.e. if the destination-pattern is 109T then it removes the 109 before it sends it on. I should have specified "no digit-strip" in the dial-peer to prevent this from happening.

I diagnosed it using the "debug voip vtsp all" command (it took me a while to find the right debug command to use).

It's unfortunate that most PBXs don't show what digits it's receiving, only that a call is incoming.

Humble pie for me

Yum