cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2968
Views
17
Helpful
28
Replies

Transferring Calls to Prompt Recording Application

Matthew Martin
Level 5
Level 5

Hello All,

First, so we have what we call our "Employee Access Line" which gives the ability to our employees to be able to call an internal extension from outside the building by calling into a DID number. This Emp Access Line has a System Call Handler in Unity, and a DN (*1898 in DID) and a CTI Route Point in CUCM.

Secondly, we have what is called the "Prompt Recording Application". This has a Directory Number (*1610 in internal) and a CTI Route Point. That DN is also associated to a System Call Handler in Unity as well, but I'm not too clear on why that has a System Call Handler anyway... When you call this extension you are taken to a Call Script in UCCX for changing Prompt messages for UCCX CSQs.

But, what I was trying to do was to allow someone to call into this Employee Access Line from outside the building and be able to dial the 1610 extension to reach the Prompt Recording Application to change prompts and the like... I had opened a TAC Case with the CUCM team, and we were able to finagle the Emp Access Line to automatically forward a call to this Prompt Recording Application. But the problem with that was, that the caller no longer had the ability to choose which extension they wanted to call, so we ended up having to change it back. So I had asked if he thought it was possible to issue a workaround by creating a new extension and have that new extension forward you to the Prompt Recording Application (*DN: 1610). He said that this was probably possible but I would need to open a new case with the Unity team, which I will do if we can't figure this out in here first. He had said that it wouldn't work the way we were trying because one device/DN can olny be associated with one Cisco Application (*i.e. either UCCX or Unity, but NOT both).

So I created a NEW Directory Number (*and a new  CTI Route Point) and set it up the same way as when we had the Emp Access Line automatically forwarding to the 1610 extension. But when I call into the Employee Access Line from outside or inside the building and then dial the new DN I created (*DN 1612) I get a Cisco recording that says:

"You cannot be transferred to this number, check the number and try again."

So I googled the recording I heard above and found that this recording has to do with the Restriction Table in Cisco Unity...? Does that sound right?

So I looked at all the Restriction Tables in Cisco Unity and I didn't find anything that would be blocking this number, so I added the 1612 extension in there directly as the first rule in all the tables and made sure the "Blocked" checkbox was NOT checked... But I am still hearing that message above.

If you need them, I can get more specific with the Partitions and CSS's  for each of those DNs and Devices that I mentioned above.

If anyone has any thoughts or suggestions, please feel free. It would be much apprectiated!

***EDIT***

Forgot to add one other thing... The 1610 Extension, which is the number I want to get transferred to, is also a Unified CM Telephony Trigger: 1610

Thanks in Advance,

Matt

28 Replies 28

Rob Huffman
Hall of Fame
Hall of Fame

Hi Matt,

I hate to jump in when you have such great help from Gareth & Carlo (+5 each!) so

I'll just add a couple of notes here.

It seems that one of the roadblocks here is the Call Handler @ 1610. I think you hear

the "new" greeting due to the greeting being enabled and set with no recording. This same

"active" greeting probably has the after greeting action set to take message.

If it were me, I would try to change the extension on this Call Handler to a new number

to remove the 1610 reference and then try the call again while collecting the rPSM info

Cheers!

Rob

"May your heart always be joyful
And may your song always be sung
May you stay forever young " 

- Dylan

Hey Rob, thanks for the reply!

Ok, so I should just change the extension of the System Call Handler with ext 1610, but leave the UCCX Trigger and CTI Route Point and DN the same...? If so, good idea, take the Call Handler out of the equation completely..!! I'll give that a shot and post back.

Thanks again for the reply, much appreciated!

Thanks,

Matt

Hey Rob,

Ok, so I changed the extension of the System Call Handler from 1610 to a extension that's not used currently, 1613...

Now, when I call the 1898 Emp Access Line I hear the same message I heard when I created the 1612 DN and CTI Route Point which was supposed to just forward all to 1610. The message I hear is:

You cannot be transfered to this number, check the number and try again.

When I heard this message the 1st time when dialing the extension 1612, I found by googling the message I heard, that this comes from the Restriction Table in Unity... Is that what that message comes from?

Here is the output from the rPSM:

CallData, 40, CallerId=xxxxxxxxxx, CalledId=1898, RedirectingId=1898, Origin=16, Reason=8, CallGuid=0D274C6A518545FEADA3AD0282126F58, CallerName=WIRELESS CALLER, LastRedirectingId=1898, LastRedirectingReason=8, PortDisplayName=CUCM-1-003

AttemptForward

State - AttemptForward.cde!Dummy

Event is [NULL]

PHTransfer

State - PHTransfer.cde!LoadInfo

Event is [TrueEvent]

PHGreeting

State - PHGreeting.cde!PlayGreeting

Call answered if needed

Playing greeting for Call Handler:  Opening Greeting - Employee Access Line

DTMF received [1]

DTMF added [610]

Event is [FalseEvent]

State - PHGreeting.cde!PlayGreetingLoop

Event is [FalseEvent]

State - PHGreeting.cde!PlayGreeting

Call answered if needed

Playing greeting for Call Handler:  Opening Greeting - Employee Access Line

Event is [HangupEvent]

State - PHGreeting.cde!DoHangup

Event is [HangupEvent]

Idle

I guess if I can figure out why I'm getting that "You cannot be transferred to this number..." message I might be able to get this working, or even get my previous workaround working (DN and CTI RP 1612), which forwarded me to 1610, because it was the same message...

EDIT: Just noticed something while changing settings for 1898 Call Handler...

Not sure if this helps at all, but I was going through each Greeting in the 1898 Call Handler and either checking (*if not already checked) or unchecking the option "Allow Transfers to Numbers Not Associated with Users or Call Handlers" and then calling after each change to see if that changed anything at all. And when I unchecked this option in the Standard greeting and I called into the Call Handler, I heard a different message this time... I heard:

"I did not recognize that as a valid entry."

Thanks Again,

Matt

Hi Matt,

Did you change this on the "Default System transfer" restriction table to something like

16?? - allow

I get the message

"You cannot be transfered to this number, check the number and try again"

when trying to dial a number not associated to a user/mailbox & not added to the restriction table

las isted above.

Cheers!

Rob

"May your heart always be joyful
And may your song always be sung
May you stay forever young " 

- Dylan

Hey Rob, thanks for the reply!

Nope, when I edited the restriction table I just added "1610" as the pattern... I'll try adding the "16??" and see if that helps.

Thanks Again,

Matt

Hey Rob, sorry for adding soo many replies, I just wanted to make sure I got that info out before I forgot to add it in...

Ok, so I added "16??" to the Restriction Table, and now when I call there is a delay of about 15 seconds or so, then I hear that message again:

"You cannot be transferred to this number, check the number and try again."

Would it change anything by adding that 16?? pattern to each of the Restriction Tables..?

Thanks Again,

Matt

Hi Matt,

No worries

In my tests here it needs to be the "Default System transfer" restriction table.

Cheers!

Rob

"May your heart always be joyful
And may your song always be sung
May you stay forever young " 

- Dylan

I just came across this info below, at this link --> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/8x/administration/guide/8xcucsagx/8xcucsag060.html

This is for the Greetings available in the System Call Handler (*i.e. Error, Internal, Standard, Holiday, etc...)

          *The one below was taken directly from the Error Greeting section of the table at that link above...

Error

Plays if the caller enters invalid digits. This can happen if the digits do not match an

extension, the extension is not found in the search  scope, or the caller is otherwise

restricted from dialing the digits.  You cannot disable the error greeting.

The system default error recording is, "I did not recognize that as a valid entry." By default,

after the error greeting plays, Connection replays the greeting that was playing when the

caller entered the invalid digits.

According to this, my situation falls into one of these 3 categories.

          1. The digits do not match an extension.

          2. The extension is not found in the search scope.

          3. Or the caller is restricted from dialing the digits

I guess I just now have to figure out which one of these this falls into... I guess we could rule out the "digits do not match an extension", because the 1610 extension does exist but is NOT currently associated to anything in Unity (*i.e. a User or Call Handler). But I assume this shouldn't matter since I have the "" checkbox checked...?

Thanks,

Matt

Matthew Martin
Level 5
Level 5

Hello All,

Finally got it working!

So I had a case open with TAC's Unity team, and we checked everything in Unity and all seemed to be correct, including Restriction Table, etc...

So we collected logs from Unity, which basically said the call was being Rejected. So we collected logs from the CallManager and after my Unity Tech had a CallManager person check out the logs he came to the conclusion that it was a CSS issue.

In order to fix the issue (*it always seems to be something so simple that gets over-looked) we had to add our UCCX-Ports Partition, to our Unity-Inbound-CSS Calling Search Space... And now its working!

Thanks to everybody who posted, muich appreciated!

Thanks Again,

Matt

Casey Arnold
Level 1
Level 1

Hello Matthew,

I know that this thread is almost two years old, but I find myself in a new position and have a great need to have a UCCX script that will allow my Customer Service Manager to dial in and change a prompt associated with their CSQ's script.   Is there any way that you could share a copy of just your UCCX Prompt Recording script.  I know that a former employer had this setup where the Manager called in and gave a PIN and then the Prompt # he wanted to change, but for the life of me, I cannot seem to setup a script with that capability.  Everything I read tells me that I need to have a ccmUser Authentication to allow the new prompt to be saved on the UCCX server.  Any advice or help you could provide would be greatly appreciated. 

Thanks,

Casey

Hey Casey

Sure, no problem. I have attached the script in a zip file to this post...

As for the User Auth you mentioned. In the script you'll see a variable called username, this is where you set you UCCX Admin username. Then, there is another variable called password, this is where you put the UCCX Admin's password. I changed the values of these vars to descriptions of what they are, so you should be able to see what I'm talking about.

Those username and password variables in the script will be what allows your Manager, or whomever logs in to modify prompts, the ability to actually write the prompt to UCCX.

Lastly, you'll see a variable called pin, whatever you set as the value for this variable, that will be what needs to be entered once you dial the Application's trigger that you assign the script to... Does that make sense?

Also, it's already set this way in the script, but you should keep the parameter attribute of the "pin" variable. This way if you ever want or need to modify the PIN you can do so from the Application's page in UCCX.

Hope that helps!!

Thanks,
Matt

Matt,

You are my new BEST friend.  :)   I can't thank you enough.  Hopefully I will have time tomorrow to actually get to play with it.  Thank you again!

Casey

No problem, happy to help!

-Matt

Information had been provided in the below post:

https://supportforums.cisco.com/discussion/12755736/uccx-110-prompt-recording-script

Regards

Deepak