I have some basic questions about CUCM call flow with a SIP CUBE router, if anyone has a moment, please correct anything that is wrong.
Here is my understanding of the flow:
1. The called number matches an inbound dial-peer and applies the associated translation rule, if there is one
2. The translated number would then match an outbound Voip dial-peer that points to Call Manager (via a SIP or h323 trunk)
Does the trunk to call manager have a calling search space associated to it at this point?
Would this point be where a number would be translated from a call manager translation pattern, before any other step?
Is it considered poor practice to send a translated number from a dial-peer translation rule to a call manager translation pattern?
3. I am unclear exactly what happens here,
if there is a translation pattern, the number gets translated,
the number from the dial-peer tranlation rule,
checks a CSS, does it match a directory number?
How you match the inbound dial-peer depends on what you have configured, it's all explained here:
ANY kind of trunk in CUCM requires an inbound CSS which defines what it can reach within CUCM dial plan.
Once the call is extended to CUCM regular logic applies, if you can only reach a TP then you reach it, if you can reach the destination DN it will ring, etc. There is no difference because this is a CUBE.
If you already know what you want to translate the call to, I don't see the point translating it twice. Either translate it with translation-rules in IOS or with translation patterns in CUCM.
If you have both a translation-rule and translation pattern they're both applied. CUCM has no knowledge that the DN has already been subject to a translation until it received the call. CUCM just knows the DN matches a TP and it will apply it.
Translation-rules do not have any idea of what you have in CUCM for the trunk and call routing. If the call matches the condition, it's applied.
If your're familiar with H323 it's very similar to it.
If this helps, please rate
Thanks for the reply,
Sorry for the basic questions, but they are general
From the CUCM perspective:
Ok, so so the number has just left the Voip dial-peer on the CUBE and entered the trunk to go to call manager, assuming that the CSS space on the trunk is correct, and no other translating is being done, where does it go from there?
Does it look for a directory number that matches the translated number (if there is a directory number that matches)?
For example, if there is a DID associated to an FXS port endpoint, once leaving the voip dial-peer onto the trunk, the resulting pattern would look to see if there is a translation pattern in call manager that matches the incoming number correct?
Does the path go directly to a directory number if no translation-pattern in CUCM matches ?
From the dial-peer perspective:
"destination-pattern" always looks to me like you point the destination-pattern to the endpoint, not the "origin" as stated in the document.
For example, if I configure a destination-pattern on a POTS dial-peer isn't that what number is dialed to get to the POTS endpoint?
The document makes it sound like the origin (or calling number?) is the destination pattern.
Can you clarify?
Once the call arrives thru the SIP trunk it's exactly the same as if you were calling from a phone.
Routing depends of what digits are used with the significant digits and the inbound CSS. There is no difference in how the call is routed.
If the trunk sends 1234 and the inbound CSS has a 1234 phone it can reach, it will ring it. If you send 4321 and it's a TP the inbound CSS can reach, then it's routed that way. Exactly the same as if you were calling from an IP Phone. Don't overcomplicate things in your head.
Destination pattern works to match both inbound and outbound dial-peers. Document explains under which circumstances and how it's used.
For example, if I configure a destination-pattern on a POTS dial-peer isn't that what number is dialed to get to the POTS endpoint? yes, outbound DP matching
The document makes it sound like the origin (or calling number?) is the destination pattern. yes, for inbound DP matching it's option #3
If this helps, please rate
I really appreciate you taking the time to answer my questions.
One more for out bound:
The destination pattern determines what digits can be called in a particular partition for an outbound call.
If I have a destination pattern for only toll free calls, 1800xxxxxxx, and I have a device attached to an FXS port that calls 5551800xxxxxx, I have to either strip the 555 off, or have a destination pattern for 5551800xxxxxxx.
Is this correct?
If so, in CUCM, can I strip off the 555 somewhere along the way?
what you'd do is create a route pattern in CCM, something like:
And set Discard Digit = predot
So when the FXS device dials 5551800xxxxxxx, it will match this route pattern
and CCM will strip off pattern before the dot (555) and only send 1800XXXXXXX
to the GW/Route List specifed in this route pattern.
Also be aware you will need a pots dial-peer to match what is sent from CUCM to the gateway. Question how are the users dialing the 800 numbers in CUCM? Are they dialing 5551800XXXXXX?Seems rather odd that callers would be dialing 555 before a call. And on the fxs port have you defined it with a plar statement?
dial-peer voice 300 pots
port 0/1/0 <---the fxs port you are sending to.
These questions are mainly for educational purposes to get a better understanding of the call flow.
The gateway with the FXS is MGCP
"you will need a pots dial-peer to match what is sent from CUCM to the gateway"
I am thinking in terms of from FXS outbound, so the only thing to ensure is there is a route pattern that matches correct?
"Question how are the users dialing the 800 numbers in CUCM"
I am not sure what you are asking here, do you mean aside from a dial-peer if not MGCP?
MGCP is a whole different matter. H323 and SIP are quite similar, but MGCP is a master/slave protocol.
There is a dial-peer, but it's MGCP controlled so ALL the call control, transformation, change DN, add digits, strip digits, etc. Needs to be done in CUCM.
There is NO destination pattern in MGCP, they look like this:
dial-peer voice 1200 pots
If this helps, please rate
In case anyone like me see this and would like some good information,
here is an outstanding document I found that is right along the lines of the questions I was asking: