Using Unity 4.0(2) with CCM 3.3.3 I have created a call handler with extension 03690 and also configured 03690 on CCM to forward all to VM. This handler then does a transfer to a subscriber 03222. This subscriber is configured to attempt a transfer to the subscribers phone, do a supervised transfer and to ask the caller what to do on busy. When the subscriber is on the phone the user is prompted to press 1 to hold 2 to leave a message and 3 to try another extension. Unity then makes 5 attempts at 12 second intervals (I changed the defualt here) to ring the subscriber before repeating the options to hold, message or dial another user. While the caller is on hold there is dead silence until the timer triggers to attempt the transfer again, at which point roughly 1 second of CCMs MOH is heard. If the subscriber is still on thier phone the call returns to silence until the next transfer attempt. Now when a second caller comes in and is presented with the options to hold message or try another station if they pick hold the do hear MOH, which is being provided by Unity from the files labeled PHHOLDMUSIC000.wav - PHHOLDMUSIC009.wav All callers other than the first caller in the queue hear these MOH files.
I have searched CCO and can't find anything indicating that caller 1 in the queue should be receiving either different wav files on hold or any MOH for that matter other than that provided by the switch (CCM) during the transfer attempt. Am I missing something, is this a bug, or was the system actually designed to function this way?
the dial attempts required, of course, that we put the caller on soft hold and dial the extension - we do this frequently for the first person in line such that the target doesn't have time to hang up and dash out of their office without getting the incoming call - you have to walk a fine line here.
With such short breaks between attempts we'd have to chop up some brief snipets of hold music that we play in between transfer attempts which is awkward at best (and limits your ability to be able to customize the attempts/delay as you have).
So, I will assume then that there is no method of providing MOH while on this soft hold? The example here is in a retail pharmacy environment and those being placed in the queue are going to be Doctors wishing to speak with the pharmacist. In this example hopefully our pharmacists are not gonig to dash out the door, or we are going to have a much larger problem on our hands 8-) There are however going to be frequent times where these doctors are going to be in the queue for several minutes. Don't ask me why but for some reason Doctors just don't want to leave a mesage that can be addressed with a return call. I have tried shortening the time between transfer attempts wich resulted in the sittuation you describe, MOH (from CCM) being notiably choppy. I have also gone the other route which yield extended periods of silence which results in the MDs thinking that they have been cut off, calling back and now being PO'd Is there any other solution that you can think off that would allow them to wait in a queue but still provide some sort of MOH to all callers rather than just the second caller on?
No, there currently isn't any way to do this. The only way I can think of doing this would be for us to have a 2nd set of MOH prompts that are shorter than the ones heard further up the queue and play those between transfer attempts - I'm not sure right off hand how much work that'd be. The best I can suggest is to ask your account team to put a PERS request in so the product folks knwo it's something folks in the field want and can prioritize it accordingly. Possibly hook this up with changes to the logic for keeping folks in the queue by requiring them to press "1" repeatedly which some folks find annoying (it's designed this way to avoicd problems with switches that don't provide positive disconnect to keep ports from being "burned" among other resons). Making that configurable would make some folks happy.
Ok, thanks for the quick and through responses. I'll get in touch with my account team and have them pass along the suggestion. Yea not having to press 1 to stay on hold wouild be a welcome change but I can see the reasoning for requiring it. Maybe there could be an option that wouldn't even need to be configurable that would no longer require the caller to press 1 to remain on hold whenever the switch is CCM. I have a couple ideas how this could work but I'll pass them along through my request to my account team. Thanks again for the quick replies.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...