Caller ID with Adit 600

We’re having some trouble getting caller ID to pass from an incoming PRI to an RBS connection facing an Adit 600 with FXS modules installed. We’re using asterisk 1.6.2.2 with dahdi 2.9.2 and digium TE435F card for the T1 connections.

Right now, the setup looks like this:
PRI -> Asterisk -> PRI -> Atlas 830 -> RBS (loopstart) -> Adit 600 -> FXS-connected modem

The above setup works perfectly and caller ID is passed by the Atlas 830 through the Adit to FXS-connected modem.

What we are trying to do is change the setup to:
PRI -> Asterisk -> RBS -> Adit 600 -> FXS-connected modem

I.e.: Cut out the Atlas 830 and allow Asterisk to do the PRI->RBS conversion on its own. This works, except that incoming Caller ID is no longer present at the modem. On the Asterisk side, we’ve done NoOp to check for CALLERID(name), CALLERID(num), CALLERID(number) and CALLERID(all) in the dialplan. All are present prior to Dial() being called, but nothing appears to be being passed.

Our dahdi system.conf looks like this:
loadzone = us
defaultzone = us
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24
span=2,2,0,esf,b8zs
bchan=25-47
dchan=48
span=3,0,0,esf,b8zs
fxoks=49-72
span=4,0,0,esf,b8zs
fxoks=73-96

chan_dahdi.conf looks like this:

[channels]
; 1st PRI
context = incoming
switchtype = national
signalling = pri_cpe
facilityenable = no
callwaiting = no
threewaycalling = no
cancallforward = no
echocancel = no
echocancelwhenbridged = no
callprogress = no
busydetect = no
priindication=outofband
resetinterval=never
group = 1
channel => 1-23
; 2nd PRI
context = incoming
switchtype = national
signalling = pri_cpe
facilityenable = no
callwaiting = no
threewaycalling = no
cancallforward = no
echocancel = no
echocancelwhenbridged = no
callprogress = no
busydetect = no
priindication=outofband
resetinterval=never
group = 1
channel => 25-47
; RBS T1 connection
group = 3
usecallerid = yes
hidecallerid = no
context = outgoing
signalling=fxo_ks
channel => 49-72

The relevant portion of the dialplan looks like this:
exten => _NXXNXXXXXX,23,Set(CALLERID(all)=${EXTEN} <${CALLERID(num)}>)
exten => _NXXNXXXXXX,24,Set(CALLERID(name)=${EXTEN})
; NoOps have been tested here to show CALLERID(name), CALLERID(num), CALLERID(all) and
; CALLERID(number). All are present and appear to be set correctly.
exten => _NXXNXXXXXX,25,Dial(DAHDI/${RG}/${EXTEN},30)

Where ${RG} is being set by an AGI script that dynamically determines the channel to dial (a number in the range of 49-72). As I said, the calls do come in to the proper device attached to the Adit 600’s FXS card, it’s just that no Caller ID information is passed. We’ve also tried the ‘o’ and ‘f’ options on the Dial() without any effect as well as removing ${EXTEN} from the Dial() - I.e.: Dial(DAHDI/{$RG},30).

In terms of the dahdi side, we’ve tried a number of different configurations and fxoks vs fxols signalling with no apparent impact on the issue as well.

The support folks at iQor (who support the Adit) are stumped … their only suggestion was to play with rxgain/txgain and impedance settings.

Any help would be appreciated.

Thanks!

For those who may be interested, we figured out (after recording audio with dahdi_monitor) that the timing between the end of the first ring and the cid spill appeared to be noticeably shorter when generated by asterisk than it is when listening to a telco phone line. We tested with just a regular caller id handset phone connected to the same equipment, and it didn’t work either. So, this appears to just be broken against FXS lines connected to the Adit 600 (at least in the Adit’s default config).

We found a modification that had been made to callerid.c for a 500ms pause prior to the cid spill in the callerid_generate() function (to fix something for Rhino channel banks, apparently). Changing that to a full second resolved our issue.

diff callerid.c callerid.c.dist
895,896c895,896
< /* Wait a full second */
< for (x = 0; x < 8000; x++)

          /* Wait a half a second */
          for (x = 0; x < 4000; x++)

Perhaps there was a better way to do this (custom ring cadence or something to put the cid spill where we need it from a timing perspective), but we had no luck with any other approach.

Hope someone finds this useful … lots of beating-head-against-wall involved in figuring it out!