Dial-Peer, part 3

This dial-peer discussion is to address dial-peers in order to establish call-legs. On each gateway, we will capture an inbound call using a dial-peer whether the inbound call leg is POTS or VOIP and then focus on extending that call by using a dial-peer to establish an outbound dial-peer. For this discussion, we will be focusing on POTS to VOIP dial-peers only and then look at what troubleshooting commands that can be executed on the gateways to verify our configuration.

Let’s first focus on call legs concept:

In the above illustration we have a Cisco Unified Communications Manager or IP PBX sending a call through a gateway to obtain access let’s say to the PSTN. As shown in the illustration, the gateway will require at least two dial-peer statements: 1- to match the inbound VOIP call leg (Optional) and 2 – to match the outbound POTS call leg. So, if the call were setup, we would actually see two call legs on the gateway in which it terminates the VOIP packet stream and converts it outbound to whatever the POTS interface we are using prescribed format.

Now what if we have two gateways involved with this process, let’s look and see how the call legs will be setup. Consider this illustration:

Here we have a call that is originating on the POTS side at the far left and then terminating at a separate gateway at the far right which is POTS as well. Each gateway will have two call legs therefore a total of four call legs will be setup as depicted in the diagram above. On the originating gateway, you will have an incoming POTS call leg followed by an outgoing VOIP call leg. On the terminating gateway, you will have an incoming VOIP call leg followed by an outgoing POTS call leg.

Now if we isolate each gateway and used the command Show voice call status while a test call is still active; we would see something like this:

Router# show voice call status
CallID     CID  ccVdb      Port      DSP/Ch  Called #   Codec    Dial-peers
0x1        11CE 0x02407B20 1:0.1     1/1     1000       g711ulaw 2000/1000

Now looking at the readout, you are looking at two distinct call legs in which the inbound call leg is coming in on Dial-Peer 2000 and the outbound call leg is using Dial-Peer 1000.  The VOIP codec will be G.711ulaw during the VOIP side of the transmission.

Another command that would give us more detail concerning the call legs would be Show voice call status compact which would give a display below:

Router# show call active voice compact
(callID)   A/O FAX T Codec    type    Peer Address    IP R:
Total call-legs: 2
58 ANS     T11          g711ulaw   VOIP     Psipp 2001:......:230A:6080
59 ORG     T11          g711ulaw   VOIP     P5000110011

In this format you can distinctly see that it says two call legs total. By running the same show command of the far right gateway will give us the same type of readout but maybe using different dial-peer tags.

Now for each inbound call leg we will try our best not to match the ‘Default Dial-Peer 0’ which could have negative consequences. In the second paragraph above, I mentioned that the incoming dial-peer was optional, which means that instead of matching a dial-peer of your choosing, it will match Cisco’s default dial-peer 0. The dial-peer 0 negative consequence is:

  • Will accept any codec
  • IP precedence
  • Vad enabled
  • No rsvp support
  • Fax-rate service
  • No ivr application

Now when creating your dial-peers, you will use different constructs to determine if you using it as an outbound or inbound dial-peer.

For inbound dial-peers we can match for E.164 numbers by using

  1. Incoming-called number (DNIS or the called number)
  2. Answer-Address (ANI or calling number being presented)
  3. Destination-Pattern (This would be the ANI or calling number match to the destination pattern)
  4. Port (POTS port in which the call arrived on – POTS dial-peers only)
  5. Dial-Peer ‘0’

The incoming call will try to match each one of the above items in the order listed including the last item dial-peer ‘0’.

For outbound patterns we only use one construct to match an E.164 number for a match and that is destination-pattern.

This concludes the short summary on call legs, the types of dial-peers to match those call legs, and the negative consequences of using dial-peer 0.

In this article

Join the Conversation