Steve, Try to uncomment "dchan=24" and remove "hardhdlc=24" in the /etc/dahdi/system.conf
Best regards, Leonid On Tue, Nov 13, 2018 at 8:01 PM <[email protected]> wrote: > Send asterisk-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.digium.com/mailman/listinfo/asterisk-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of asterisk-users digest..." > > > Today's Topics: > > 1. Xorcom PRI (Jeff LaCoursiere) > 2. Detect missed call in extensions? (Sebastian Nielsen) > 3. Re: Xorcom PRI (Steve Totaro) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Nov 2018 13:42:54 -0600 > From: Jeff LaCoursiere <[email protected]> > To: [email protected] > Subject: [asterisk-users] Xorcom PRI > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > 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# egrep -v '^;' chan_dahdi.conf > > [trunkgroups] > > [channels] > > switchtype = national > context=from-pstn > signalling = pri_cpe > callwaiting=yes > usecallingpres=yes > callwaitingcallerid=yes > threewaycalling=no > transfer=no > canpark=no > cancallforward=no > callreturn=no > echocancel=yes > echocancelwhenbridged=yes > group=0 > callgroup=1 > pickupgroup=1 > channel => 1-23 > > Thanks for any debugging advice! > > Cheers, > > j > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.digium.com/pipermail/asterisk-users/attachments/20181112/7b4d8eeb/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 12 Nov 2018 22:39:28 +0100 > From: "Sebastian Nielsen" <[email protected]> > To: <[email protected]> > Subject: [asterisk-users] Detect missed call in extensions? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.digium.com/pipermail/asterisk-users/attachments/20181112/4450e232/attachment-0001.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 5261 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://lists.digium.com/pipermail/asterisk-users/attachments/20181112/4450e232/attachment-0001.bin > > > > ------------------------------ > > Message: 3 > Date: Mon, 12 Nov 2018 21:22:06 -0500 > From: Steve Totaro <[email protected]> > To: Asterisk Users Mailing List - Non-Commercial Discussion > <[email protected]> > Subject: Re: [asterisk-users] Xorcom PRI > Message-ID: > <CAGA-L+UTRV-zVgB-KPzuxvSUoAzj1NnT-TGxZCbnHLFyjO3p= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Turn on PRI debugging and double check your cable. > > On Mon, Nov 12, 2018 at 3:24 PM Jeff LaCoursiere <[email protected]> > 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 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# egrep -v '^;' chan_dahdi.conf > > > > [trunkgroups] > > > > [channels] > > > > switchtype = national > > context=from-pstn > > signalling = pri_cpe > > callwaiting=yes > > usecallingpres=yes > > callwaitingcallerid=yes > > threewaycalling=no > > transfer=no > > canpark=no > > cancallforward=no > > callreturn=no > > echocancel=yes > > echocancelwhenbridged=yes > > group=0 > > callgroup=1 > > pickupgroup=1 > > channel => 1-23 > > > > Thanks for any debugging advice! > > > > Cheers, > > > > j > > -- > > _____________________________________________________________________ > > -- 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.digium.com/pipermail/asterisk-users/attachments/20181112/d8969ba9/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > 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 > > ------------------------------ > > End of asterisk-users Digest, Vol 171, Issue 7 > ********************************************** >
-- _____________________________________________________________________ -- 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
