[asterisk-users] UK BT ISDN30e PRI Problem

[Mike Hardman]

Ok it's all fixed! A silly mistake in my zaptel.conf meant that
packets destined for the foneBridge device were leaving the wrong
interface... So although I could confirm that I was recieving packets
from the fonebridge and everything appeared "green", any packets
destined for the device were never getting there; as a result even
though my server was responding to the "SABME" request with an
appropriate Unnumbered Acknowledgement... it was never getting to the
telco... I'm kicking myself at how simple this show stopper turned out
to be... It's incredibly obvious now looking back :-/

I'm happy to say that the guys from redfone were incredibly helpful
every step of the way, without Jose explanations and tips I would
probably still be scratching my head...

Hope this helps another poor soul in my situation out in the future.

Mike

On Wed, May 7, 2008 at 2:12 PM, Mike Hardman
<mike.hardman.work at googlemail.com> wrote:
> So a quick update on this since I haven't had any feedback... I've
> just grabbed the latest trunk from the digium subversion repo; I've
> completely cleaned out the asterisk server and rebuilt from scratch
> with CentOS 5, all pre-reqs have been yum installed and the whole box
> has been yum update'd.
>
> I've built the latest trunk of libpri with no errors... I grabbed a
> copy of the latest zaptel redfone source and copied the ztd-ethmf.c
> from there into the appropriate source dir in the zaptel code I got
> from digium... I added the module to the makefile and then built and
> installed it. This again went without issue...
>
> I have just built and installed the asterisk trunk I got from the
> digium svn, and I have just ftp'd all the config files I had altered
> back onto the server, so sip.conf, iax.conf, extensions.conf, etc; are
> all exactly the same as they were before... I am waiting until out of
> hours tonight >6pm GMT to test to see if these versions on libpri,
> zaptel and asterisk fix the issues; and I will update the list to
> reflect either my success or failure :/
>
> Thanks guys
>
> Mike
>
> On 5/4/08, Mike Hardman <mike.hardman.work at googlemail.com> wrote:
>> Ok Guys, I've done a tonne of hunting around on this problem, but
>> can't find much help.
>>
>> I'm running:
>> asterisk 1.4.19.1
>> libpri 1.4.3
>> and zaptel 1.4.9.2 which I believe has been modified by RedFone to add
>> the ztd-ethmf module.
>>
>> My interface is a RedFone foneBridge2 4 Span; and I'm connecting to a
>> BT E1 PRI / ISDN30e with 15 lines on span 1, and a legacy Panasonic
>> PBX on span 4. Upon connection of the E1 I get the following in pri
>> debug span 1:
>>
>>
>> Sending Unnumbered Acknowledgement
>> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
>> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
>> -- Got SABME from network peer.
>> Sending Unnumbered Acknowledgement
>> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
>> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
>> -- Got SABME from network peer.
>> Sending Unnumbered Acknowledgement
>> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
>> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
>> -- Got SABME from network peer.
>> Sending Unnumbered Acknowledgement
>> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
>> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
>> -- Got SABME from network peer.
>> Sending Unnumbered Acknowledgement
>> q921.c:709 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
>> q921.c:664 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
>>
>> Now I'm sure that this line is q931 and not 921, but I cant seem to
>> find where I configure this... My configs are as follows:
>>
>> Zaptel.conf:
>>
>> dynamic=ethmf,eth0/00:50:C2:65:D1:DC/0,31,1
>> dynamic=ethmf,eth0/00:50:C2:65:D1:DC/1,31,0
>> dynamic=ethmf,eth0/00:50:C2:65:D1:DC/2,31,0
>> dynamic=ethmf,eth0/00:50:C2:65:D1:DC/3,31,0
>> #
>> bchan=1-15,17-31
>> dchan=16
>> bchan=32-46,48-62
>> dchan=47
>> bchan=63-77,79-93
>> dchan=78
>> bchan=94-108,110-124
>> dchan=109
>>
>> # NOTE: Most E1 use alaw codec and this must be specified.
>> alaw=1-124
>> #
>>
>>
>> # Global data
>>
>> loadzone = uk
>> defaultzone = uk
>>
>> Redfone.conf:
>> [globals]
>> fb=192.168.1.254
>> port=1
>> server=00:0F:B5:8D:CB:95
>>
>> [span1]
>> framing=ccs
>> encoding=hdb3
>> slave
>>
>> [span2]
>> framing=ccs
>> encoding=hdb3
>> master
>>
>> [span3]
>> framing=ccs
>> encoding=hdb3
>> master
>>
>> [span4]
>> framing=ccs
>> encoding=hdb3
>> master
>>
>> zapata.conf:
>> [trunkgroups]
>>
>> [channels]
>>
>> language=en
>> xwink=300
>> usecallerid=yes
>> hidecallerid=no
>> callwaiting=yes
>> usecallingpres=yes
>> callwaitingcallerid=yes
>> threewaycalling=yes
>> transfer=yes
>> cancallforward=yes
>> callreturn=yes
>> echocancel=yes
>> echocancelwhenbridged=no
>> ;echotraining=800
>> rxgain=0.0
>> txgain=0.0
>> callgroup=1
>> pickupgroup=1
>> immediate=no
>>
>>
>> context=from-panasonic
>> group=0
>> switchtype=euroisdn
>> signalling=pri_net
>> channel=>94-108
>> channel=>110-124
>>
>> context=from-zaptel
>> signalling=pri_cpe
>> group=1
>> channel=>1-15
>> channel=>17-31
>>
>>
>> I should note that I have tried this with and without crc4 on the
>> spans; both with identical results. Could anybody shed any light on
>> this or point me in the right direction? I'm now not sure what I'm
>> missing or where to go looking for it?
>>
>> Thanks guys and gals.
>>
>> Mike
>>
>