IPIVR. Well that’s been some time. not sure on that one I don’t
think that info ever makes it. I think your stuck with playing at the
dialpeer level or the scripting. I’ll email if I think of anything
Kent
> On Nov 19, 2019, at 08:01, daniele visaggio
> wrote:
>
>
Hi Kent,
even though we are talking about a UCCE deployment, we are still stuck with
IP IVR. This means no CVP for the time being.
The only way I can pass this kind of metadata to the IVR/ICM/UCCE world is
through CTI/Jtapi, afaik.
It is not clear to me the precise logic used by cucm to
Did something similar to this in the SBC at the dial-peer level with number
translations, when UCCE first didn’t support improper ANI many moons ago...
If you can grab the inbound call at the dial-peer level (or via the return
carrier). And send it in to its own CUCM SIP config, then you can do
Thanks, Stephen.
Yes, I'm aware of lua scripting.
Having an sbc in front of the cucm, I already tried to alter the REFER
message in some obvious ways but no luck so far.
I tried also to transform the incoming REFER into a brand new INVITE
(oracle sbc has this feature built-in). Sadly this
Hi Daniele,
Not my area, but have you looked at using LUA scripts to pass-thru/transform
SIP headers on UCM:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/9_0_1/sip_t_n/5-sip_pass_thru.html
Thanks
Stephen Welsh
On 19 Nov 2019, at 09:38, daniele visaggio
Good morning.
Diagram:
FINESSE --- UCCE --- CUCM --- SBC --- THIRD PARTY SIP SERVER
*Scenario*:
CUCM receives a call from PSTN. A route pattern sends the call to THIRD
PARTY SIP SERVER which, in turn, transfers the call back to UCCE IVR SCRIPT
via SBC/CUCM.
So we have:
*Transferee*: it's the
