Outgoing Calls ringing to Internal Extensions...

[eloybonuz]

                   Hi,

We just moved a location from a PRI to a SIPTrunk. After correcting a few routing issues, another issue popped up. When a caller is dialing an outgoing number (XXX-XXX-6560), the call is going to an internal office extension 6560, as opposed to dialing out. This is happening when the last four digits match. It is not consistent. Some times it will work correctly, other times, it will ring to internal number.

I'm suspecting it's still a routing issue. Would appreciate some insight from the pros!

Eloy

[testeven]

Hi Eloy,

I will recommend you to get a CUCM detailed trace file and see why the call is matching the internal DN. It's hard to tell  why this does not work properly, probably a TP or Route Pattern is misconfigured.

Regards, 

Tere. 

If you find this post helpful, please rate! :)

[eloybonuz]

Good, I didn't think of that. I'll give it a shot and see what I get. Thanks for the post!

Eloy

[islam.kamal]

This configuration CME based or UCM , please also share the route pattern or dial-peer for the outgoing call , if you have translation rules

[eloybonuz]

Thanks for your post. We're running CUCM 7.1. The particular

The number being dialed is 9-832-877-6526 and the particular pattern for this is 9.832XXXXXXX. Well, I think I found the problem, when looking up this pattern, I noticed it was included. I just have a wildcard pattern: 9.XXXXXXXXXX.

I'm going to include this pattern and see if it take care of the issue. Thanks so much for your help!

[PatrickReady]

Do you happen to have a DNIS setting (From when the server was used for PRI) that is stripping off the first x number of digits for the last 4? What if you changed this to 10? 

Can you make outbound calls at all? Might be able to work with your SIP trunk provider to ask them if they see any traffic come out of the PBX when you do attempt to make these outbound calls. They should be able to capture the calls/packets and tell you what number is coming out on their end. 

[eloybonuz]

Hi there Patrick! Great suggestion... Checking with AT&T on this now. Verifying the DNIS. It should be 10, but something has to be stripping off those first 6 digits. Thanks for your post!

[Ayodeji Okanlawon]

Your best way to troubleshoot this is to look at the traces. You need to see how the call is routed, otherwise it will be like groping in the dark. What is your call flow. Do you have a direct integration to your sip provider or do you have a CUBE in the middle.If you have CUBE then send debug ccsip messages for a failed call. If you dont send cucm traces..make sure you have enabled detailed traces..Include calling and called number..

It is also possible that the call maybe matching a translation pattern configured to route calls made by users using the full DDI of a user to get routed back to internal number

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"