03-25-2024 03:32 AM
Hi Everyone, I hope everyone in the community is doing well.
I have 4 SIP connections terminated to the vCUBE (PSTN, Webex, Teams, and on-prem CUCM). I am using DPG on each incoming dial-peer to route the call to the outgoing dial-peers. However, on the DPG, I created dial-peer preferences for each dial-peer (preference 1, 2, 3). When an incoming call hits the DPG dial-peers, it checks all dial-peers one by one, and that takes a long time for the call to connect. Is there a way I can fix this issue to reduce the time it takes for the call to be connected (30-40 seconds) or sometime matches incorrect outgoing dila-peer?
example:
voice class dpg 4
description From Teams to Webex or CUCM or PSTN
dial-peer 6 preference 2
dial-peer 2 preference 3
dial-peer 4 preference 1
Solved! Go to Solution.
03-26-2024 03:20 AM
I completely deleted all DPG and dial-peer associations, then reconfigured and tested each one individually. Therefore, I assume the main issue was a call loop. I am utilizing a combination of server-group, e164-pattern-maps, and DPG.
03-25-2024 03:48 AM
The precision approach to solving this would be e164-pattern-maps so each TN has only one appropriate destination. This is also the most efficient for CUBE; every additional dial-peer it has to hunt through lowers the Calls Per Second capacity since it’s additional load on the CPU.
It shouldn’t take that long to fail through a dual-peer unless the far end isn’t responding. Are you sure there isn’t a call loop happening here? What does the far-end reply with when sent an INVITE for a TN it doesn’t have? CUCM should send a 100 and then 404, at which point CUBE should immediately hunt to the next dial-peer (unless you’re also using server groups within the dial-peer, then it would have to repeat this process per-server.)
03-25-2024 08:22 AM
Where are these dial peers actually going? Based on your description on the DPG it looks like you’re sending it to 3 different services, CM, Webex or PSTN. IMO that is not a great structured DPG. Also if you are using server groups as @Jonathan Schulenberg mentioned you should add this to the server group, huntstop 1 resp-code 404 to 404, to not have it hunt trough all the servers in the group.
03-26-2024 01:49 AM
Thanks gents. The issue is now resolved.
03-26-2024 02:50 AM
Glad to hear that. For the good of the community it would be great if you please took the time to give a little more details on what you did to solve your issue.
03-26-2024 03:20 AM
I completely deleted all DPG and dial-peer associations, then reconfigured and tested each one individually. Therefore, I assume the main issue was a call loop. I am utilizing a combination of server-group, e164-pattern-maps, and DPG.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide