I just noticed this today, and wondered if others had experienced this. CVP 7, if you are interested.
I have a GD microapp to get three digits from the caller, and want to use those in a dynamic label to transfer the call to an IP phone where no DID is allowed. Could use Unity auto-attendant but bandwidth is low, so looking at a CVP solution since the call center is CVP.
After getting the digits I had a few checks to make sure the extension was in the configured set - if you return a label that is not a phone, it just drops the call. No CUCM message about an invalid number. So the CVP app has to know for sure.
When the extension is valid, I played a PM ("connecting, please wait ...") and then returned the label. Fixed label, no worries. Dynamic label - concatenate ("77002", CED) - failed. SIP messages in VP showed I was trying to get to 77002. The CED was empty.
Changed the program to copy from the CED into PV1 immediately after the GD microapp node, and appended PV1 in the dynamic label node. No problem.
So, are others aware that a call to a microapp that just does a Play Media will reset the caller entered digits variable to the empty string on the way out.
Is this something I should have known? Is it well documented?
I'll try that with CVP 4.1 and let you know. I would think that the CED would not clear unless you run another GD... however logic doesn't always apply with Cisco software.
Geoff - we're doing pretty much the same thing with UCCE/CVP 7. Using GD for a dial by extension option. Then we contatenate the location id with CED. The only difference is we're doing an RF8, sip refer. So it looks like this contatenate("rf8",branch_id,CED).
Interesting that you're having that problem.....
Any ES's applied?
Rob, thanks for your post.
It works fine as long as I copy out the CED before the little PM microapp that says "Connecting". If I don't do that, it gets clobbered.
Do you have a PM after the GD?
The SIP refer is very interesting. I must try that, because it will release the Call Server port. Any other special config required?
Actually, I just run the external script with GD - then stuff the CED into the label. I don't do a PM afterword, but do check for a couple other options, probably similar to the checks you're doing.
For the SIP refer, not much else is needed. If you're dialing a PSTN number, you would need to add routes on the SIP proxy in order to route PSTN numbers directly to the PSTN gateway. But if you're just doing a local extension, you should be good to go just using the RF8. It does have to be in "quotes" inside the label though.
Yeah, it's the PM after the GD that clobbers the CED. But I'm over it. ;-)
I just tried changing my dynamic label so that I had "rf" at the front of my previous concatenation - to reach an IP phone - and it worked without any changes.
I could tell from the CVP Diagnostic Applet that the calls had been dropped from CVP. Very nice. Saves a Call Server port and a signalling path.
Good suggestion for my "poor-man's dial by extension" application.
I've done the similar setup (withour Sip Refer Transfer). Problem I am facing is when the IP PHone extension rings the call gets dropped after almost 20 seconds. If I put the CFNA to VM after 15 seconds call goes to VM fine. If I increase the CFNA timer to 120 seconds still the call gets dropped after almost 20 seconds.
Other business processes using the same CVP and ICM setup can have calls in queue for much longer time. ICM 7.5.1, CVP 7.0.2.
Does someone know any known issue and a possible fix for it?
PSTN----VG ---CVP---ICM---IP Phone---VoiceMail
>Problem I am facing is when the IP PHone extension rings the call gets dropped after almost 20 seconds.
If you look at OAMP > Call Server > SIP tab > "Patterns for RNA timeout on outbound SIP calls", does the label of the IP phone you're using match a pattern there? That section typically includes the DN ranges of IP phones to allow CVP to pull back the call and reroute it when an agent doesn't answer a call. If that's the case you can look at adding a more specific pattern for your label with a longer timeout.
As far as the call dropping, if it would be helpful you can check the "enable target requery" in the properties of your label node and that will allow you to implement alternate logic if the RNA timer does kick in.
I guess the below was documented after this post (scripting and media routing guide):
In Customer Voice Portal, the Collected digits will only be cached for a CAPTURE microapp following
the digit collection node. If a non-digit collect nodes follows a digit collect node, Customer Voice Portal’ s
CED variable will get nulled out and inturn Call.CallerEnteredDigits also get nulled out .
For example, if the script is START > GD (Get Digit node) > CAPTURE NODE > PM (Play Media) >
CAPTURE NODE . In this case, user has to cache the collected data via ICM peripheral (or call) variables.