[cisco-voip] UCCX Hold Music

Wed Apr 7 15:19:14 EDT 2021

Barge in vs interruptible

One disables keypad entries :)

On Wed, Apr 7, 2021 at 11:54 AM Matthew Loraditch <
MLoraditch at heliontechnologies.com> wrote:

> That wouldn’t matter in this scenario but appreciate the info!
>
>
>
> Matthew Loraditch
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* DJ Lundberg <dj at netguys.net>
> *Sent:* Wednesday, April 7, 2021 2:48 PM
> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>; Brian V <
> bvanbens at gmail.com>
> *Cc:* cisco-voip at puck.nether.net; DJ Lundberg <dj at netguys.net>
> *Subject:* RE: [cisco-voip] UCCX Hold Music
>
>
>
> [EXTERNAL]
>
>
>
> One word of caution using a play prompt step for the hold music:  This
> allows the caller to press the # key and skip the remaining portion of the
> prompt.
>
>
>
> It’s not a huge deal, but something to be aware of if you previously would
> have used the delay step to control how long the caller is waiting before
> offering them an alternative to holding.  E.g. leave a voicemail, receive a
> callback, etc.
>
>
>
> You might get some supervisors asking why a caller was only in queue for 2
> minutes before transferring to voicemail when they are expected to hold for
> 5.
>
>
>
> DJ
>
>
>
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> *On Behalf Of *Matthew
> Loraditch
> *Sent:* Monday, April 5, 2021 2:31 PM
> *To:* Brian V <bvanbens at gmail.com>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] UCCX Hold Music
>
>
>
> Didn’t think about that, so I could just play the new MOH as a prompt, As
> long as it’s interruptible the call will still transfer to the agent while
> playing if one becomes available?
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Brian V <bvanbens at gmail.com>
> *Sent:* Monday, April 5, 2021 3:25 PM
> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] UCCX Hold Music
>
>
>
> [EXTERNAL]
>
>
>
> Depends if you want your MoH to come from putting the call on hold (script
> step Call Hold) or via Play Prompt
>
> with the Call Hold Step, the internal leg is actually torn down from UCCX
> and moved to CUCM's media streaming service.   MoH comes from the CTI ports
> and you'd need different port groups per app to get different messaging .
>
>
>
> The other option is in the script, use the* Play Prompt* step to play the
> messaging from UCCX.  In this case the call is never put on Hold from a
> CUCM point of view and the media stays with UCCX.  I think the step you can
> look at is a *Cascading Promp*t (someone jump in if I have this wrong)
> and in that step  you can provide various static wav files and it will
> stitch them together for you in a linear or random fashion.  One of the
> main drawbacks of this method is your "hold time" between announcements is
> determined by the length of your .wav file.  Make sure you set the play
> prompt to be "interruptible" so the first available avent pulls the call.
>
>
>
> On Mon, Apr 5, 2021 at 2:19 PM Matthew Loraditch <
> MLoraditch at heliontechnologies.com> wrote:
>
> Am I thinking about this right?
>
>
>
> MOH for UCCX comes from the CTI ports.
>
>
>
> If a customer wants different MOH per different queues they will need
> separate CCGs for each queue?
>
>
>
> If I do it that way I have to capacity plan per queue vs overall system or
> application capacity?
>
>
>
> For an agent based install, can I mix and match IVR port licenses? I don’t
> believe so, and certainly not on a smart install on flex based on what I
> can see.
>
>
>
> They have intermittent announcements right now, which is what I usually do
> for folks, I’m thinking this would be a nightmare.
>
>
>
>
>
>
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image310843.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image311844.png
Type: image/png
Size: 9409 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9409 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image726463.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image244656.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210407/c8cb39e6/attachment-0007.png>