ISDN Overlap Receiving

Overlap receiving allows the matching of dial peers as the digits are being entered.  I’m not aware of the benefits of ISDN overlap receiving, but it does exist and we need to be prepared for it on the voice lab.  Without overlap receiving, digits presented to available dial peers are sent en bloc, meaning that 5123 is analyzed as “5123″ and not “5″ … “1″ … “2″ … “3″

Sample Configuration – Inaccurate Dial-Peer

interface Serial3/0:15
no ip address
no logging event link-status
isdn switch-type primary-qsig # Primary switch type defined, instead of globally
isdn overlap-receiving  # Overlap receiving is enabled
isdn incoming-voice voice # Incoming voice calls bypass modems and handled as voice calls.
isdn send-alerting # Specify that Alerting message be sent before Connect message with ISDN calls
no cdp enable
!
!
voice-port 3/0:15
!
dial-peer cor custom
!
!
dial-peer voice 1 voip
destination-pattern 5 # Any dialed string beginning with “5″
session target ipv4:10.0.0.1

Sample Debug – Inaccurate Dial-Peer (Dialed 5500)

In this example, a dial-peer is matched before the entire digit string has been entered.  If there was a more exact match for “5500,” such as 55.., it would have been matched.  However, since overlap signaling did not establish some sort of time, the call was prematurely matched and sent over the MPLS to Dubai instead of Chicago, incurring some additional charges and waking up the sleep executive in Dubai instead of the helpdesk in Chicago.

# An incoming call with the first digit of called number 5.
*Mar  2 01:47:05.705: ISDN Se3/0:15: RX <- SETUP pd = 8  callref = 0x001A
*Mar  2 01:47:05.705:         Bearer Capability i = 0x8090A3
*Mar  2 01:47:05.709:         Channel ID i = 0xA9839B
*Mar  2 01:47:05.709:         Facility i = 0x91AA068001008201008B0102A11
402025CA002013B300B30090A01050A01030A0104
*Mar  2 01:47:05.713:         Facility i = 0x91AA068001008201008B0100A10
C02025CB006042B0C09008400
*Mar  2 01:47:05.713:         Calling Party Number i = 0×00, 0×83, ’5000′,
Plan:Unknown, Type:Unknown
*Mar  2 01:47:05.717:         Called Party Number i = 0×80, ’5′, Plan:Unknown,
Type:Unknown
*Mar  2 01:47:05.717:         High Layer Compat i = 0×9181

# An information message with the next digit 5.
*Mar  2 01:47:05.729: ISDN Se3/0:15: TX -> SETUP_ACK pd = 8  callref = 0x801A
*Mar  2 01:47:05.729:         Channel ID i = 0xA9839B
*Mar  2 01:47:06.385: ISDN Se3/0:15: RX <- INFORMATION pd = 8  callref = 0x001A
*Mar  2 01:47:06.385:         Called Party Number i = 0×80, ’5′, Plan:Unknown,
Type:Unknown

# The router matches received digits 55 with dial peer 1.

*Mar  2 01:47:06.393: ccCallSetupRequest numbering_type 0×80
*Mar  2 01:47:06.393: ccCallSetupRequest encapType 2 clid_restrict_disable 1
null_orig_clg 0 clid_transparent 0 callingNumber 5000
*Mar  2 01:47:06.393: dest pattern 5, called 55, digit_strip 0
*Mar  2 01:47:06.393: callingNumber=5000, calledNumber=55, redirectNumber=
display_info= calling_oct3a=83

# The call was disconnected from the remote router, because the number is incomplete as only 55 is sent, this fails to match any dial peers (dial peers at remote router were four digits in length).
*Mar  2 01:47:06.421: ccCallDisconnect (callID=0×25, cause=0×1 tag=0×0)
*Mar  2 01:47:06.421: ccCallDisconnect (callID=0×24, cause=0×1 tag=0×0)
*Mar  2 01:47:06.425: cc_api_call_disconnect_done(vdbPtr=0×62679168,
callID=0×24, disp=0, tag=0×0)

# The call was disconnected because of an unallocated/unassigned number.
*Mar  2 01:47:06.433: ISDN Se3/0:15: TX -> DISCONNECT pd = 8  callref = 0x801A
*Mar  2 01:47:06.433:         Cause i = 0×8081 – Unallocated/unassigned number

Sample Configuration – Corrected Dial-Peer

interface Serial3/0:15
no ip address
no logging event link-status
isdn switch-type primary-qsig
isdn overlap-receiving T302 2000 # T302 timer is configured to wait for two seconds.
isdn incoming-voice voice
isdn send-alerting
no cdp enable
!
!
voice-port 3/0:15
!
dial-peer cor custom
!
!
!
dial-peer voice 1 voip
destination-pattern 5T # “T” is added to the dial peer.

Sample Debug – Corrected Dial-Peer (Dialed 5678)

With the updated dial-peer configuration, you can see that the router waits to allow more digits to be entered before finding an immediate match based on a partial number string.

# An incoming call with the first digit of called number 5.
*Mar  2 21:36:10.132: ISDN Se3/0:15: RX <- SETUP pd = 8  callref = 0×0024
*Mar  2 21:36:10.136:         Bearer Capability i = 0x8090A3
*Mar  2 21:36:10.136:         Channel ID i = 0xA98386
*Mar  2 21:36:10.136:         Facility i = 0x91AA068001008201008B0102A114020262A
002013B300B30090A01050A01030A0104
*Mar  2 21:36:10.140:         Facility i = 0x91AA068001008201008B0100A10C020262B
006042B0C09008400
*Mar  2 21:36:10.140:         Calling Party Number i = 0×00, 0×83, ’5000′,
Plan:Unknown, Type:Unknown
*Mar  2 21:36:10.144:         Called Party Number i = 0×80, ’5′, Plan:Unknown,
Type:Unknown
*Mar  2 21:36:10.144:         High Layer Compat i = 0×9181

# An information message with the next digit 6.
*Mar  2 21:36:10.164: ISDN Se3/0:15: TX -> SETUP_ACK pd = 8  callref = 0×8024
*Mar  2 21:36:10.164:         Channel ID i = 0xA98386
*Mar  2 21:36:10.360: ISDN Se3/0:15: RX <- INFORMATION pd = 8  callref = 0×0024
*Mar  2 21:36:10.364:         Called Party Number i = 0×80, ’6′, Plan:Unknown,
Type:Unknown

# An information message with the next digit 7.
*Mar  2 21:36:10.660: ISDN Se3/0:15: RX <- INFORMATION pd = 8  callref = 0×0024
*Mar  2 21:36:10.664:         Called Party Number i = 0×80, ’7′, Plan:Unknown,
Type:Unknown

# An information message with the next digit 8.
*Mar  2 21:36:10.924: ISDN Se3/0:15: RX <- INFORMATION pd = 8  callref = 0×0024
*Mar  2 21:36:10.924:         Called Party Number i = 0×80, ’8′, Plan:Unknown,
Type:Unknown

# The router matches received digits 5678 with dial peer 1.
*Mar  2 21:36:20.168: ccCallSetupRequest encapType 2 clid_restrict_disable 1
null_orig_clg 0 clid_transparent 0 callingNumber 5000
*Mar  2 21:36:20.172: dest pattern 5T, called 5678, digit_strip 0
*Mar  2 21:36:20.172: callingNumber=5000, calledNumber=5678, redirectNumber=
display_info= calling_oct3a=83

# The call is successfully routed and the remote phone is ringing.
*Mar  2 21:36:20.228: ISDN Se3/0:15: TX -> CALL_PROC pd = 8  callref = 0×8024
*Mar  2 21:36:20.420: cc_api_call_cut_progress(vdbPtr=0x6221F1E8, callID=0×38,
prog_ind=0×8, sig_ind=0×1)
*Mar  2 21:36:20.440: ISDN Se3/0:15: TX -> ALERTING pd = 8  callref = 0×8024
*Mar  2 21:36:20.440:         Progress Ind i = 0×8188 – In-band info or appropriate
now available

4 Responses to “ISDN Overlap Receiving”

  1. Stift November 16, 2010 at 10:51 am #

    Greetings from germany. Overlap receiving is business as usual in germany, austria and switzerland.

  2. Otto March 26, 2012 at 12:44 pm #

    Hey Matt!,

    Glad to say hello to you!, I have a customer with a similar setup and I was wondering that if why couldn’t do the same on the incoming pots dial-peer. I know the number of digits the provider will send and have a couple translation rules on that incoming dial-peer, in my case the incoming dial-peer would have the “incoming called-number 1…” command. I can’t think of a reason this wouldn’t work, any thoughts?

    Thanks.

    Otto

    • Otto March 26, 2012 at 2:05 pm #

      Well, I actually think I should use incoming called-number 1T on the incoming dial-peer.

      Thanks!

      Otto

  3. Johns April 1, 2012 at 8:52 am #

    Hey there..like your blog..trying to read through now..its inspiring too..thanks for this at the outset..

    In the above eg, the dialpeer used is a voip one..but when a call comes in through an ISDN trunk, the incoming dial peer will always be a pots dial peer..rt? Please correct me if i am wrong..and overlap receiving is done on incoming dial-peer only ..Please confirm..

Leave a Reply:

Gravatar Image

Don't have a Gravatar? Get one!

Have you Subscribed via RSS yet? Don't miss a post!