cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3528
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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

28 Replies 28

garethpeart
Level 3
Level 3

Matthew,

From the sound of it, you just want someone to be able to call in and change the recording of the call handler. Is this correct? If so, you just need to set up a greetings admin for that handler. That admin would have to be a mailbox user with either the greetings admin role, or assigned as owner to the call handler.

Let me know if i'm on the right track!

Gareth

Hey Gareth, thanks for the reply, much appreciated!

The recordings that change are for UCCX not Unity Call Handler Greetings. When you call the extension 1610, which is the extension I would like to be able to reach from outside the building, you are taken through a UCCX Call Script which allows you to change the Prompts you would hear when you call into our 800 number for example.

The recordings that are actually being changed are the ones you would see in UCCX > Prompt Management...

So you would call that extension internally (i.e. 1610) and you would be prompted for a PIN number. After entering your PIN it asks you if you would like to record or play a prompt by selecting either 1(record) or 2(play), then you are asked to enter the 4-digit number of the prompt you wish to play and/or record... Does that make sense?

Thanks Again,

Matt

Matthew,

Sorry for missing the UCCX piece!

It does make sense... unfortunately my UCCX knowledge is pretty limited at this time, so hopefully someone else can come through for you. You might want to port this over to the UC applications forum tho.. that'll get you to the people that can really help.

Gareth

No problem, thanks anyways...

Ok, will do. I'll move the discussion over to that forum... Thanks!

Thanks Again,

Matt

Hi Matthew.

What the UCCX script does when you call it from an internal extension using 1610 DN.

If you can, please upload the script so we can analyze it together

Let me know

Regards

Carlo

Please rate all helpful posts

"The more you help the more you learn"

Please rate all helpful posts "The more you help the more you learn"

Hey Carlo, thanks for the reply!

Sure I can do that, but I don't see an option to upload anything other then a Picture and/or a Video... How do I upload that?

When you call 1610 internally and reach the UCCX Script you hear:

"Welcome to the Prompt Recording Application, please enter your PIN Number now."

       ---After entering PIN---

"To record a prompt Please press 1, to play a prompt please press 2"

      ---Then you enter the 4-digit Filename of the Prompt---

So this "menu" allows you to play and/or record prompts from UCCX's Prompt Management page. I thought it was a standard/default UCCX Application/Script that comes with the system, but I wasn't with the Co. when this system was put in place, so I'm not positive about that.

Thanks,

Matt

Hi Matt.

Use advanced editor and you'll find upload file button

Cheers

Carlo

Please rate all helpful posts

"The more you help the more you learn"

Please rate all helpful posts "The more you help the more you learn"

Ohh there it is below the textbox by the Post Message button... Thanks, don't know how I missed that.

-Matt

Matthew,

I checked your script and what I can see is that you can call it directly from the outside without passing through UC.

Any reason to force the call to take that path?

Let me know

Regards

Carlo

Please rate all helpful posts

"The more you help the more you learn"

Please rate all helpful posts "The more you help the more you learn"

Well, it doesn't have a DID (i.e. an external number) associated to that DN, 1610. That DN is only an internal extension.

I didn't create this setup, so I myself am trying to understand how it works. The DN 1610 which is the number to reach that script, has the following things associated to that Directory Number:

  1. Directory Number = 1610 (CallManager)
  2. CTI Route Point (CallManager)
  3. Cisco Unified Telephony Trigger (UCCX)
  4. System Call Handler (Unity) -> *Not sure why it is associated to a call handler..?

So when I call 1610 from an internal number I am taken directly to that UCCX Script/App. But when I call that extension from our Employee Access Line (*DID DN=1898) which is a System Call Handler that allows people to call internal extensions from its DID Number.

So lets say I call the DID number from my cell phone and I dial xxx-xxx-1898. I reach the Emp Access Line, which then prompts me to enter an extension. I enter the extension 1610, then there is about a 10-15 second delay and I hear:

"Sorry ManualDownMessage is not available."

The "ManualDownMessage" is the name of the System Call Handler I mentioned in that list above of things associated to that 1610 DN.

When I had the TAC case open we were able to modify the 1898 DID DN's config so we were able to reach 1610. We changed the DID number's CSS from to our UCCX-Inbound-CSS, then we unchecked the Forward All's "Voicemail" checkbox and added the extension 1610 instead and changed the CSS for that Forward All to UCCX-Inbound-CSS. And after we did this we were automatically forwarded to the 1610 extension and I was able to reach the UCCX Script by calling xxx-xxx-1898. But we could not keep it this way since people use this to reach other employees as well.

EDIT: We also added the DID Partition to the UCCX-Inbound-CSS.

So what I thought I could do was create a new Directory Number and a new CTI Route Point, and configure it the same way we configured the 1898 DN and CTI Route Point and just have this new extension forward me to 1610 in the same way 1898 did when we had it automatically forwarding you to 1610. The new extension I created is 1612. But when you call xxx-xxx-1898 and enter 1612 you hear:

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

And when I googled that I saw lots of people saying that message was due to the Restriction Table in Unity. So I checked the Restriction Table and there was nothing in there that I could see that would prevent me from dialing 1612 as a extension to reach. So I added 1612 to the Table anyway and made sure the Blocked checkbox was NOT checked, and still no luck...

One last thing I tried was adding a NEW "Caller Input" section the the System Call Handler of the 1898/Emp Access Line, and I set that up to have,

  • Action = "Transfer to Alternate Contact Number "
    • Extension = "1610"
    • Transfer Type = "Release to Switch"

And when I call the xxx-xxx-1898 DID number and press number 8 for the caller input, I hear:

"Wait while I transfer your call..."
--- Then after about 10-15 seconds, I hear ---
"Sorry this number did not answer."

Thanks again for the reply Carlo, much appreciated!

Thanks,

Matt

Hi Matthew.
Dialing Employee access line, are you able to dial an internal extension?
I replicated your setup in my lab and what gave me that message was an incorrect css configured on unity connection.
Please double check that setting on your UCNX and let me know.
Also download a useful tool Port Status Monitor Tool from the link below, run it and make a call to Employee Access Line selecting application DN 1610 and post the output from that tool
http://www.ciscounitytools.com/Applications/CxN/PortStatusMonitorCUC7x/PortStatusMonitorCUC7x.html



Let me know.

Cheers

Carlo

Sent from Cisco Technical Support iPhone App

Please rate all helpful posts "The more you help the more you learn"

Hey Carlo,

Yes, we can dial internal extensions from the Employee Access Line. It works both from calling the full DID number, xxx-xxx-1898 externally, and also dialing internally to 1898.

Something I noticed while calling 1898 internally. When I dial 1898 and then hit dial on my phone, the number I'm calling immediatley changes to 6000, which is our voice mail pilot. So I'm assuming it worked when TAC and I made those changes for it to NOT forward to Voicemail and instead Forward to 1610, because the call never reached the Call Handler itself, it actually just did a direct transfer to another extension within CallManager... Does that sound right?

Also, where in Unity is the CSS configured? Is that in the System Call Handler for the Emp Access Line somewhere? I'll look around for it and let you know if I find it before you respond.

Thanks AGAIN, for the reply!

Thanks,

Matt

Hi Matthew.
You can check voice mail port and voicemail pilot CSS on CUCM
Run also suggested tool and please post the output.

Thanks

Regards

Carlo

Sent from Cisco Technical Support iPhone App

Please rate all helpful posts "The more you help the more you learn"

Carlo,

Voicemail Pilot CSS = Internal-Only-CSS

Voicemail Port CSS = Unity-Inbound-CSS

Here is the output from the rPSM:

     *This is me calling into the 1898 DID Number from my cell phone.

------------------------------------------------------------

04:31:56, New Call, CalledId=1898,  RedirectingId=1898,  Origin=16,  Reason=8,  CallGuid=4C4B22B0890A417E9A6CB9C3CB9309D1,  CallerName=WIRELESS CALLER,  LastRedirectingId=1898,  LastRedirectingReason=8,  PortDisplayName=CUCM-1-003,[Origin=Unknown],[Reason=Forward Unconditional]

04:31:56, AttemptForward

04:31:56, State - AttemptForward.cde!Dummy

04:31:56, Event is [NULL]

04:31:56, PHTransfer

04:31:56, State - PHTransfer.cde!LoadInfo

04:31:56, Event is [TrueEvent]

04:31:56, PHGreeting

04:31:56, State - PHGreeting.cde!PlayGreeting

04:31:56, Call answered if needed

04:31:56, Playing greeting for Call Handler:  Opening Greeting - Employee Access Line

04:32:03, DTMF received [1]

04:32:05, DTMF added [610]

04:32:06, Event is [NULL]

04:32:06, PHTransfer

04:32:06, State - PHTransfer.cde!LoadInfo

04:32:06, Answer Phone if needed

04:32:06, Event is [FalseEvent]

04:32:06, State - PHTransfer.cde!CheckPlayTransferIntro

04:32:06, Event is [FalseEvent]

04:32:06, State - PHTransfer.cde!XferCall

04:32:16, Event is [TransferFailed]

04:32:16, State - PHTransfer.cde!LeaveMsg

04:32:16, Event is [NULL]

04:32:16, PHGreeting

04:32:16, State - PHGreeting.cde!PlayGreeting

04:32:16, Call answered if needed

04:32:16, Playing greeting for Call Handler:  ManualDownMessage

04:32:22, Event is [HangupEvent]

04:32:22, State - PHGreeting.cde!DoHangup

04:32:22, Event is [HangupEvent]

04:32:22, Idle

------------------------------------------------------------

I had gone through all the Greetings in the Greetings section of the System Call Handler and I had checked the checkbox labeled " for ALL of the Greetings listed there, whether they were enabled or NOT. The only one that had this checkbox checked was the Standard Greeting, and the only 2 Greetings that are "enabled" are the Standard and Error greetings... I don't know if those changes I did caused this, but now when I call the 1610 extension from the Emp Access Line I hear the message: "Sorry extension 1610 is not available, record your messgae at the tone....etc...".

I dont know how/why it switched to saying that now, when it was saying this earlier today; "Sorry, ManualDownMessage is not available"...?

Thanks Again,

Matt