VoIP Question: Failure to Forward Call Offsite

[Udgnim]

Hi, I'm interning at a small business and I've been asked to look into a call forwarding problem.

I've found this link which looks like it explains the problem, cause, and solution.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080618a74.shtml

Problem

When you make an inside call from an external device to an internal device, the receiving device fails to forward the call to an external device on the CFNA condition. For example, external phone A calls phone 1 in site A and phone 1 in site A fails to forward the call to external phone B.

Cause

This problem occurs when you make an inside call from an external device and the internal device forwards the call to another external device on the CFNA condition by using the original external device number as the calling number. Since this calling number is not part of the subscribed direct inward dial (DID) numbers, the carrier rejects the phone call for the reason of invalid phone number.

The problem is that the T1 is configured for account code based long-distance calling. Since the calling number is not one of the subscribed T1 numbers, it causes billing issues. Therefore, the carrier denies the call.

Solution

Calling Party Selection on a gateway can send directory number information for any outbound call. This field determines which directory number is sent. When a problem happens, this parameter is set as Originator. The original calling phone number (external phone number) is used as the calling directory number. Since it is not part of the subscribed DID numbers, the carrier denies the call for the reason of invalid phone number.

Set Calling Party Selection as First Redirect Number for the gateway in order to solve the issue. This causes the gateway to use the DID phone number (internal device number) on the CFNA condition as the calling phone number. This phone number falls into the range of the subscribed phone numbers. The carrier forwards the call to the recipient.

So my questions, is this the right track?

The Cisco hardware is UC520. The GUI management that I've been looking at is Cisco Unified Communications Manager Express. The link is for Cisco Unified Communications Manager (CallManager) though, and I haven't found anything similar to the link's solution steps in Unified CME.

Is this something that can be configured to work properly through Unified CME or do I need to use Cisco IOS commands or a different Cisco GUI management?

Is this the right track to solving the problem? Should I just find out who our provider is and call them for support?

Thanks for the help.

 

[imagoon]

You would need to pull the logs from the PBX first. See why the call was denied. If it is truly occurring because you are forwarding out improper DID data then substituting out your internal DID in place would work.

I would call your provider they are going to know better than anyone. There are differing rules along with differing settings for the PRIs depending on your plan or region. For call forwarding in our systems we had a rule set where we could send any CID data so we could send the caller ID data but still make a successful outbound call.

 

[Specop 007]

Could be, if the redirect header isnt getting set and your provider is doing any type of call screening that could definitely cause a problem. I dont know the specifics on the Cisco gear. If you can contact your provider I would start there as it should be an easily answered question for them.

Not only that but if they are doing call screening so that if the call appears to originate offnet you could bring this up to your boss as an enhancement/problem if you could get your provider to not screen. This would allow the external device B to see the original calling number as opposed to seeing the redirecting number internal phone 1. Some people like to see the call come from their desk phone, some like to see the original calling number. User preference.

But it sounds like you are not on the wrong track. I've also seen where the redirect header actually gets tripped by the carrier which plays hell on voicemail systems but that doesnt sound like your problem at all.

 

[jlazzaro]

if you try to send a call out with a number not assigned to you, most carriers will overwrite it with your BTN. definitely pull logs and verify the behavior...you should be able to do head-to-head testing with the carrier and get to the bottom of it.

as a work around, try assigning an outgoing, calling translation pattern to your POTS dial-peer to translate non-standard caller ID numbers into your DID range. you could also trying applying "clid override rdnis" to your dial-peer, which in theory should overwrite the caller ID with the redirected dial number.

 

[Udgnim]

found out the original number used to forward the call was incorrect and a 91 should have been added in front of the number. someone else inputted the first number, and I assumed it was inputted correctly.

hooray for taking so long to solve a simple mistake. at least I've been exposed to a lot of stuff though which may or may not become useful because I've also been asked to create a phone map.