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

[Kent Roberts]

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
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191119/b110f4ef/attachment.htm>