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
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
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
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
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
>
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
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
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
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
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
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
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
13 matches
Mail list logo
