Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Wednesday, 6 November 2013

Outbound dial peer matching, direct inward dial (DID)



Finally got inspiration again to do a new post. This time on some pretty basic stuff. So basic in fact that most of the time,  when I need to configure dial peers, I need to look this shit up.  (Might be because my brain is the size of a peanut, dunno).  Anyway dial peers, and more specifically outbound dial peers. How are they matched and according to what mechanism.


In order to match Outbound dial peers voice gateways uses; destination pattern (irrespective of whether the its a pots or a voip dial peer

To match the relevant dial-peer with its destination pattern  there are two mechanisms:


  • With Direct inward dial 
  • Without Direct inward dial

Let me elaborate on these two different mechanism and how to configure them. Before I do that, please remember that the configuration on whether direct inward dial is being used or not, need to be applied on the INBOUND DIALPEER. This because a call always has two call legs; an inbound and an outbound call leg.

Direct inward dial (DID) en bloc

With DID calls, also referred to as one stage dialing, the setup message contains all the digits necessary to route the call, and the voice gateway should not do any subsequent digit collection. To invoke DID it will need to be configured on the inbound dial peer(s). This can be done by using the direct-inward-dial command under the dial peer, for example:

dial-peer voice 1 voip
  incoming called-number .
  direct-inward-dial


Of course you don't have  use incoming called-number  on a separate, dedicated  inbound voip dial peer, like I have done above, you can also use it on existing dial peers, for instance the ones pointing to your CUCM (as I showed below). 

When a gateway receives a DID dial string it searches the whole string, assuming ALL digits have been received. For example, a gateway receives dial string 197023. When DID is used, it will match dial peer 3, because this is an exact match.


dial-peer voice 1 voip
 description to CUCM
 destination-pattern 197 
 session target ipv4:192.168.10
 incoming-called number . 
 direct-inward-dial
!
dial-peer voice 2 voip
 description to CUCM
 destination-pattern 197023
 session target ipv4:192.168.10.1
 incoming-called number . 
 direct-inward-dial



non DID (digit-by-digit)

Non-DID, also called two staged dialing, is the mechanism a gateway uses when no DID is configured on the inbound dial peer. In this case the gateway uses digit by digit analysis (digits are collected inband).  This would mean that each dial peer that has a destination pattern, is analysed digit by digit until a pattern is matched. Once the gateway matches a dialpeer (ANY DIAL PEER), the call is routed straight away, without waiting for any additional digits of for the interdigit timeout to expire. Say for instance ,a dial string of 1970566 gets offered to the gateway and the gateway has two dial peers, one with pattern 19705 and one with 1970566, the dial peer with pattern 19705 is used. This means that the last two digits, 66, never get collected (see below).

dial-peer voice 2 voip
 destination-pattern 1970
 session target ipv4:192.168.10.1

dial-peer voice 3 voip
 destination-pattern 1970566
 session target ipv4:192.168.10.1



You can see that, without DID, you will quickly run into trouble with a variable length dial plan. 

In order to "disable" variable length matching on a dial peer, add the $ at the end of a destination pattern:

dial-peer voice 2 voip
 destination-pattern 1970$
 session target ipv4:192.168.10.1



The $ in the destination pattern, now forces the digits after 1970 to be considered as well.  You can also choose to end every destination pattern with    T , to signify that the interdigit timeout needs to occur, inidcating no more digits are to be collected for matching.


I personally prefer to use direct inward dial, in which case you will not run into issues with variable length dial plans. This for the simple reason that when a call hits a gateway either from CUCM or PSTN, it will present the full dial string to the gateway (DNIS). If an inbound call can present the full dial string, there is no point NOT to use the default digit-by-digit matching.


an easy way to test which dial-peer is getting matched is to issue:

show dialplan number <insert number>

This will tell you exactly is the intended dial peer gets matched or not

Namaste!



No comments:

Post a Comment