German (Overlap Receiving) ISDN With CME

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