cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
850
Views
4
Helpful
11
Replies

carrier based divert possible towards WxCC Entry point number ??

mrvoipstuff
Level 1
Level 1

Hi

just wanting to validate from WxCalling/CC experts if what I am thinking is possible

I have a CUBE doing encrypted calls (sRTP) to Teams phone system via Direct routing and will be trunked to Webex Calling/CC. Currently we have more than 100 DID ranges with each range having its own advertised number i.e. a CTI route point of UCCX so 100+ trigger numbers. I want to avoid my CUBE having to process the IVR calls because the overhead of encrypted calls..

I am thinking to have our ITSP do a carrier based divert on those individual numbers from all the different DID ranges. The destination diverted number will be from range which I will acquired via Cisco calling plan and set it to particular location within WxCalling. These destination numbers will be the corresponding entry point mapping numbers. This way when calls hit WxCC Entry point mapping number it's not consuming call legs on my CUBE. Only when it's time to transfer calls to agent is when WxCC would transfer to my on-prem CUBE which will in turn route to Teams phone system. Since there's no voice cut-thru process possible in my topology as happens in on-prem CUCM/UCCX where RTP destination IP changes over from UCCX to Agent's IP I am conscious of the impact of extra call legs (because they are encrypted calls) on CUBE ...

Appreciate any feedback ... 

1 Accepted Solution

Accepted Solutions

Another point:

Would you be encrypting the call leg between CUBE and WxCC?
If no, I wouldn't see any advantage of splitting up the IVR numbers to another PSTN access, because the unencrypted calls won't bring a 44xx router to it's limits, taking your total number of about 600 - 700 simultaneous calls.
4431 supports 3000 and 4451 supports 6000 unenc. calls, both support 750 encrypted in total (depending on the encryption algorithm used).
And even if you unload the IVR calls, the agent calls will always run via the CUBE and to MS teams, so they will be encrypted anyway.

Taking all this info, I personally wouldn't bring in an additional (complexity adding) entity into this, without a real advantage.

View solution in original post

11 Replies 11

b.winter
VIP
VIP

Why don't you ask this question to your provider?
Who in the forum should answer the question, which feature your provider supports or not?

Did I ask anywhere whether my carrier is supporting this or not ?? that is not the question ... so chill 

I am simply asking a question from an architectural stand point given how integration works and how many resources are consumed on CUBE .. if you can't answer the question just scroll past ...

Then what's your question? You wrote a TL;DR text without an obvious question ...
One hint: Sometimes a drawing helps understanding a non-standard setup^^

What should this mean:
"Since there's no voice cut-thru process possible in my topology as happens in on-prem CUCM/UCCX where RTP destination IP changes over from UCCX to Agent's IP I am conscious of the impact of extra call legs (because they are encrypted calls) on CUBE ..."

For a incoming call to WxCC, I understood the following flow:
Carrier 1 --> forward to Wx calling plan carrier --> WxCC

For an agent call:
WxCC --> CUBE --> MS

The RTP will then go like this:
Carrier 1 --> Wx calling plan carrier --> WxCC --> CUBE --> MS

Thanks. your understanding of the flow is correct .... Question is "Would the idea of my ITSP diverting a number (customer advertised #) to another number (Entry point mapping #) that resides in the Wx Calling plan work in theory so IVR on WxCC works off between Carrier 1 <<==> Wx Calling Plan carrier ? Basically don't want CUBE to be used for just IVR calls. only use CUBE until it's time for agent transfer in which case WxCC ==> CUBE ==> MS. Would that flow work in theory ?  have not done this before that's why wanting to confirm. 

The reason I am having the carrier forward number to another number in Wx Calling plan (and not directly terminate on my CUBE) is to reduce the number of secure call legs on CUBE ... So if all IVR calls are handled between ITSP <<==>> Wx Calling plan carrier and only agent based calls are transferred from WxCC ==> CUBE ==> MS then I could keep CUBE resource utilization in check. Wanting to check if this is a valid way to approach capacity issue on CUBE ?  

Before I can say anthing more, I need to get the picture straight:
Where is the carrier connection terminating (for all other numbers)? Also on the CUBE?
Or asked in a different way: How is the call-flow for a normal incoming call?

And are your users also using Webex Calling or just MS Teams?
So, is Webex just there for the WxCC part?

But I think, the question you need to ask yourself is: What's the amount for incoming WxCC calls compared to the normal traffic? So, what's the ratio and is it worth all this work and complicated setup (in terms of future implementation and troubleshooting)

If you have just a few WxCC calls per day, but a lot of normal calls to MS teams, the WxCC calls are not noteworthy.

On the other, you have to discuss with Cisco your setup during the A2Q-phase, if you setup is possible at all.
Because I'm not currently sure, if WxCC can use more than 1 PSTN options. Which, in your case, you have: 1 Calling Plan (which I assume should also be used for outgoing WxCC calls) and 1 BYoPSTN (in form of the CUBE to MS teams) to route the agent calls.


@b.winter wrote:

But I think, the question you need to ask yourself is: What's the amount for incoming WxCC calls compared to the normal traffic? So, what's the ratio and is it worth all this work and complicated setup (in terms of future implementation and troubleshooting)

 

About 300 concurrent calls during peak hours will be on WxCC (200 IVR, 100 agents) ... 150-200 calls concurrent for hunt groups, CMS audio in-dials, normal telephony, etc. 

Yes planning to discuss with Cisco during A2Q phase. Because WxCalling gives us flexibility of choosing PSTN connectivity type per location I was hoping to put all entry point numbers in one location/range of type Cisco calling plan. Then have my ITSP do diversion for all our advertised PSTN numbers where customers call to their corresponding entry point numbers that are in location using Calling plan. This way I'm thinking should be able to offload atleast 200 calls for IVR off of my CUBE ??? Let carrier handle those calls and only time CUBE gets involved is when it's agent transfer. i.e. WxCC ==> CUBE ==> MS 

I'll post back the results here ... 


@b.winter wrote: 

 

Where is the carrier connection terminating (for all other numbers)? Also on the CUBE?
Or asked in a different way: How is the call-flow for a normal incoming call?

Yes terminating on CUBE. Incoming is PSTN => ITSP => CUBE => MS Teams

Outgoing is MS Teams => CUBE => ITSP => PSTN 

 


@b.winter wrote:

So, is Webex just there for the WxCC part?


Correct ! Webex there to do just the WxCC function. normal telephony users and agents will be on Teams

Another point:

Would you be encrypting the call leg between CUBE and WxCC?
If no, I wouldn't see any advantage of splitting up the IVR numbers to another PSTN access, because the unencrypted calls won't bring a 44xx router to it's limits, taking your total number of about 600 - 700 simultaneous calls.
4431 supports 3000 and 4451 supports 6000 unenc. calls, both support 750 encrypted in total (depending on the encryption algorithm used).
And even if you unload the IVR calls, the agent calls will always run via the CUBE and to MS teams, so they will be encrypted anyway.

Taking all this info, I personally wouldn't bring in an additional (complexity adding) entity into this, without a real advantage.

thanks again for taking the time to post your thoughts on this ... Ok so my understanding up until now was calls "have to be" encrypted between CUBE and Wx Calling ... just like between SBC and MS Teams for direct routing. If unencrypted is possible then I don't need to introduce the complexity and can keep it unencrypted. using AES_CM_128_HMAC_SHA1_80 for reference. 

I think the only other potential issue I can run into is the 250 call limit on WxCC when using LGW ... I believe after that WxCC returns 403 Forbidden ... so may still have to split the calls between ITSP/calling plan to get around that. I think some discussions for me to do during A2Q phase many thanks again ..

You're welcome. Glad I could help (y).

And I agree, there probably will be some discussions for you in the A2Q.