[asterisk-users] Xorcom PRI
Leonid Fainshtein
leonid.fainshtein at xorcom.com
Thu Nov 15 03:10:00 CST 2018
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 <asterisk-users-request at lists.digium.com>
wrote:
> Send asterisk-users mailing list submissions to
> asterisk-users at lists.digium.com
>
> 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
> asterisk-users-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-users-owner at lists.digium.com
>
> 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 <jeff at stratustalk.com>
> To: asterisk-users at lists.digium.com
> Subject: [asterisk-users] Xorcom PRI
> Message-ID: <14920cf8-2c8d-0d40-f2b7-cf207ad25dee at stratustalk.com>
> 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 at 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 at 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 at 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 at astbeach:/etc/dahdi# egrep -v '^#' xpp.conf
> pri_protocol T1
>
> ----------------------------------------------------------------------
>
> root at 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" <sebastian at sebbe.eu>
> To: <asterisk-users at lists.digium.com>
> Subject: [asterisk-users] Detect missed call in extensions?
> Message-ID: <001c01d47ad0$3152c040$93f840c0$@sebbe.eu>
> 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 <stotaro at totarotechnologies.com>
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-users at lists.digium.com>
> Subject: Re: [asterisk-users] Xorcom PRI
> Message-ID:
> <CAGA-L+UTRV-zVgB-KPzuxvSUoAzj1NnT-TGxZCbnHLFyjO3p=
> w at mail.gmail.com>
> 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 <jeff at stratustalk.com>
> 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 at 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 at 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 at 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 at astbeach:/etc/dahdi# egrep -v '^#' xpp.conf
> > pri_protocol T1
> >
> > ----------------------------------------------------------------------
> >
> > root at 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
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20181115/fdbd1e46/attachment-0001.html>
More information about the asterisk-users
mailing list