Need help with CUBE dial-peers and call routing

[voip7372]

Hi

UPDATE:  See my reply to this post.  I think I actually have a problem with the service provider, not an issue with my config as I originally thought.  See my debug in the reply and let me know what you think

I hate to just ask for a complete solution here, but that may be easiest given our situation and my confusion about getting the mix of dial peers right to do this. We had a current working solution though I'm sure it's not as efficient and proper as it should be, but our situation has changed (become more complicated with more entities involved) and now this setup doesn't work.

Here's an overview of the scenario we have to deal with now...

Outgoing calls from CUCM (we now have two CUCM clusters using the same Cisco 4431 router - due to a company merger). We have one provider for normal PSTN calls (Verizon VoIP) and one provider for our call center (inContact), both use the same router. We need to send normal outgoing PSTN calls to Verizon but we also need to send certain outgoing calls to inContact. All outgoing CUCM calls to inContact will start with 91400....... but end up as +E164 and begin with +1400 before being send to inContact. All outgoing CUCM calls to Verizon will also start 9 but will be a variety of domestic U.S. and international calls. The key is, everything but 91400....... will go to Verizon. All 91400....... calls must go to inContact.  (we strip off the 9 and replace it with + before sending to Verizon or inContact)

Incoming calls from Verizon and inContact will be +E164 format and be sent to CUCM (either CUCM cluster A or cluster B, depending on the incoming called number). My original basic rule before we had to deal with two CUCM clusters was that anything starting with + will be sent to CUCM, but now I did start trying calls with a +E164 number map setup so we could route certain phone number ranges to CUCM A and other phone number ranges to CUCM Cluster B, for example. My config was working OK until I needed the +E164 number map config. Before that, my setup worked fine, but now we have calls matching the wrong dial-peer and I'm not sure yet about how to fix this. For example, my calls to the 1400 numbers that should be sent to inContact are matching the dial-peer to Verizon. I've looked over the dial-peer info on Cisco's web site regarding incoming dial-peer matching and so, but I'm still confused about the complete config so I thought it would be nice to see if someone here that knows dial-peer matching in the routers really well to show me an example for our setup that would work, then I can learn more about it and understand WHY it works that way and edit accordingly in the future, but most importantly, have a solution we can use to fix our problem.

Here are the basics of what I need to do and some basic facts about our situation:

1. Outgoing calls from either of the CUCM clusters will ALWAYS have 9 in front of the digits sent to the router. All calls that begin with 91400 (like 914005553333) should be sent to the inContact. All other calls that begin with 9 need to be sent to the Verizon IP address.
Example outgoing call from CUCM to Router:
915137211700 > Send to Verizon IP addresses (two dial peers for this, preference 1 and preference 2)
914005553333 > Send to inContact - I have the IPs in server-group 5

2. Incoming calls from Verizon and inContact will always begin with + and could be various lengths (because it could be an agent using inContact making an outgoing call to an international number or they could be calling a user on CUCM that has a +E164 DN - All CUCM DNs are +E164). Certain ranges of DID numbers need to be sent to CUCM A and other ranges of DID numbers sent to CUCM B.
Example incoming calls from Router to CUCM:
+15135558899 > Send to CUCM A
+15034445566 > Send to CUCM B

Here's a portion of the config I have now which I think is relevant for this question (see attached spreadsheet). It's an edited version of what I have been using successfully for a few years with only ONE CUCM cluster in the config, but when the addition of the other CUCM cluster came along and the need to send some DID numbers to one CUCM and some DID numbers to the other CUCM cluster, that's when I started having trouble. For now this is a new router addition and I can make changes for testing without affecting service, but we'll need it in service soon.

[voip7372]

UPDATE

Actually, maybe my config for the dial-peer/call routing IS working.  I just did a debug and noticed something.  I'm not very schooled on reading these debugs so please have a look and tell me what you think is wrong.  It appears to be selecting the dial-peer I want (dial-peer 403), but then there's some kind of a problem so it continues on and then selects dial-peer 400, which is NOT what I want.  

Original dialed digits in this example is 914005557777 and that should be converted to +14005557777 and use dial-peer 403 to reach inContact.  It should hit dial-peer 300 first (incoming) then select dial-peer 403 (outgoing).  It appears to be attempting that anyway...

See attached spreadsheet.

[Maren Mahoney]

The disconnect cause code of 47 often indicates a codec mismatch. If this is a SIP trunk to a service provider, can you provide a debug ccsip messages for the call?

*Feb  8 17:01:08.674: //228426/B282A4000000/CCAPI/cc_api_call_disconnected:
   Cause Value=47, Interface=0x7FA4FA23A760, Call Id=228426
*Feb  8 17:01:08.674: //228426/B282A4000000/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=47, Retry Count=0)
*Feb  8 17:01:08.674: //228425/B282A4000000/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.

You noted outbound dial-peer 400 is attempted. That is because 403 failed and the router is trying to be helpful and fail over to the next best outbound dial-peer.

Maren

[voip7372]

Hi

Here's the ccsip messages debug.  From what I can tell, at this point it has already determined that it will use dial peer 400 instead of 403 (due to whatever problem) because I see the IP of Verizon in the debug, so at this point it's only showing me the call to Verizon on dial-peer 400 (not 403 to inContact like I want). 

Once it gets to this point, Verizon answers and gives me the 'you have dialed an invalid number' message because it is indeed an invalid number (the +1400xxxxxxx type number, that was originally intended for inContact). 

As I was thinking about this, I realized Verizon and inContact 'might' not be ready for us because while this is indeed a working circuit with Verizon, we haven't been told by inContact that THEY are ready to receive calls from us, from THIS particular router.  We have two other routers that are already working with inContact and this will be the third.  I suppose it could just be a simple matter of inContact not accepting traffic from us from this router...yet.  Make sense?  

The IP addresses and phone numbers below have been edited to hide our real phone numbers and IP addresses:

See attached spreadsheet.

[Roger Kallberg]

Please learn how to attach file(s) with information to your posts so that they are not a mile long. It’s very unpractical to read your long posts the way you do it.

[voip7372]

I know how to attach files for this purpose but I thought if anyone was going to review it anyway, it may be more convenient to have it all right here without opening/downloading files...but perhaps not.  Noted.

Edit:   I fixed

[TONY SMITH]

We really need to see the debug for the failed call attempt to Incontact.  Or some feedback from the provider, assuming you've asked them why they're rejecting your calls.

As I expect you're aware although that called number preferentially matches the DP 403 destination pattern of 91400T it also matches DP 400's 9T.  Can you fix up the called number with your translation rules, so that the format is acceptable to Verizon?

[voip7372]

I'm waiting to hear from inContact.  I emailed them yesterday afternoon but they haven't replied yet.  Verizon is reselling the inContact service to us and Verizon is done with their part (regarding normal PSTN calls), so I realize now it's probably not an issue with my config but more of an issue with inContact not being ready on their side yet.  I hope to confirm that soon and when I find out, I'll be sure to update this discussion.  I know for myself, if I see a config here in the forum that I know works, it helps me solve problems sometimes, so I want to be sure to let everyone know this config works (if it does, and I think it does from what I've seen so far).  

I had no official training on Cisco when we were told to switch away from Avaya to support many thousands of employees, so that's one of reasons I didn't realize the router would match what I wanted (DP 403) but then continue searching if the call failed at that dial-peer.  Otherwise, I would have performed the debug voip ccapi inout command to figure that out before posting here.  

I looked into using that 'huntstop' command this morning and added that to dial peer 403 and boom...now I get a fast busy signal and the call stops at dial peer 403 like I want it to (it doesn't try to look for another route to take).  I may experiment with the huntstop command to see how it affects my other dial peers (the dial peers for the final destination) because I think that might make troubleshooting easier (if the call stops where I expect it to and not try any other dial peers).  

By the way, regarding this:  We really need to see the debug for the failed call attempt to Incontact.

The debug ccsip messages output I posted was indeed the call attempt to inContact.   That's the issue, it initially matched DP 403 like I wanted (digits 91400T) but then continued on to DP 400 (digits 9T) when it was not able to complete the call to inContact...it ended up going to Verizon which is DP 400.  

I added the 'huntstop' command on DP 403 this morning to stop that so it's easier to troubleshoot.  

Also: Can you fix up the called number with your translation rules, so that the format is acceptable to Verizon?

Verizon won't accept those '1400xxxxxxx' type calls from us.  It uses the same circuit, but the destination IP is different.  Those 1400xxxxxxx type calls must be sent only to inContact's SBC, which is why the call fails when it hits dial-peer 400 (which is for Verizon).  I think it's failing on DP 403 right now because inContact isn't ready for us yet (realized that's probably what's happening AFTER I created this post here on the forum.  Once I confirm that's the case, I'll let everyone know (so people can use my config also, if they need a solution like this...incoming calls going to two different CUCM cluster, using e164 number maps and for outgoing calls, using simple dial peers).

[voip7372 · Accepted solution]

Like I mentioned previously, it turns out that my config was OK.  The problem was Verizon was finished and ready to accept calls from us, but inContact (service resold by Verizon) was NOT ready for us and I failed to recognize this initially because I didn't realize my calls were hunting over to an alternate dial-peer instead of stopping at the dial-peer I wanted it to stop at, so I thought my call routing config in CUBE was wrong, but it's not.  It's fine.  I learned more about the 'huntstop' command and this will make my life/troubleshooting a lot easier in the future.  I added the huntstop command to a few of my dial-peers to prevent the call from searching past the dial-peer I really want to use.

I know sometimes people on forums can be a little stingy with sharing a complete working config, so for anyone's benefit here that might have a situation where you have 2 internal entities like 2 CUCM clusters and 2 external entities like Verizon and inContact all using the same router, I created a spreadsheet and attached it here for your use, if you find it helpful.  There are 2 tabs.  One with general notes and one with the CUBE config pertaining to the call routing (also with notes).