Re: [asterisk-users] Xorcom PRI
Turn on PRI debugging and double check your cable. On Mon, Nov 12, 2018 at 3:24 PM Jeff LaCoursiere wrote: > > I've been struggling for a few weeks now with the local telco trying to > bring up a trunk that has been down for a year (hurricanes in the > caribbean). Box is a Dell R710, 16G RAM, Ubuntu 14.04.5 LTS, Dahdi > 2.10.2-rc1, asterisk 13.23.1. Xorcom Astribank w/ one T1/E1/PRI module, > plugged into a USB 2.0 port on the Dell. All of this was working *before* > the storms last year with the same hardware/versions. > > Dahdi sees the astribank and loads firmware without issue: > > root@astbeach:~# dmesg | grep -i dahdi > [661368.877090] dahdi: Version: 2.10.2-rc1 > [661368.880450] dahdi: Telephony Interface Registered on major 196 > [661368.963988] dahdi_transcode: Loaded. > [661368.982746] INFO-xpp: FEATURE: with sync_tick() from DAHDI > [661369.233471] INFO-xpd_pri: FEATURE: WITHOUT DAHDI_AUDIO_NOTIFY > [661370.256053] dahdi_devices astribanks:xbus-00: local span 1 is already > assigned span 1 > [661370.270028] dahdi_echocan_mg2: Registered echo canceler 'MG2' > root@astbeach:~# lsusb > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub > Bus 001 Device 002: ID e4e4:1162 Xorcom Ltd. Astribank 2 series > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > > The dahdi drivers are loaded, and the T1 layer has no alarms... telco also > reports the line itself is "UP": > > root@astbeach:~# service dahdi status > ### Span 1: XBUS-00/XPD-00 "Xorcom XPD [usb:X1067719].1: T1" (MASTER) > ESF/B8ZS ClockSource > 1 T1 Clear (In use) (EC: MG2 - INACTIVE) > 2 T1 Clear (In use) (EC: MG2 - INACTIVE) > 3 T1 Clear (In use) (EC: MG2 - INACTIVE) > 4 T1 Clear (In use) (EC: MG2 - INACTIVE) > 5 T1 Clear (In use) (EC: MG2 - INACTIVE) > 6 T1 Clear (In use) (EC: MG2 - INACTIVE) > 7 T1 Clear (In use) (EC: MG2 - INACTIVE) > 8 T1 Clear (In use) (EC: MG2 - INACTIVE) > 9 T1 Clear (In use) (EC: MG2 - INACTIVE) > 10 T1 Clear (In use) (EC: MG2 - INACTIVE) > 11 T1 Clear (In use) (EC: MG2 - INACTIVE) > 12 T1 Clear (In use) (EC: MG2 - INACTIVE) > 13 T1 Clear (In use) (EC: MG2 - INACTIVE) > 14 T1 Clear (In use) (EC: MG2 - INACTIVE) > 15 T1 Clear (In use) (EC: MG2 - INACTIVE) > 16 T1 Clear (In use) (EC: MG2 - INACTIVE) > 17 T1 Clear (In use) (EC: MG2 - INACTIVE) > 18 T1 Clear (In use) (EC: MG2 - INACTIVE) > 19 T1 Clear (In use) (EC: MG2 - INACTIVE) > 20 T1 Clear (In use) (EC: MG2 - INACTIVE) > 21 T1 Clear (In use) (EC: MG2 - INACTIVE) > 22 T1 Clear (In use) (EC: MG2 - INACTIVE) > 23 T1 Clear (In use) (EC: MG2 - INACTIVE) > 24 T1 Hardware-assisted HDLC (In use) > > asterisk chan_dahdi shows the T1 up with no alarms: > > astbeach*CLI> dahdi show status > Description Alarms IRQbpviol CRCFra > Codi Options LBO > Xorcom XPD [usb:X1067719].1: T1 OK 0 0 0 ESF > B8ZS 0 db (CSU)/0-133 feet (DSX-1) > > but the PRI is down: > > astbeach*CLI> pri show spans > PRI span 1/0: Down, Active > > I'm not really sure where to take it from here, and the telco has even > less of a clue. They brought out some gear that they hooked up to our > cabling for the T1 and pretty quickly established a PRI, then placed and > received test calls over it. At that point they washed their hands of it, > and logged as a "CPE issue"! > > Could it be that the storms damaged the Xorcom unit in such a way that the > T1 can be up without alarms but the PRI signaling is broken? Seems > unlikely. > > I have included a few relevant config files below. Note that the cabling > wasn't in place when we ran dahdi_genconf, which is why it shows red > alarm. There is no red alarm now. > > /etc/dahdi/system.conf: > # Autogenerated by /usr/sbin/dahdi_genconf on Fri Oct 12 11:34:27 2018 > # 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: XBUS-00/XPD-00 "Xorcom XPD [usb:X1067719].1: T1" (MASTER) RED > span=1,1,0,esf,b8zs > # termtype: te > bchan=1-23 > #dchan=24 > echocanceller=mg2,1-23 > hardhdlc=24 > > # Global data > > loadzone= us > defaultzone= us > > --
[asterisk-users] Detect missed call in extensions?
How I do to detect missed calls? After Dial() has been executed, theres 3 ways a call could end up in: 1: The callee answers, and a communication is going on. Then one party hangs up, and thus execution goes to the h extension. 2: The callee newer answers or there was some error, the Dial() fails, and execution continues on next line in extensions. 3: The caller hangs up before callee have answered, and execution goes to the h extension. Now to the problem. I want to detect if callee did answer or not (in separate 1 and 3) so I could determite if a missed call should be logged to a missedcall.txt log file. (call should be logged in 3 case, but not in 1 case) 2 is easy to detect, as these always are failed (non-answered) calls. Best regards, Sebastian Nielsen smime.p7s Description: S/MIME Cryptographic Signature -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Xorcom PRI
I've been struggling for a few weeks now with the local telco trying to bring up a trunk that has been down for a year (hurricanes in the caribbean). Box is a Dell R710, 16G RAM, Ubuntu 14.04.5 LTS, Dahdi 2.10.2-rc1, asterisk 13.23.1. Xorcom Astribank w/ one T1/E1/PRI module, plugged into a USB 2.0 port on the Dell. All of this was working *before* the storms last year with the same hardware/versions. Dahdi sees the astribank and loads firmware without issue: root@astbeach:~# dmesg | grep -i dahdi [661368.877090] dahdi: Version: 2.10.2-rc1 [661368.880450] dahdi: Telephony Interface Registered on major 196 [661368.963988] dahdi_transcode: Loaded. [661368.982746] INFO-xpp: FEATURE: with sync_tick() from DAHDI [661369.233471] INFO-xpd_pri: FEATURE: WITHOUT DAHDI_AUDIO_NOTIFY [661370.256053] dahdi_devices astribanks:xbus-00: local span 1 is already assigned span 1 [661370.270028] dahdi_echocan_mg2: Registered echo canceler 'MG2' root@astbeach:~# lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 002: ID e4e4:1162 Xorcom Ltd. Astribank 2 series Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub The dahdi drivers are loaded, and the T1 layer has no alarms... telco also reports the line itself is "UP": root@astbeach:~# service dahdi status ### Span 1: XBUS-00/XPD-00 "Xorcom XPD [usb:X1067719].1: T1" (MASTER) ESF/B8ZS ClockSource 1 T1 Clear (In use) (EC: MG2 - INACTIVE) 2 T1 Clear (In use) (EC: MG2 - INACTIVE) 3 T1 Clear (In use) (EC: MG2 - INACTIVE) 4 T1 Clear (In use) (EC: MG2 - INACTIVE) 5 T1 Clear (In use) (EC: MG2 - INACTIVE) 6 T1 Clear (In use) (EC: MG2 - INACTIVE) 7 T1 Clear (In use) (EC: MG2 - INACTIVE) 8 T1 Clear (In use) (EC: MG2 - INACTIVE) 9 T1 Clear (In use) (EC: MG2 - INACTIVE) 10 T1 Clear (In use) (EC: MG2 - INACTIVE) 11 T1 Clear (In use) (EC: MG2 - INACTIVE) 12 T1 Clear (In use) (EC: MG2 - INACTIVE) 13 T1 Clear (In use) (EC: MG2 - INACTIVE) 14 T1 Clear (In use) (EC: MG2 - INACTIVE) 15 T1 Clear (In use) (EC: MG2 - INACTIVE) 16 T1 Clear (In use) (EC: MG2 - INACTIVE) 17 T1 Clear (In use) (EC: MG2 - INACTIVE) 18 T1 Clear (In use) (EC: MG2 - INACTIVE) 19 T1 Clear (In use) (EC: MG2 - INACTIVE) 20 T1 Clear (In use) (EC: MG2 - INACTIVE) 21 T1 Clear (In use) (EC: MG2 - INACTIVE) 22 T1 Clear (In use) (EC: MG2 - INACTIVE) 23 T1 Clear (In use) (EC: MG2 - INACTIVE) 24 T1 Hardware-assisted HDLC (In use) asterisk chan_dahdi shows the T1 up with no alarms: astbeach*CLI> dahdi show status Description Alarms IRQ bpviol CRC Fra Codi Options LBO Xorcom XPD [usb:X1067719].1: T1 OK 0 0 0 ESF B8ZS 0 db (CSU)/0-133 feet (DSX-1) but the PRI is down: astbeach*CLI> pri show spans PRI span 1/0: Down, Active I'm not really sure where to take it from here, and the telco has even less of a clue. They brought out some gear that they hooked up to our cabling for the T1 and pretty quickly established a PRI, then placed and received test calls over it. At that point they washed their hands of it, and logged as a "CPE issue"! Could it be that the storms damaged the Xorcom unit in such a way that the T1 can be up without alarms but the PRI signaling is broken? Seems unlikely. I have included a few relevant config files below. Note that the cabling wasn't in place when we ran dahdi_genconf, which is why it shows red alarm. There is no red alarm now. /etc/dahdi/system.conf: # Autogenerated by /usr/sbin/dahdi_genconf on Fri Oct 12 11:34:27 2018 # 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: XBUS-00/XPD-00 "Xorcom XPD [usb:X1067719].1: T1" (MASTER) RED span=1,1,0,esf,b8zs # termtype: te bchan=1-23 #dchan=24 echocanceller=mg2,1-23 hardhdlc=24 # Global data loadzone = us defaultzone = us -- root@astbeach:/etc/dahdi# egrep -v '^#' xpp.conf pri_protocol T1 -- root@astbeach:/etc/asterisk#
