You need at least two dial-peers if you think through all of the call flows.
- Using the same dial-peer for the incoming and outgoing call legs of the same "side" (eg CUCM) is possible. The most common example of this is "incoming called-number 9T" and "destination-pattern [0-8]..." for a classic four-digit CUCM numbering plan in the US.
- It is technically possible - but a really bad design IMO - to use the same dial-peer as the incoming call leg from one side and the outgoing call leg for the other side (eg in from CUCM and out to PSTN); however, this only works asymmetrically.
- It is not possible for a single dial-peer to cover all four parts of a two-sided CUBE design: inbound and outbound call legs of a CUCM to PSTN call as well as the inbound and outbound call legs of a PSTN to CUCM call.
Personally, I use the same dial-peer for incoming and outgoing to/from the same "side" of CUBE as mentioned in the first bullet point. I agree with Manish though for those gettting started: use a seperate one for all four side-and-direction combinations. It will make reading the "show call active voice brief" output a little easier to start.
I am a big fan of the URI matching "incoming uri via" approach since it ensures an exact match regardless of how the numbers are formatted as is the case when relying on incoming called-number. I still use destination-pattern, or e164-pattern-map if multiple destinations for that "side" on the outbound direction. In most designs.
On a related note, I also use COR (or LPCOR since it's the only option on ASR 1k) to prevent unintended/undesired hairpinning of the call. This is more of an issue when you aren't using an off-net prefix on CUBE for PSTN-facing numbers though. Just think through the failure scenarios: if CUCM returns a 404 Not Found, 503, etc. on an incoming call, will the PSTN-facing dial-peers be alternate matches for the outbound call leg? If yes, you had better prevent that from happening!
