Call forwarding issue

Answered Question
May 9th, 2012

We have a client running CUCM 7.1.3, and they are reporting the following situation:

when the receptionist receives an external call and tranfer it to an internal DN,  final destination user receives the call identified by receptionist's DN, instead of external phone number !

They have told us that before answering the forwarded call they see receptionist's DN, but when they answer it this number change to original caller's external phone number.

On receptionist DN, we have mark "Redirect Number" on "Forwarded Call Information Display" section

Could you please tell me what can be missing on this CUCM configuration??

Thank you in advanced.

Enrique Villasana

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Rob Huffman Wed, 05/09/2012 - 08:43

Hi Enrique,

You need to get the receptionist to do one of two things to make this

a "blind" transfer. Either;

receive call > press Transfer > Dial DN of transferee > Press Transfer again immediately

or set up and use;

Onhook Call Transfer

Modifications to the Call Transfer feature add the onhook (hangup) action as a possible last step to complete a call transfer. The Transfer On-hook Enabled service parameter, which enables onhook call transfer, must be set to True for onhook call transfer to succeed. If the service parameter is set to False, the onhook action ends the secondary call to the third party.

In the existing implementation, if user B has an active call on a particular line (from user A) and user B has not reached the maximum number of calls on this line, the Cisco IP Phone provides a Transfer softkey to user B. If user B presses the Transfer softkey (or Transfer button, if available) once, user B receives dial tone and can make a secondary call: user B dials the number of a third party (user C). Cisco CallManager provides a Transfer softkey to user B again. If user B presses the Transfer softkey again (or Transfer button, if available), the transfer operation completes.

With the new onhook call transfer implementation, user B can hang up after dialing user C's number, and the transfer completes. Both the existing and new implementations work in both the case of a blind transfer (user B disconnects before user C answers) and also in the case of a consult transfer (user B waits for user C to answer and announces the call from user A).

The previous implementation remains unchanged: user B can press the Transfer softkey twice to complete the transfer.

As for the "Redirect Number" on "Forwarded Call Information Display" section

Those settings are very confusing, but what they really refer to is what

is shown on your phone if a call is forwarded to it not what is sent on a forward

to someone else

Here is an excerpt from Cisco Press

Configurable Display of Forwarded Call Information

You can specify, on a per-line basis, the types of information that users see when calls are forwarded to their stations. Each line on a station can display different forwarded call information based on the settings configured in the Forwarded Call Information Display area on the Directory Number Configuration page in CallManager Administration (Device > Phone > find and select a phone > click a line number).

To better understand the display capabilities that can be configured for each line on a station, the following explanations help to clarify some common terms.

###Each line on your station that can be used for calls has an associated directory number. If you originate a call, the line that you use to place the call, for display purposes, is referred to as the calling line ID (CLID) or simply calling party number. There is also a display name associated with that line on your station, and it is referred to as the calling name ID (CNID) or simply the calling party name.

When you make a call by dialing the directory number of the person you want to reach, the number that you dial is referred to as the original dialed number (ODN). Because calls might be forwarded one or more times, the original dialed number might not be the actual number of the line that is answered when the call is completed. The final directory number used to extend the call when the call is actually completed is referred to as the redirected dialed number (RDN).

The following check boxes are provided on the Directory Number Configuration page in CallManager Administration. All can be enabled or disabled by selecting/deselecting the check box. These check boxes control the display of information for calls that have been forwarded to the phone. By default, for forwarded calls that arrive at your phone, you will see the original dialed number and the calling party name.

    *Caller name (also known as calling name ID [CNID])— Enabled by default
    *Caller number (also known as calling line ID [CLID])— Disabled by default
    *Redirected number (also known as redirected dialed number [RDN])— Disabled by default
    *Dialed number (also known as original dialed number [ODN])— Enabled by default

Consider the following example: A call arrives at John's station on the line associated with directory number 4444. Delon Whetten originated the call on line 1111, and called Anne Smith at 2222. Anne had forwarded 2222 to Chris Pearce at 3333. Chris had forwarded 3333 to you at 4444. In this example, the calling party name is Delon, and the calling party number is 1111. The original dialed number is 2222. The redirected dialed number is 3333. When the phone arrives at John's station, the information that displays depends on the display options that you configured for John's station.

Cheers!

Rob

"Everything is broken" - Bob Dylan

Jaime Valencia Wed, 05/09/2012 - 08:44

So, what are you doing????

Call forward??? CFA? CFNA?? CFB??

Or call transfer???

Different features and different behaviors, yet you mention both.

"when the receptionist receives an external call and tranfer it to an  internal DN"

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

ev1205 Wed, 05/09/2012 - 09:26

Thanks everyone,

Something important about this case, client (the receptionist) is not using a simple Ip phone, she is using Attendant Console , and this issue is about transfered calls.

She told me that she answer external call, verify destination user, and trasnfer the calll from her Attendant Console station.

I hope this can help.

Thanks

Enrique

Jaime Valencia Wed, 05/09/2012 - 09:29

OK, so transfers.

Blind or supervised??

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

Rob Huffman Wed, 05/09/2012 - 10:03

Hi Enrique,

The receptionist would have to do a "Direct" or "Blind" transfer for the

user to be able to see the actual calling number before answering but it sounds

like they want to verify that the user is there/available before transferring the caller.

"She told me that she answer external call, verify destination user, and trasnfer the calll from her Attendant Console station."

In a "Consult" transfer where the receptionist wants to consult/verify the user before transfer is completed

there is no way to change the call display behavior

Cheers!

Rob

"Everything is broken" - Bob Dylan

ev1205 Thu, 05/10/2012 - 11:36

Hi everyone, our Attendant Console 8.0 client was most specific about process she follows:

a) Receive external call,

b) Answer it

c) Browse destination DN

d) Double-click this destination DN, (and call is transferred)

Here i understand that "double-click" destination DN mplies a "Bliind trasnfer" and this transferred call should be indentified by external Caller Number, at our client's case destination user sees "CTI port DN", instead of external number.

I have read the following procedure as a "solution" for this issue:

At Attendant Console work station...

1) Close down the CUEAC Console

2) Open regedit

3) Browse to HKEY_LOCAL_MACHINE>Software>Arc Solutions>CallConnect>Operator>Defaults>Direct transfers

4) Set this to ALL

5) Close the registry editor and try again.

what do you think??

and thanks again for your help

Enrique

ev1205 Mon, 05/14/2012 - 13:25

Rob, i have just completed this change, and the problem was solved

Actions

Login or Register to take actions

This Discussion

Posted May 9, 2012 at 8:21 AM
Stats:
Replies:9 Avg. Rating:5
Views:965 Votes:0
Shares:0

Related Content

Discussions Leaderboard