<div dir="ltr"><div>Hi Kent,</div><div><br></div><div>even though we are talking about a UCCE deployment, we are still stuck with IP IVR. This means no CVP for the time being.<br></div><div><br></div><div>The only way I can pass this kind of metadata to the IVR/ICM/UCCE world is through CTI/Jtapi, afaik.</div><div><br></div><div>It is not clear to me the precise logic used by cucm to translate between sip and Jtapi.</div><div><br></div><div>Any hints in this regard?</div><div><br></div><div>Thanks!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 19 nov 2019 alle ore 15:23 Kent Roberts <<a href="mailto:kent@fredf.org">kent@fredf.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">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...<br><div><br></div><div>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 anything you want with it.</div><div><br></div><div>I believe your stuck replacing ANI, as CUCM may not forward all the sip headers…</div><div><br></div><div>Have you tried to turn up the CVP SIP debugs, and see if the headers get passed?</div><div><br></div><div><br><blockquote type="cite"><div>On Nov 19, 2019, at 3:19 AM, daniele visaggio <<a href="mailto:visaggio.daniele@gmail.com" target="_blank">visaggio.daniele@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>Thanks, Stephen. <br></div><div><br></div><div>Yes, I'm aware of lua scripting. <br></div><div><br></div><div>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.</div><div><br></div><div>I tried also to transform the incoming REFER into a brand new INVITE (oracle sbc has this feature built-in). Sadly this breaks the routing, meaning the transfer totally fails.</div><div><br></div><div>Before going on with other exotic manipulations, I would like to know in advance if what I want is even possible...it seems to me cucm is totally ignoring whatever I put in the REFER.<br></div><div><br></div><div>Best Regards<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 19 nov 2019 alle ore 11:01 Stephen Welsh <<a href="mailto:stephen.welsh@unifiedfx.com" target="_blank">stephen.welsh@unifiedfx.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Hi Daniele,</div>
<div><br>
</div>
Not my area, but have you looked at using LUA scripts to pass-thru/transform SIP headers on UCM:
<div><br>
</div>
<div>
<div><a href="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" target="_blank">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</a></div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Stephen Welsh</div>
<div><br>
<blockquote type="cite">
<div>On 19 Nov 2019, at 09:38, daniele visaggio <<a href="mailto:visaggio.daniele@gmail.com" target="_blank">visaggio.daniele@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">Good morning.<br>
<br>
Diagram:<br>
<br>
FINESSE --- UCCE --- CUCM --- SBC --- THIRD PARTY SIP SERVER<br>
<br>
<b>Scenario</b>:<br>
<br>
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.<br>
<br>
So we have:<br>
<br>
<b>Transferee</b>: it's the PSTN caller, i.e. the party ending up being transferred to the finesse agent<br>
<br>
<b>Transfer Target</b>: technically it's a CTI route point on CUCM, which triggers a UCCE script placing the call on a queue. It is the new party being introduced to the Transferee. In the end it represents a finesse agent.<br>
<br>
<b>Transferor</b>: THIRD PARTY SIP SERVER, i.e. the party initiating the transfer of the Transferee (PSTN caller) to the Transfer target (finesse agent)<br>
<br>
In order to transfer the call, THIRD PARTY SIP SERVER sends a SIP REFER message to SBC/CUCM.<br>
<br>
>From a routing perspective, the transfer works fine. The pstn caller can be transferred to a finesse agent.<br>
<br>
<b>GOAL</b>:<br>
<br>
we need to alter the calling id seen by UCCE and then by Finesse Agent. Actually, the calling id (ANI) seen by UCCE/Finesse is the original PSTN phone number.<br>
<br>
There are business reasons why we need to do so. <br>
<br>
The crucial point is that THIRD PARTY SIP SERVER sends back to cucm a custom sip header in the REFER message containing the phone number needed to be seen by UCCE/Finesse. This can be different from the original PSTN ANI (e.g. the pstn call is anonymous). This
new ANI is dynamic and so it's not always the same.<br>
<br>
I tried with many sip manipulations on the SBC. I placed the new ANI into the REFER FROM sip header, in the Remote-Party-id, the PAI header. Nothing worked so far.<br>
<br>
Is there a way to set a new ani in this call transfer scenario? I need to find a way to "convince" cucm to pass the new ANI via Jtapi to UCCE/IVR/Finesse. Is this possible?<br>
<br>
<div>Thanks,</div>
<div><br>
</div>
<div>Daniele<br>
</div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote></div>
_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></div></blockquote></div><br></div></blockquote></div>