Outbound calls out via specific cube/trunk

[rvarela1223]

Hopefully someone can answer this.  I have an existing cube with one provider configured and working just fine.  I have been tasked with creating another cube at another site coming back to our CUCM 11.0.  This is done and configured.  In testing outbound calls from test phone it keeps going to the original cube as opposed to the new one. 

I do know that a cube can/does support multiple interfaces from different providers and the dial peers can be configured with the specific did and ip addressing to ensure calls go out correctly.  In this instance we have 2 physical cubes setup at different locations and with different addresses.  Cube 1 (original) say has an address of X.X.X.50 while cube 2 has an address of Y.Y.Y.66

I have the separate device trunks created as well as the route list/route group/etc.  I even mirrored the existing route patterns for the new cube.  I just need any outbound calls for the test number made to go out on the specific trunk I created.

If anyone can advise would appreciate

[Nithin Eluvathingal]

quick answer Put new  RP in a different partition  and give the  test phone access to only this partition , you will be Able to make test calls. 

To provide the best solution need to know bit more details about your RP, RL, partition etc.

[Roger Kallberg]

If it is as you say that you have the correct configuration do a DNA to check the call routing for the phone that you want to use for the test of the new Cube. There you’ll see the path it takes trough your setup configuration.

[Nithin Eluvathingal]

As Roger  mentioned  you can run DNA it will show you the call flow. 

[TONY SMITH]

If you just want to test calls out of the second CUBE then you can configure this as follows ..

- New Route Group containing the second CUBE

- New Route List containing the RG just created

- Test Route Pattern pointing to the new RL

What I tend to do in this situation is make the test pattern a new prefix.  For example if our normal PSTN out pattern is "9.@" then my test pattern would be something like "*91.@".   In many cases I leave these in place anyway, so for example if the customer has call issues via one gateway we can quickly test forcing the call out of another one.

[VON CLAWSON]

All great answers above. I would just add, if you want to just test a single call without messing with the configuration of the first CUBE. Add a route pattern with a single number, a cell phone, for example, and put it in the same partition as your normal outbound route patterns. Point this Route Pattern to the Route List that has your new CUBE in it. Make sure this is a RL with only the RG that contains only this CUBE. Then make the call. Put on debug ccsip message and see what you get at the CUBE. 

Let me know if that helps.