Ernie Dunbar
2012-May-15 17:58 UTC
[asterisk-users] Difference between Asterisk/libPRI/DAHDI versions breaks Caller ID?
Hi List! We have two Asterisk servers connected to a PRI, an old one and a new one. The old server (voip1 let's call it) is running Asterisk 1.4.23, libpri 1.4.9, and DAHDI 2.1.0.4. The new server (voip2) is running Asterisk 1.8.6, libpri 1.4.2 and DAHDI 2.4.0. We've had serious, show-stopping stability issues with any previous version of Asterisk 1.8, and we're very leery about changing to any other version now that we've found one that works. Voip1 used to be our live SIP hosting server, and while we were migrating to the new Asterisk server, the old server continued to accept calls on the PRI and forwarded those calls to the new server to minimize disruption to service. Since our intention was to move the new server to the PRI when the migration was fully completed, we set up Voip1 as a PRI bridge - one port on the PRI card was used for connecting directly to the PRI, and another port was set up as an exact copy of our PSTN provider's PRI (our configuration below will show this), and we connected this from Voip1 to Voip2. Incoming DIDs would have a dialplan on Voip1 that accepted the call and then immediately called the same DID on Voip2, like this: exten => 6041234567,1,Dial(DAHDI/g4/6041234567) exten => 6041234567,n,Macro(handle-hangup,hc-16) This worked flawlessly. All of our DIDs were migrated to Voip2 and everything was ironed out over time. The problem is, that apparently the PRI between Voip1 and Voip2 is not exactly the same as the PRI from our PSTN provider. I should have been able to simply unplug Voip1 and plug the PRI directly into Voip2 without any issues whatsoever, but instead we found the following: 1. Incoming calls worked fine for two-way voice, but any call coming through the PRI would show "Anonymous" for the caller ID name and number. This was in spite of the fact that first, this did not happen when the PRI went through Voip1, and second, after setting up the dialplan on our inbound context to display the Caller ID name and number on the Asterisk console, I could see the name and number as it was supposed to be displayed. 2. After googling for this issue, I found this page: http://forums.asterisk.org/viewtopic.php?p=166952 which described a solution to change sip.conf to enable trustrpid and sendrpid globally. This fixed the problem somewhat, but many of our customers ceased to be able to make outbound calls because their ATAs were now sending either a MAC address as their caller ID name and number, or their SIP usernames as the caller ID name and number. Something somewhere wouldn't allow outbound calling as a result, but I think the main problem is that we would trust and/or send the RPID not just to the SIP phones, but also *from* the SIP phones. We should be able to set the caller ID name and number on the server, rather than trust the client. Either way, these settings weren't interfering when the equipment on the other side of the PRI was an Asterisk box, so I don't understand why Asterisk's behaviour had changed at all. Okay, finally, I have the DAHDI configuration for both servers, to show how the PRI was set up: Voip1: [channels] usecallerid=yes cidsignalling=bell ; This one causes problems with Bell telephone numbers, or something. cidstart=polarity ; The default is "ring" ; cidstart=ring facilityenable=yes hidecallerid=no callwaitingcallerid=yes callwaiting=no threewaycalling=yes transfer=yes echocancel=yes ;echotraining=yes echocancelwhenbridged=no immediate=no ; PRI group 1: group=1 signalling=pri_cpe switchtype=national pridialplan=unknown relaxdtmf=yes context=local channel=>1-23 rxgain=0 txgain=0 busydetect=yes busycount=5 resetinterval=3600 #include dahdi-channels.conf FILE dahdi-channels.conf: ; Autogenerated by /usr/sbin/dahdi_genconf on Mon Jul 26 22:53:04 2010 -- do not hand edit ; Dahdi Channels Configurations (chan_dahdi.conf) ; ; This is not intended to be a complete chan_dahdi.conf. Rather, it is intended ; to be #include-d by /etc/asterisk/chan_dahdi.conf that will include the global settings ; ; Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" (MASTER) ;group=0,11 ;context=from-pstn ;switchtype = national ;signalling = pri_cpe ;channel => 1-23 ;context = default ;group = 63 ; Span 2: TE4/0/2 "T4XXP (PCI) Card 0 Span 2" ;group=0,12 ;context=from-pstn ;switchtype = national ;signalling = pri_cpe ;channel => 25-47 ;context = default ;group = 63 ;; Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" ;group=0,13 ;context=from-pstn ;switchtype = national ;signalling = pri_cpe ;channel => 49-71 ;context = default ;group = 63 ; Span 4: TE4/0/4 "T4XXP (PCI) Card 0 Span 4" group=4 context=default switchtype = national signalling = pri_net channel => 73-95 context = default group = 63 FILE /etc/dahdi/system.conf # Autogenerated by /usr/sbin/dahdi_genconf on Mon Jul 26 22:53:04 2010 -- do not hand edit # Dahdi Configuration File # # This file is parsed by the Dahdi Configurator, dahdi_cfg # # Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" (MASTER) span=1,1,0,esf,b8zs # termtype: te bchan=1-23 dchan=24 echocanceller=mg2,1-23 # Span 2: TE4/0/2 "T4XXP (PCI) Card 0 Span 2" span=2,2,0,esf,b8zs # termtype: te bchan=25-47 dchan=48 echocanceller=mg2,25-47 # Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" span=3,3,0,esf,b8zs # termtype: te bchan=49-71 dchan=72 echocanceller=mg2,49-71 # Span 4: TE4/0/4 "T4XXP (PCI) Card 0 Span 4" span=4,0,0,esf,b8zs # termtype: te bchan=73-95 dchan=96 echocanceller=mg2,73-95 # Global data loadzone = us defaultzone = us Voip2: FILE /etc/asterisk/chan_dahdi.conf: [channels] usecallerid=yes cidsignalling=bell ; This one causes problems with Bell telephone numbers, or something. cidstart=polarity ; The default is "ring" ; cidstart=ring facilityenable=yes hidecallerid=no callwaitingcallerid=yes callwaiting=no threewaycalling=yes transfer=yes echocancel=yes ;echotraining=yes echocancelwhenbridged=no immediate=no group=1 signalling=pri_cpe ; Switching to National at the end of May 2010 switchtype=national ; switchtype=5ess ;context=incoming ; Added Mar 13, 2012 ; Don't use this. It breaks incoming faxes. ; relaxdtmf=yes context=local channel=>1-23 dchannel=>24 ;channel=25-47,49-71,73-95 rxgain=0 txgain=0 busydetect=yes busycount=5 resetinterval=1800 FILE /etc/dahdi/system.conf: # Autogenerated by /usr/sbin/dahdi_genconf on Thu May 10 12:58:48 2012 # If you edit this file and execute /usr/sbin/dahdi_genconf again, # your manual changes will be LOST. # Dahdi Configuration File # # This file is parsed by the Dahdi Configurator, dahdi_cfg # # Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" (MASTER) B8ZS/ESF span=1,1,0,esf,b8zs # termtype: te bchan=1-23 dchan=24 echocanceller=mg2,1-23 # Span 2: TE4/0/2 "T4XXP (PCI) Card 0 Span 2" span=2,2,0,esf,b8zs # termtype: te bchan=25-47 dchan=48 echocanceller=mg2,25-47 # Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" span=3,3,0,esf,b8zs # termtype: te bchan=49-71 dchan=72 echocanceller=mg2,49-71 # Span 4: TE4/0/4 "T4XXP (PCI) Card 0 Span 4" span=4,4,0,esf,b8zs # termtype: te bchan=73-95 dchan=96 echocanceller=mg2,73-95 # Global data loadzone = us defaultzone = us