[cisco-voip] Call Transfer: Inject an arbitrary calling id (ANI) to a JTapi Transfer target

Tue Nov 19 10:59:28 EST 2019

Hy out there

maybe this could be done with CURRI on an incomming route or translation pattern

https://devnetsupport.cisco.com/hc/en-us/sections/115002851247-Cisco-Unified-Routing-Rules-XML-Interface-CURRI-
On 19. Nov 2019, 16:15 +0100, Kent Roberts <kent at fredf.org>, wrote:
> 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 <visaggio.daniele at gmail.com> 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 translate between sip and Jtapi.
> >
> > Any hints in this regard?
> >
> > Thanks!
> >
> > > Il giorno mar 19 nov 2019 alle ore 15:23 Kent Roberts <kent at fredf.org> ha scritto:
> > > > 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 anything you want with it.
> > > >
> > > > I believe your stuck replacing ANI, as CUCM may not forward all the sip headers…
> > > >
> > > > Have you tried to turn up the  CVP SIP  debugs, and see if the headers get passed?
> > > >
> > > >
> > > > > On Nov 19, 2019, at 3:19 AM, daniele visaggio <visaggio.daniele at gmail.com> wrote:
> > > > >
> > > > > 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 breaks the routing, meaning the transfer totally fails.
> > > > >
> > > > > 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.
> > > > >
> > > > > Best Regards
> > > > >
> > > > >
> > > > > > Il giorno mar 19 nov 2019 alle ore 11:01 Stephen Welsh <stephen.welsh at unifiedfx.com> ha scritto:
> > > > > > > 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 <visaggio.daniele at gmail.com> wrote:
> > > > > > > >
> > > > > > > > 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 PSTN caller, i.e. the party ending up being transferred to the finesse agent
> > > > > > > >
> > > > > > > > Transfer Target: 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.
> > > > > > > >
> > > > > > > > Transferor: THIRD PARTY SIP SERVER, i.e. the party initiating the transfer of the Transferee (PSTN caller) to the Transfer target (finesse agent)
> > > > > > > >
> > > > > > > > In order to transfer the call, THIRD PARTY SIP SERVER sends a SIP REFER message to SBC/CUCM.
> > > > > > > >
> > > > > > > > From a routing perspective, the transfer works fine. The pstn caller can be transferred to a finesse agent.
> > > > > > > >
> > > > > > > > GOAL:
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > There are business reasons why we need to do so.
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > 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?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Daniele
> > > > > > > > _______________________________________________
> > > > > > > > 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
> > > >
> _______________________________________________
> 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/20191119/ab059a45/attachment.htm>