Mailing List Archive

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@gmail.com<mailto:visaggio.daniele@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@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

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@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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>

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@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@unifiedfx.com <mailto:stephen.welsh@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 <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@gmail.com <mailto:visaggio.daniele@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@puck.nether.net <mailto:cisco-voip@puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip <https://puck.nether.net/mailman/listinfo/cisco-voip>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

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@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@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@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@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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>

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@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@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@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@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@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@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>

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@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@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@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@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@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@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@puck.nether.net
> > > > > > > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > > > > > >
> > > > > _______________________________________________
> > > > > cisco-voip mailing list
> > > > > cisco-voip@puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > > >
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip