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

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