In Germany they use overlap sending & receiving on ISDN circuits, meaning that call setup messages don't contain the entire dialled number (i.e. en bloc dialling), instead the dialled digits will be split across several call setup messages. This is complicated by the fact that this isn't done for all calls - calls from international numbers & mobiles use en bloc dialling.
The Cisco configuration guide for overlap receiving says to enable it on the ISDN interface, disable direct-inward-dial & use T in your dial-peers to force a T302 timeout. However all the documentation I've seen covers a voice gateway with inbound & outbound dial-peers with timeout, not CME. This causes a problem as having just an inbound dial-peer with timeout doesn't result in digits after the first call setup message being captured, as the virtual dial-peers for the phones registered with CME don't have a timeout. The solution is to use a voip dial-peer pointing to the CME router to loop back the call, then translate the dialled number so that the phone's virtual dial-peer is matched.
Below is example configuration using a BRI interface, where the direct dial range is 8693920X & internal numbers are 920X. After experimentation I found the 6000ms value for the overlap receiving T302 timeout to work the best (the default is 10000ms).
interface BRI0/1/0
no ip address
isdn switch-type basic-net3
isdn overlap-receiving T302 6000
isdn point-to-point-setup
isdn incoming-voice voice
isdn send-alerting
isdn sending-complete
isdn static-tei 0
!
voice translation-rule 1
rule 1 /^8693\(920.\)/ /\1/
voice translation-profile BRI_Called
translate called 1
!
dial-peer voice 3000 pots
description BRI0 inbound
incoming called-number 869392T
port 0/1/0
dial-peer voice 3001 voip
description Loopback for overlap receive T302 timeout
translation-profile outgoing BRI_Called
destination-pattern 869392T
session target ipv4:172.23.12.130
incoming called-number 92..
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
Looking at the debug isdn q931 output, we can see the first call setup message arrive, followed by the 2nd containing the last digit & then the call connects correctly:
001218: May 3 11:49:04.136: ISDN BR0/1/1 Q931: TX -> RELEASE pd = 8 callref = 0x2B
001219: May 3 11:49:04.188: ISDN BR0/1/1 Q931: RX <- RELEASE pd = 8 callref = 0xAB
001220: May 3 11:49:20.569: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x01
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Exclusive, B1
Progress Ind i = 0x8283 - Origination address is non-ISDN
Calling Party Number i = 0x00A3, N/A
Plan:Unknown, Type:Unknown
Called Party Number i = 0xC1, '8693920'
Plan:ISDN, Type:Subscriber(local)
001221: May 3 11:49:20.573: ISDN BR0/1/0 Q931: TX -> SETUP_ACK pd = 8 callref = 0x81
Channel ID i = 0x89
Exclusive, B1
001222: May 3 11:49:21.125: ISDN BR0/1/0 Q931: RX <- INFORMATION pd = 8 callref = 0x01
Called Party Number i = 0xC1, '0'
Plan:ISDN, Type:Subscriber(local)
001223: May 3 11:49:27.149: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x81
001224: May 3 11:49:27.193: ISDN BR0/1/0 Q931: TX -> ALERTING pd = 8 callref = 0x81
Progress Ind i = 0x8188 - In-band info or appropriate now available
001225: May 3 11:49:29.297: ISDN BR0/1/0 Q931: TX -> CONNECT pd = 8 callref = 0x81
Channel ID i = 0x89
Exclusive, B1
001226: May 3 11:49:29.377: ISDN BR0/1/0 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01
001227: May 3 11:49:29.381: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected
