Re: [cisco-voip] Server-groups and failover...

[Pawlowski, Adam]

Sure

Again some time ago but what we’d run into was that PSTN calls in would fail on 
the network side if we didn’t signal progress back within a period of time. 
With stock timers, it never was able to move through all of the available call 
processors (4) before this happened, so you’d not really had effective 
redundancy, nor could it fall through for handling if you wanted to do that. It 
was based on watching the debugging to see how the flow went when we ACL’d off 
various UCMs from the CUBE itself.

As you can see form other postings in the thread, I did not know enough about 
this at the time to adjust other timers to account for either mid-call or call 
teardown signaling. I’m still learning, as always.

On the outbound end to the ITSP we also had a BGP relationship setup with them 
to tear down routing if the physical circuit failed somewhere outbound. That 
allowed us two disparate CUBEs that would still be available for call routing, 
resources, etc even if we lost an outbound circuit – we could still reach both 
peers for LB/HA across the surviving one at another structure from either CUBE 
in the arrangement.

Adam



From: Anthony Holloway 
Sent: Tuesday, November 19, 2019 9:37 AM
To: Pawlowski, Adam 
Cc: Jonathan Charles ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Server-groups and failover...

I'm curious as to how you arrived at those settings. Would you be able to share 
your path to arriving at those specific settings?

I typically leave the 500ms alone but do lower the retries to so that the total 
worst case delay would be ~3sec. For no other reason than that was always the 
for h323 tcp timeout we all used to use.

I do also use OPTIONS though, because in my opinion, tweaking/enabling both 
provides the best user experience. Though I don't typically adjust the default 
OPTIONS timers and retries. Do you?

On Tue, Nov 19, 2019, 7:06 AM Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:
I think I had to make some adjustments to our timers as well to get this to 
work before network timeout or similar:

sip-ua
retry invite 2
timers trying 100
!

I know I also goofed this up between dial peer group and server group, one of 
the two will retry within the group, the other sure doesn’t.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Jonathan Charles
Sent: Monday, November 18, 2019 11:56 PM
To: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I pasted the wrong part of the script (to manually change it)...

Here is the actual config:



voice class server-group 1
 ipv4 172.31.120.43
 ipv4 172.31.125.43 preference 2
 description Verizon SIP
!

Jonathan

On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
First off, I'm wondering why it says "no ipv4" in front of your two addresses.  
That might be your problem right there.

Secondly, I'd recommend putting an explicit preference on your entries, it's 
just better for everyone, and you don't get a credit back from Cisco for saving 
on a few ascii characters by implicitly using the default.  Plus, if the 
default is 0, which it is, then your next preference should be technically 1.  
But then having nothing and 1 seems silly, because if pref 1 is actually pref 
2, then well, might as well call them pref nothing and pref 8.  I digress.

You might not have failed over, because you might not have provided the system 
with the correction conditions to failover...E.g., you didn't wait long enough.

No seriously, by default SIP failover occurs after 30 seconds.  Unless, did you 
lower the retry count under sip-ua?  Or did you enable SIP options?  If you 
enabled SIP options, have your confirmed that it's turned on correctly?

Can you share the output of the following commands:

show run | section sip-ua|sip.options-keepalive

show dial-peer voice summary

Feel free to redact what you need to, in terms of IPs or usernames/passwords.  
I am only looking for the features and settings for retries and keepalives.


On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Using session server groups on outbound dial-peers and it does not appear to be 
failing over:


voice class server-group 1
 no ipv4 172.31.125.43  preference 2
 no ipv4 172.31.120.43
 description Verizon SIP
!

We had the 172.31.20.43 go down (no response to invites) and we did NOT 
failover to the second (.125.43)...

What is needed to force a failover to the next configured SBC?


Jonathan
___
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

Re: [cisco-voip] Server-groups and failover...

[Pawlowski, Adam]

In this router we actually tried something different (and gave up on this 
implementation thus I think the dial-peer groups maybe not being effective here 
for redundancy, and we’d just not fixed it, it’s been a couple of years – it 
may have been the options ping either not working or marking the whole peer out 
of service despite other available targets).

I also like to complicate things as you can see below:

dial-peer voice 200 voip
description PSTN ITSP SIP Trunk
translation-profile outgoing ITSP-PSTN-Out
session protocol sipv2
session transport udp
session server-group 200
destination dpg 400
destination e164-pattern-map 2200
incoming called e164-pattern-map 200
voice-class codec 200
voice-class sip profiles 200
voice-class sip options-keepalive
dtmf-relay rtp-nte sip-kpml
no vad
dial-peer voice 400 voip
description Production UCM Dial Peer
translation-profile outgoing Windstream-PSTN-In
session protocol sipv2
session target dns:prodall.cmgroup.srv.domain
session transport tcp
destination dpg 200
destination e164-pattern-map 400
voice-class codec 400
voice-class sip options-keepalive
dtmf-relay rtp-nte sip-kpml
no vad
dial-peer voice 500 voip
description Non-Working Number 404 Code Fallthrough
service non_working_number out-bound
destination-pattern +.*T
session target loopback:rtp


voice class dpg 400
description Production UCM Dial Peer Group
dial-peer 400
dial-peer 500 preference 1
!
voice class dpg 200
description ITSP SIP Dial Peer Group
dial-peer 200
!
voice class server-group 200
ipv4 10.250.0.5
ipv4 10.250.0.6 preference 1
description ITSP Server Group
!

From: Johnson, Tim 
Sent: Tuesday, November 19, 2019 8:23 AM
To: Pawlowski, Adam ; 'Jonathan Charles' 
; Anthony Holloway 
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Server-groups and failover...

What’s your dial peer configuration look like? Curious if you have ‘huntstop’ 
configured.

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Pawlowski, Adam
Sent: Tuesday, November 19, 2019 8:07 AM
To: 'Jonathan Charles' mailto:jonv...@gmail.com>>; Anthony 
Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I think I had to make some adjustments to our timers as well to get this to 
work before network timeout or similar:

sip-ua
retry invite 2
timers trying 100
!

I know I also goofed this up between dial peer group and server group, one of 
the two will retry within the group, the other sure doesn’t.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Jonathan Charles
Sent: Monday, November 18, 2019 11:56 PM
To: Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I pasted the wrong part of the script (to manually change it)...

Here is the actual config:



voice class server-group 1
 ipv4 172.31.120.43
 ipv4 172.31.125.43 preference 2
 description Verizon SIP
!

Jonathan

On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
First off, I'm wondering why it says "no ipv4" in front of your two addresses.  
That might be your problem right there.

Secondly, I'd recommend putting an explicit preference on your entries, it's 
just better for everyone, and you don't get a credit back from Cisco for saving 
on a few ascii characters by implicitly using the default.  Plus, if the 
default is 0, which it is, then your next preference should be technically 1.  
But then having nothing and 1 seems silly, because if pref 1 is actually pref 
2, then well, might as well call them pref nothing and pref 8.  I digress.

You might not have failed over, because you might not have provided the system 
with the correction conditions to failover...E.g., you didn't wait long enough.

No seriously, by default SIP failover occurs after 30 seconds.  Unless, did you 
lower the retry count under sip-ua?  Or did you enable SIP options?  If you 
enabled SIP options, have your confirmed that it's turned on correctly?

Can you share the output of the following commands:

show run | section sip-ua|sip.options-keepalive

show dial-peer voice summary

Feel free to redact what you need to, in terms of IPs or usernames/passwords.  
I am only looking for the features and settings for retries and keepalives.


On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Using session server groups on outbound dial-peers and it does not appear to be 
failing over:


voice class server-group 1
 no ipv4 172.31.125.43  preference 2
 no ipv4 172.31.120.43
 description Verizon SIP
!

We had the 172.31.20.43 go down (no response to invites) and we did NOT 
failover to the second (.125.43)...

What is needed to force a failover to the next configured SBC?


Jonathan

Re: [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  
> 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  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  
>>> 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 
  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  
> 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
>> 

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

[daniele visaggio]

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  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 
> 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.we...@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 
>> 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

Re: [cisco-voip] Server-groups and failover...

[Anthony Holloway]

I'm curious as to how you arrived at those settings. Would you be able to
share your path to arriving at those specific settings?

I typically leave the 500ms alone but do lower the retries to so that the
total worst case delay would be ~3sec. For no other reason than that was
always the for h323 tcp timeout we all used to use.

I do also use OPTIONS though, because in my opinion, tweaking/enabling both
provides the best user experience. Though I don't typically adjust the
default OPTIONS timers and retries. Do you?

On Tue, Nov 19, 2019, 7:06 AM Pawlowski, Adam  wrote:

> I think I had to make some adjustments to our timers as well to get this
> to work before network timeout or similar:
>
>
>
> sip-ua
>
> retry invite 2
>
> timers trying 100
>
> !
>
>
>
> I know I also goofed this up between dial peer group and server group, one
> of the two will retry within the group, the other sure doesn’t.
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of 
> *Jonathan
> Charles
> *Sent:* Monday, November 18, 2019 11:56 PM
> *To:* Anthony Holloway 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Server-groups and failover...
>
>
>
> I pasted the wrong part of the script (to manually change it)...
>
>
>
> Here is the actual config:
>
>
>
>
>
> voice class server-group 1
>  ipv4 172.31.120.43
>  ipv4 172.31.125.43 preference 2
>  description Verizon SIP
> !
>
>
>
> Jonathan
>
>
>
> On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> First off, I'm wondering why it says "no ipv4" in front of your two
> addresses.  That might be your problem right there.
>
>
>
> Secondly, I'd recommend putting an explicit preference on your entries,
> it's just better for everyone, and you don't get a credit back from Cisco
> for saving on a few ascii characters by implicitly using the default.
> Plus, if the default is 0, which it is, then your next preference should be
> technically 1.  But then having nothing and 1 seems silly, because if pref
> 1 is actually pref 2, then well, might as well call them pref nothing and
> pref 8.  I digress.
>
>
>
> You might not have failed over, because you might not have provided the
> system with the correction conditions to failover...E.g., you didn't wait
> long enough.
>
>
>
> No seriously, by default SIP failover occurs after 30 seconds.  Unless,
> did you lower the retry count under sip-ua?  Or did you enable SIP
> options?  If you enabled SIP options, have your confirmed that it's turned
> on correctly?
>
>
>
> Can you share the output of the following commands:
>
>
>
> show run | section sip-ua|sip.options-keepalive
>
>
>
> show dial-peer voice summary
>
>
>
> Feel free to redact what you need to, in terms of IPs or
> usernames/passwords.  I am only looking for the features and settings for
> retries and keepalives.
>
>
>
>
>
> On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
> wrote:
>
> Using session server groups on outbound dial-peers and it does not appear
> to be failing over:
>
>
>
>
> voice class server-group 1
>  no ipv4 172.31.125.43  preference 2
>  no ipv4 172.31.120.43
>  description Verizon SIP
> !
>
>
>
> We had the 172.31.20.43 go down (no response to invites) and we did NOT
> failover to the second (.125.43)...
>
>
>
> What is needed to force a failover to the next configured SBC?
>
>
>
>
>
> Jonathan
>
> ___
> 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

Re: [cisco-voip] Server-groups and failover...

[Anthony Holloway]

Tim,

Surely he wouldn't have huntstop and be using server groups.

But even if he did have both, huntstop wouldn't stop a server group, right?
Just DP hunting, right?

On Tue, Nov 19, 2019, 7:23 AM Johnson, Tim  wrote:

> What’s your dial peer configuration look like? Curious if you have
> ‘huntstop’ configured.
>
>
>
> *From:* cisco-voip  *On Behalf Of 
> *Pawlowski,
> Adam
> *Sent:* Tuesday, November 19, 2019 8:07 AM
> *To:* 'Jonathan Charles' ; Anthony Holloway <
> avholloway+cisco-v...@gmail.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Server-groups and failover...
>
>
>
> I think I had to make some adjustments to our timers as well to get this
> to work before network timeout or similar:
>
>
>
> sip-ua
>
> retry invite 2
>
> timers trying 100
>
> !
>
>
>
> I know I also goofed this up between dial peer group and server group, one
> of the two will retry within the group, the other sure doesn’t.
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of 
> *Jonathan
> Charles
> *Sent:* Monday, November 18, 2019 11:56 PM
> *To:* Anthony Holloway 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Server-groups and failover...
>
>
>
> I pasted the wrong part of the script (to manually change it)...
>
>
>
> Here is the actual config:
>
>
>
>
>
> voice class server-group 1
>  ipv4 172.31.120.43
>  ipv4 172.31.125.43 preference 2
>  description Verizon SIP
> !
>
>
>
> Jonathan
>
>
>
> On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> First off, I'm wondering why it says "no ipv4" in front of your two
> addresses.  That might be your problem right there.
>
>
>
> Secondly, I'd recommend putting an explicit preference on your entries,
> it's just better for everyone, and you don't get a credit back from Cisco
> for saving on a few ascii characters by implicitly using the default.
> Plus, if the default is 0, which it is, then your next preference should be
> technically 1.  But then having nothing and 1 seems silly, because if pref
> 1 is actually pref 2, then well, might as well call them pref nothing and
> pref 8.  I digress.
>
>
>
> You might not have failed over, because you might not have provided the
> system with the correction conditions to failover...E.g., you didn't wait
> long enough.
>
>
>
> No seriously, by default SIP failover occurs after 30 seconds.  Unless,
> did you lower the retry count under sip-ua?  Or did you enable SIP
> options?  If you enabled SIP options, have your confirmed that it's turned
> on correctly?
>
>
>
> Can you share the output of the following commands:
>
>
>
> show run | section sip-ua|sip.options-keepalive
>
>
>
> show dial-peer voice summary
>
>
>
> Feel free to redact what you need to, in terms of IPs or
> usernames/passwords.  I am only looking for the features and settings for
> retries and keepalives.
>
>
>
>
>
> On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
> wrote:
>
> Using session server groups on outbound dial-peers and it does not appear
> to be failing over:
>
>
>
>
> voice class server-group 1
>  no ipv4 172.31.125.43  preference 2
>  no ipv4 172.31.120.43
>  description Verizon SIP
> !
>
>
>
> We had the 172.31.20.43 go down (no response to invites) and we did NOT
> failover to the second (.125.43)...
>
>
>
> What is needed to force a failover to the next configured SBC?
>
>
>
>
>
> Jonathan
>
> ___
> 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

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

[Kent Roberts]

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  
> 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 
> mailto:stephen.we...@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 > > 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

Re: [cisco-voip] Server-groups and failover...

[Johnson, Tim]

What’s your dial peer configuration look like? Curious if you have ‘huntstop’ 
configured.

From: cisco-voip  On Behalf Of Pawlowski, 
Adam
Sent: Tuesday, November 19, 2019 8:07 AM
To: 'Jonathan Charles' ; Anthony Holloway 

Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I think I had to make some adjustments to our timers as well to get this to 
work before network timeout or similar:

sip-ua
retry invite 2
timers trying 100
!

I know I also goofed this up between dial peer group and server group, one of 
the two will retry within the group, the other sure doesn’t.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Jonathan Charles
Sent: Monday, November 18, 2019 11:56 PM
To: Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I pasted the wrong part of the script (to manually change it)...

Here is the actual config:



voice class server-group 1
 ipv4 172.31.120.43
 ipv4 172.31.125.43 preference 2
 description Verizon SIP
!

Jonathan

On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
First off, I'm wondering why it says "no ipv4" in front of your two addresses.  
That might be your problem right there.

Secondly, I'd recommend putting an explicit preference on your entries, it's 
just better for everyone, and you don't get a credit back from Cisco for saving 
on a few ascii characters by implicitly using the default.  Plus, if the 
default is 0, which it is, then your next preference should be technically 1.  
But then having nothing and 1 seems silly, because if pref 1 is actually pref 
2, then well, might as well call them pref nothing and pref 8.  I digress.

You might not have failed over, because you might not have provided the system 
with the correction conditions to failover...E.g., you didn't wait long enough.

No seriously, by default SIP failover occurs after 30 seconds.  Unless, did you 
lower the retry count under sip-ua?  Or did you enable SIP options?  If you 
enabled SIP options, have your confirmed that it's turned on correctly?

Can you share the output of the following commands:

show run | section sip-ua|sip.options-keepalive

show dial-peer voice summary

Feel free to redact what you need to, in terms of IPs or usernames/passwords.  
I am only looking for the features and settings for retries and keepalives.


On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Using session server groups on outbound dial-peers and it does not appear to be 
failing over:


voice class server-group 1
 no ipv4 172.31.125.43  preference 2
 no ipv4 172.31.120.43
 description Verizon SIP
!

We had the 172.31.20.43 go down (no response to invites) and we did NOT 
failover to the second (.125.43)...

What is needed to force a failover to the next configured SBC?


Jonathan
___
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

Re: [cisco-voip] Server-groups and failover...

[Pawlowski, Adam]

I think I had to make some adjustments to our timers as well to get this to 
work before network timeout or similar:

sip-ua
retry invite 2
timers trying 100
!

I know I also goofed this up between dial peer group and server group, one of 
the two will retry within the group, the other sure doesn’t.


From: cisco-voip  On Behalf Of Jonathan 
Charles
Sent: Monday, November 18, 2019 11:56 PM
To: Anthony Holloway 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Server-groups and failover...

I pasted the wrong part of the script (to manually change it)...

Here is the actual config:



voice class server-group 1
 ipv4 172.31.120.43
 ipv4 172.31.125.43 preference 2
 description Verizon SIP
!

Jonathan

On Mon, Nov 18, 2019 at 10:22 PM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
First off, I'm wondering why it says "no ipv4" in front of your two addresses.  
That might be your problem right there.

Secondly, I'd recommend putting an explicit preference on your entries, it's 
just better for everyone, and you don't get a credit back from Cisco for saving 
on a few ascii characters by implicitly using the default.  Plus, if the 
default is 0, which it is, then your next preference should be technically 1.  
But then having nothing and 1 seems silly, because if pref 1 is actually pref 
2, then well, might as well call them pref nothing and pref 8.  I digress.

You might not have failed over, because you might not have provided the system 
with the correction conditions to failover...E.g., you didn't wait long enough.

No seriously, by default SIP failover occurs after 30 seconds.  Unless, did you 
lower the retry count under sip-ua?  Or did you enable SIP options?  If you 
enabled SIP options, have your confirmed that it's turned on correctly?

Can you share the output of the following commands:

show run | section sip-ua|sip.options-keepalive

show dial-peer voice summary

Feel free to redact what you need to, in terms of IPs or usernames/passwords.  
I am only looking for the features and settings for retries and keepalives.


On Mon, Nov 18, 2019 at 9:26 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Using session server groups on outbound dial-peers and it does not appear to be 
failing over:


voice class server-group 1
 no ipv4 172.31.125.43  preference 2
 no ipv4 172.31.120.43
 description Verizon SIP
!

We had the 172.31.20.43 go down (no response to invites) and we did NOT 
failover to the second (.125.43)...

What is needed to force a failover to the next configured SBC?


Jonathan
___
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

Re: [cisco-voip] VCS Expressway upgrade, 8.7 to 12.5

[Pawlowski, Adam]

If anything like this farts up on us then I usually remove it from the 
Expressway and put it back. It doesn’t really cause a ton of harm to do so and 
seems to clear a lot of issues.

Troubleshooting certificate issues ends up being kind of obnoxious as I’ve yet 
to find any debugging that really expands on the fault errors that you can see 
in the event log.

If this were me and I ran into “Decryption Error” and not a validation error, 
I’d be looking at say the default TLS level and ciphers as they may have 
changed between 8.7 -> 12.5. I know it’s default TLS 1.2 at this point. I’d 
actually just changed the s_channel string or what have you to try and 
eliminate the ciphers flagged for no forward secrecy and it broke MRA for me as 
well. I got “Internal Server Error” back in Jabber.

I don’t know if it enforces key lengths on the certificates at this point 
either but that’s where I’d go with this one personally.

Adam



From: cisco-voip  On Behalf Of Jonathan 
Charles
Sent: Monday, November 18, 2019 12:24 AM
To: Ryan Huff 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] VCS Expressway upgrade, 8.7 to 12.5

So, just an FYI, with MRA down, we rolled back to 8.7.3... going to try this 
again next Friday...

Should we try going to an intermediate version first, say, 8.11 or something?


Jonathan

On Sun, Nov 17, 2019 at 6:15 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Loaded the local certs... no joy...


Jonathan

On Sun, Nov 17, 2019 at 6:07 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Have you tried adding the IMP identity cert into the Expressway trust? It 
shouldn’t have to work that way, but if it does, might point to an issue with 
how the CA chain is being recognized in the trust.

Also, make sure to do a full reboot of the Expressway node after adding certs 
into the truststore (again, you shouldn’t have to do that but I’ve seen this 
work before).
Sent from my iPhone


On Nov 17, 2019, at 18:58, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:

When I try to refresh the IMP nodes, I get Failed: Unable to communicate with 
[[IMPNODE] CryptoError: Decryption failure.

On Sun, Nov 17, 2019 at 5:54 PM Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
I re-uploaded the root and intermediate CA certificate... still get the same 
error...

I also tried adding a new AXL user... same error...


Jonathan

On Sun, Nov 17, 2019 at 5:48 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Likely certificate / trust issues..
Sent from my iPhone


On Nov 17, 2019, at 18:36, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:

Yep, we are running into clustering issues...

Getting Inactive: (Remote host is reachable but connection is not established. 
Either refresh this page, or check the credentials.)

For IMP connection, so MRA is down...

Still looking for a fix...


Jonathan

On Fri, Nov 15, 2019 at 7:17 PM Erick Bergquist 
mailto:erick...@gmail.com>> wrote:
I’ve done 2 8.11.x to 12.5.5 fine (clustered setup, 4). There is a bug with 
clustering to watch out for but I did not encounter it. The 12.5 Cisco download 
page has a note and link about this.

Currently working on jabberd process high memory consumption issue on one node 
that has been present since 8.11.x which 12.5 had memory leak fix for but still 
an issue. Slow memory increase over time just on one of the edge nodes.

Going to look over 12.5.6 release notes now

Erick



On Fri, Nov 15, 2019 at 3:28 PM Matt Jacobson 
mailto:m4ttjacob...@gmail.com>> wrote:
If that is the case, then I would double check that it is supported. In the 
release notes there is a chart for supported platforms based on serial numbers. 
If it is a legacy Tandberg box, then I suspect 12.x may not work out for you.

On Fri, Nov 15, 2019 at 14:30 Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
This is a legacy Tandberg VCS for video only... no MRA, no remote phones... 
just inbound and outbound sip video...


Jonathan

On Fri, Nov 15, 2019 at 12:44 PM Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:
We’re at 12.5.3 and probably moving to 12.5.5/12.5.6 somewhere in the Holiday 
timeframe when everything quiets down a bit.

There hasn’t been really any significant issue upgrading from 8 -> 12, but 
there have been a couple of bugs that largely are all resolved by deleting and 
rebuilding whatever the thing is that is misbehaving.

The requirement for the _cup_login and _cisco-uds SRVs went away though it 
still endlessly logs a warning about not finding them, but it will work.

You do also gain the ability to play with the openssl cipher strings but in my 
limited experience trying to change those to bump them up a notch, it ends up 
breaking XMPP or something.

Adam

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Jonathan Charles
Sent: Friday, November 15, 2019 11:59 AM
To: Ryan Huff mailto:ryanh...@outlook.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] 

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

[daniele visaggio]

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.we...@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 
> 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

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

[Stephen Welsh]

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 
mailto:visaggio.dani...@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] 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
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip