asterisk users - Feb 2008 - Connecting a Rolm CBX to Asterisk via T1?

Hi all,

So I'm trying to work on this complex fax server setup, and part of it
involves connecting my asterisk server to my Rolm CBX switch, via a T1 line.  I
plan on using Asterisk simply as a T1-PRI Bridge to IAXmodem (which in turn,
activates HylaFax+ to handle the faxing).  So far, though, I don't think
I'm getting 100% of the way there.  When dialing the fax extension from my
Rolm phone, I get several seconds of silence followed by error tone.  But on
asterisk's CLI, I see this:

    -- Starting simple switch on 'Zap/2-1'
    -- Starting simple switch on 'Zap/3-1'
    -- Starting simple switch on 'Zap/4-1'
    -- Starting simple switch on 'Zap/1-1'
    -- Executing [s at fax-in:1] Dial("Zap/2-1",
"IAX2/iaxmodem0/s|10|r") in new stack
    -- Called iaxmodem0/s
    -- Call accepted by 127.0.0.1 (format ulaw)
    -- Format for call is ulaw
    -- IAX2/iaxmodem0-5 is ringing
    -- IAX2/iaxmodem0-5 answered Zap/2-1
    -- Executing [s at fax-in:1] Dial("Zap/3-1",
"IAX2/iaxmodem0/s|10|r") in new stack
    -- Called iaxmodem0/s
[Feb 15 15:40:22] WARNING[24329]: chan_iax2.c:7542 socket_process: Call rejected
by 127.0.0.1: Busy
    -- Hungup 'IAX2/iaxmodem0-1'
  == Everyone is busy/congested at this time (1:0/0/1)
  == Auto fallthrough, channel 'Zap/3-1' status is 'CHANUNAVAIL'
    -- Executing [s at fax-in:1] Dial("Zap/4-1",
"IAX2/iaxmodem0/s|10|r") in new stack
    -- Called iaxmodem0/s
[Feb 15 15:40:30] WARNING[24327]: chan_iax2.c:7542 socket_process: Call rejected
by 127.0.0.1: Busy
    -- Hungup 'IAX2/iaxmodem0-3'
  == Everyone is busy/congested at this time (1:0/0/1)
  == Auto fallthrough, channel 'Zap/4-1' status is 'CHANUNAVAIL'
    -- Hungup 'Zap/3-1'
    -- Executing [s at fax-in:1] Dial("Zap/1-1",
"IAX2/iaxmodem0/s|10|r") in new stack
    -- Called iaxmodem0/s
[Feb 15 15:40:35] WARNING[24327]: chan_iax2.c:7542 socket_process: Call rejected
by 127.0.0.1: Busy
    -- Hungup 'IAX2/iaxmodem0-4'
  == Everyone is busy/congested at this time (1:0/0/1)
  == Auto fallthrough, channel 'Zap/1-1' status is 'CHANUNAVAIL'
    -- Hungup 'Zap/4-1'


The Rolm gives me error tone just before the "Starting simple switch"
messages begin to appear, so it's almost like the Rolm is not waiting around
long enough for the asterisk server to answer, before it jumps to the next
configured T1 channel, runs out of channels (I only configured four in the Rolm
and on asterisk).


Here's my configuration for asterisk.  Is anything amiss by chance?

Standard T1
Signalling is E&M Wink, 200ms wink time (as far as I can tell)
Mode is ESF and format is B8ZS

/etc/zaptel.conf is:
span=1,1,0,esf,b8zs
e&m=1-4
loadzone = us
defaultzone=us


/etc/asterisk/zapata.conf is:
[trunkgroups]

[channels]
language=en
context=default
switchtype=national
signalling=em_w
wink=200
channel => 1-4
usecallerid=yes
callerid=asreceived
cidsignalling=bell
hidecallerid=no
callwaiting=no
usecallingpres=yes
callwaitingcallerid=no
threewaycalling=no
transfer=no
canpark=no
cancallforward=no
callreturn=no
echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=0.0
txgain=0.0
group=0
busydetect=yes
busycount=6
faxdetect=incoming


/etc/asterisk/extensions.conf is:
[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]
CONSOLE=Console/dsp                             ; Console interface for demo
TRUNK=Zap/g0                                    ; Trunk interface
TRUNKMSD=1                                      ; MSD digits to strip (usually 1
or 0)

[fax-in]
exten => s,1,Dial(IAX2/iaxmodem0/${EXTEN},10,r)


Thoughts?

Thanks!,

--Josh

Joshua Kinard wrote:
> So I'm trying to work on this complex fax server setup, and part of it
involves connecting my asterisk server to my Rolm CBX switch, via a T1 line.  I
plan on using Asterisk simply as a T1-PRI Bridge to IAXmodem (which in turn,
activates HylaFax+ to handle the faxing).  So far, though, I don't think
I'm getting 100% of the way there.  When dialing the fax extension from my
Rolm phone, I get several seconds of silence followed by error tone.  But on
asterisk's CLI, I see this:
>
>     -- Starting simple switch on 'Zap/2-1'
>     -- Starting simple switch on 'Zap/3-1'
>     -- Starting simple switch on 'Zap/4-1'
>     -- Starting simple switch on 'Zap/1-1'
>   
So, okay, there are four calls coming in on the Zap (strange, but...)
>     -- Executing [s at fax-in:1] Dial("Zap/2-1",
"IAX2/iaxmodem0/s|10|r") in new stack
>     -- Called iaxmodem0/s
>     -- Call accepted by 127.0.0.1 (format ulaw)
>     -- Format for call is ulaw
>     -- IAX2/iaxmodem0-5 is ringing
>     -- IAX2/iaxmodem0-5 answered Zap/2-1
>   
iaxmodem0 correctly takes the first call...
>     -- Executing [s at fax-in:1] Dial("Zap/3-1",
"IAX2/iaxmodem0/s|10|r") in new stack
>     -- Called iaxmodem0/s
> [Feb 15 15:40:22] WARNING[24329]: chan_iax2.c:7542 socket_process: Call
rejected by 127.0.0.1: Busy
>     -- Hungup 'IAX2/iaxmodem0-1'
>   == Everyone is busy/congested at this time (1:0/0/1)
>   == Auto fallthrough, channel 'Zap/3-1' status is
'CHANUNAVAIL'
>     -- Executing [s at fax-in:1] Dial("Zap/4-1",
"IAX2/iaxmodem0/s|10|r") in new stack
>     -- Called iaxmodem0/s
> [Feb 15 15:40:30] WARNING[24327]: chan_iax2.c:7542 socket_process: Call
rejected by 127.0.0.1: Busy
>     -- Hungup 'IAX2/iaxmodem0-3'
>   == Everyone is busy/congested at this time (1:0/0/1)
>   == Auto fallthrough, channel 'Zap/4-1' status is
'CHANUNAVAIL'
>     -- Hungup 'Zap/3-1'
>     -- Executing [s at fax-in:1] Dial("Zap/1-1",
"IAX2/iaxmodem0/s|10|r") in new stack
>     -- Called iaxmodem0/s
> [Feb 15 15:40:35] WARNING[24327]: chan_iax2.c:7542 socket_process: Call
rejected by 127.0.0.1: Busy
>     -- Hungup 'IAX2/iaxmodem0-4'
>   == Everyone is busy/congested at this time (1:0/0/1)
>   == Auto fallthrough, channel 'Zap/1-1' status is
'CHANUNAVAIL'
>     -- Hungup 'Zap/4-1'
>   
And the other calls get busy and improperly run through the auto 
fallthrough process (you *need* a Hangup in your dialplan fax-in context).
> The Rolm gives me error tone just before the "Starting simple
switch" messages begin to appear, so it's almost like the Rolm is not
waiting around long enough for the asterisk server to answer, before it jumps to
the next configured T1 channel, runs out of channels (I only configured four in
the Rolm and on asterisk).
>   
I think that your zaptel/zapata configuration between the Rolm and 
Asterisk on that T1 is misconfigured.  Set it up for PRI if you can... 
it'll be a lot easier, is my guess.

Thanks,

Lee.

-----Original Message-----
From: Lee Howard 
> So, okay, there are four calls coming in on the Zap (strange, but...)
There's definitely some kind of a timing error here.  I cut my channels back
down to 1, as the Rolm isn't waiting long enough for an answer back from the
asterisk server, and it gives up too early with a busy tone now.  What I'm
seeing is the asterisk server taking too long to respond in kind, only to find
the Rolm's quit and gone home already.

Also, asterisk seems to have signalling=em and signalling=em_w mixed up, as I
have to use signalling=em to see a wink sent back down to my Rolm.  em_w does
nothing.

An attached text file (rolm-asterisk-chatter.txt) is what my Rolm is seeing. 
Notes on each line are on the right and are my additions.

Another attached text file shows what iaxmodem is doing during all of this. 
Something about adjusting skew.


Here's what Asterisk itself sees (appears long after the Rolm went to busy
tone):

    -- Starting simple switch on 'Zap/1-1'
    -- Executing [s at fax-in:1] Dial("Zap/1-1",
"IAX2/iaxmodem0/s") in new stack
    -- Called iaxmodem0/s
    -- Call accepted by 127.0.0.1 (format ulaw)
    -- Format for call is ulaw
    -- IAX2/iaxmodem0-3 is ringing
    -- IAX2/iaxmodem0-3 answered Zap/1-1
    -- Hungup 'IAX2/iaxmodem0-3'
  == Spawn extension (fax-in, s, 1) exited non-zero on 'Zap/1-1'
    -- Hungup 'Zap/1-1'

 
> And the other calls get busy and improperly run through the auto 
> fallthrough process (you *need* a Hangup in your dialplan fax-in context).
Added, how does this look?

exten => s,1,Dial(IAX2/iaxmodem0/${EXTEN})
exten => s,2,Busy
exten => s,3,Hangup

> I think that your zaptel/zapata configuration between the Rolm and 
> Asterisk on that T1 is misconfigured.  Set it up for PRI if you can... 
> it'll be a lot easier, is my guess.
Unfortunately, the Rolm only speaks plain T1 talk.  It's too old for PRI. 
We have an Adtran Atlas unit infront of it that does the PRI->T1 translation
that we get from our carrier, but to get another card for the Adtran is more
than I'll be able to weasel out of my manager for now.

Cheers!,

--Josh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rolm-asterisk-chatter.txt
Url:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080215/b4d5296f/attachment-0002.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iaxmodem-skew.txt
Url:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080215/b4d5296f/attachment-0003.txt

Okay, so I've been toying around on the Rolm side, and still getting
nothing.  Took another look on Asterisk, finally figured out where the debugging
could be enabled on the console, and finding a lot of interesting things.

Running 'dmesg' simply shows the entire buffer is flooded with 'PCI
Master Aborts', and they appear as soon as the zaptel driver tries to do
anything in conjunction with asterisk.  Further more, there seems to be a
problem with chan_zap and the my_zt_write function, in that it gets a -1 return
code, "Resource temporarily unavailable" (which comprised the bulk of
the asterisk debugging output).

I've attached a snipped version of that output, notably removing about 2000
lines of chan_zap repeating the "Resource temporarily unavailable"
error.  Do I need to look at downgrading asterisk and zaptel to 1.2.x, or might
this be some conflict with the Proliant DL385 hardware that currently hosts the
T1 Card?

FYI, asterisk-1.4.18 and zaptel-1.4.8.


Thanks!,

--jkinard
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: asterisk-zap-debug.txt
Url:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080219/2a696a90/attachment.txt

Okay, some more interesting tidbits to throw out incase someone has run into
this before.

I've found out that th D100P has been EOL'ed by Digium due to it being a
bit weird with certain systems, and I suspect my HP Proliant DL385 server may be
one of those.  Anyone used this card on such a system, running Suse (or at
minimum, kernel 2.6.16.5x), and seen either PCI Master Aborts or NMI Errors
being fired around in dmesg?

I moved the the D110P card out of what was a 100MHz PCI Slot and into a 133MHz
PCI slot.  The PCI Master Aborts vanish, but get replaced by this:

Do you have a strange power saving mode enabled?
Uhhuh. NMI received for unknown reason 00 on CPU 1.
Uhhuh. NMI received for unknown reason 21 on CPU 0.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?

Ad infinium.

The interesting part of all of this?  The whole T1-PRI Bridge setup works now. 
I dial my test extension, and a fax modem comes screaming back at me a few
seconds later.  That timing oddity with my Rolm system vanished with moving this
to the PCI 133MHz slot I guess.  The downside is my server locked up a few times
until I passed a couple of options given to me by Digium's tech support.

I'm going to go run some hardware diagnostics on the server itself to make
sure it's not going all emo on me or something, and then see what Digium can
maybe help with.  But I thought I'd see if anyone's had similar or other
odd cases on DL385 hardware.

Cheers!,

--jkinard



-----Original Message-----

Okay, so I've been toying around on the Rolm side, and still getting
nothing.  Took another look on Asterisk, finally figured out where the debugging
could be enabled on the console, and finding a lot of interesting things.

Running 'dmesg' simply shows the entire buffer is flooded with 'PCI
Master Aborts', and they appear as soon as the zaptel driver tries to do
anything in conjunction with asterisk.  Further more, there seems to be a
problem with chan_zap and the my_zt_write function, in that it gets a -1 return
code, "Resource temporarily unavailable" (which comprised the bulk of
the asterisk debugging output).

I've attached a snipped version of that output, notably removing about 2000
lines of chan_zap repeating the "Resource temporarily unavailable"
error.  Do I need to look at downgrading asterisk and zaptel to 1.2.x, or might
this be some conflict with the Proliant DL385 hardware that currently hosts the
T1 Card?

FYI, asterisk-1.4.18 and zaptel-1.4.8.

-----Original Message-----
Joshua,
> You probably mean a T100P? The single E1/T1 card? Been a few years but I
> remember seeing the NMI Errors on a HP DL380 (the Intel dual Xeon
> model).
Nah, it's classified as a D110P, although the driver says TE110P.  And I
checked to make sure I had the onboard jumper rigged for T1 (open), not E1 mode
(closed).  There's another, unidentified jumper on the board too, but
I'm not sure what it's for.

> Seen this one. Actually now I think of it I've seen those as far back
as
> before Asterisk 0.7 with Dell servers.
>
> The DL380 & T100P (E1) setup was only used in a test for a couple of
> months and never taken into production so I don't have any recent data.
Hmm, so is it possible this card I have is a prototype that wasn't supposed
to ever make it to the market?  I've seen it in quite a few online stores.

That said, because you've also seen similar issues in a HP Proliant system
that's very similar to the DL385 G1, suggests it could be related to
something weird HP does in this class of system that this driver and card
don't seem to like very much.  I've got to run some diagnostics later
today on it to verify there's nothing bad with the hardware, but I've
also checked for BIOS updates and haven't seen anything new for this system.
And I know going through HP's support will be utterly pointless, given their
phone people barely speak English anymore.

Thanks for the info!,

--jkinard

-----Original Message-----
> The D110P is a clone card, which is *not* made/sold/endorsed/etc by
> Digium.  I would suggest getting a newer card, which would not exhibit
> these types of issues.  You will save yourself many headaches in the
future.
Ah, that would explain quite a bit...

Let me guess, Chinese knock-off?  I should've known something was a little
weird when I kept seeing a green PCI card (TE110P) versus a blue PCI card
(D110P).  But the chips and other components are all in the same exact spot in
the images I found, so I figured it was just a manufacturing curiosity.

Bah, that's $300 into the bit bucket.

Thanks for the info.  Time to go yell very loudly at the person I got this from.


Cheers,

--jkinard

Joshua Kinard wrote:
> I kept seeing a green PCI card (TE110P) versus a blue PCI card (D110P). 
But the chips and
Did you get that backwards?  All my TE110P cards are blue.  I got them 
from a reputable vendor (voipsupply.com)

Doug

-- 
 
Ben Franklin quote:

"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety."

-----Original Message-----
> Did you get that backwards?  All my TE110P cards are blue.  I got them 
> from a reputable vendor (voipsupply.com)
Yanno, it's hard to tell really.  I just took another look at Google, and
this:
http://hardware4less.net.au/images/te120p_large.png

Looks like a Digium card (The asterisk logo is visible), but it could be the
TE100P too, of which, OpenVox's ripoff version is also green.  I'm
probably seeing this card in a lot of the online stores, because even this one
looks remarkably close to the TE110P, which does appear to be blue, as is the
knockoff I have.

I knew the ripoff market was pretty bad and shameless, but until you're
actually burned by it, you don't fully realize the lengths they'll go to
rip a product off.

Really all I need is a simple 1-span T1 card.  Nothing fancy and nothing
expensive (very limited budget for this project unfortunately).  I think I might
be able to recover most of what I spent on the D110P, so I'm gonna have to
find something that's not too much more expensive (talking $300-$450 range),
and I guess, just triple check to make sure it's not another clone card :)

--jkinard