Exactly what I was about to say Steve.  The numbers won't change. They are configured when the driver actually detects the E1 card and it's spans.  If a span goes down it doesn't disappear. Turning off the meridian would be the same as an E1 that's connected to a carrier going down.  If the channel numbers changed and everything stopped working every time that happened, no one would be using asterisk.  Our carrier friends are hardly 100% reliable.

I'm going with clock source.  I have a feeling that it was using span 4 for clocking and when it lost that, it broke everything...

Jamie


On Wed, 2005-06-15 at 21:32 +0100, Steve Hanselman wrote:
I doubt they do, if they are marked as being there, but happen to be down then the numbers would stay the same.
Sounds more likely that something happened with the clock source.
 
You'd need to reproduce it out of hours and look at the output of pri show span x and cat /proc/zaptel/*
 


________________________________

From: [EMAIL PROTECTED] on behalf of Rich Adamson
Sent: Wed 15/06/2005 5:01
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Nasty little incident ...



> >>We have a te410p, with the following connections:
> >>
> >>span 1 connected to a 32 Channel EuroISDN
> >>span 2 connected to a card in a legacy pbx (Meridian)
> >>span 3 connected to a 10 Channel EuroISDN
> >>span 4 connected to a card in a legacy pbx (Meridian)
> >>
> >>We have no need for the meridian now, and decided to turn it off. I did
> >>not change the zaptel.conf settings, nor the zapata.conf settings.
> >>
> >>When the meridian was turned off, * would no longer allow any outbound
> >>or inbound calls through spans 1 and 3 (although these are connected to
> >>the pstn). When I turned the meridian back on - in a hurry I might add
> >>;) (had no time to play with configurations) and restarted *, then
> >>everything was ok again ...
> >>
> >>Should I comment out span 2 and 4, run a ztcfg, unplug the cables in 2
> >>and 4, and then turn off the meridian ?
> >>
> >>Julian.
> >>
> >>/* zaptel.conf */
> >>
> >>span=1,1,0,ccs,hdb3,crc4
> >>bchan=1-15,17-31
> >>dchan=16
> >>
> >>span=2,0,0,ccs,hdb3,crc4
> >>bchan=32-46,48-62
> >>dchan=47
> >>
> >>span=3,2,0,ccs,hdb3,crc4
> >>bchan=63-77,79-93
> >>dchan=78
> >>
> >>span=4,0,0,ccs,hdb3,crc4
> >>bchan=94-108,110-124
> >>dchan=109
> >>
> >>loadzone=uk
> >>defaultzone=uk
> >>   
> >>
> >
> >Just a wild guess....
> >
> >When the two meridian links disappeared, the channel numbers
> >probably changed. Instead of channels 1 through 124, you probably
> >have channels 1 through 62 and your supporting dialplan (and other
> >channel specific items) likely don't match.
> > 
> >
>
> I thought that the definitions in the zaptel.conf and zapata.conf (see
> below) defined the channel numbers, not the physical channels themselves
> ? I use Dial(zap/g3) to call on the zap channels.
>
> /* zapata.conf */
>
> context=isdn32-b
> prilocaldialplan=national
> internationalprefix = 00
> nationalprefix = 0
> localprefix = 01702
> group=1
> signalling=pri_cpe
> switchtype=euroisdn
> channel=1-15,17-31
>
> context=meridian-b
> group=2
> signalling=pri_net
> switchtype=euroisdn
> channel=32-46,48-62
>
> context=isdn32-a
> pridialplan=unknown
> group=3
> signalling=pri_cpe
> switchtype=euroisdn
> channel=63-77,79-93
>
> context=meridian-a
> group=4
> signalling=pri_net
> switchtype=euroisdn
> channel=94-108,110-124

I'm sure there are others on this list that can add to this, but
when the card drivers are loaded and ztfg run, the channels that
are discovered have to be mapped to what's in zaptel.conf one way or
another. (Moving card driver load around changes the discovered
order and one must manually modify zaptel.conf to match.)

Then each zap channel is defined in zapata.conf, and those definitions
have to match the channel numbers resulting from the above zaptel.conf
stuff.

So, what happens when two E1s disappear? Do the avaiable channel
numbers change at the zaptel.conf level? My best guess is they do,
but I don't have E1s around to play with to prove it. So, that's
my best guess and it certainly can be an incorrect guess on my
part.


_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users




The information contained in this email is intended for the personal and confidential use
of the addressee only. It may also be privileged information. If you are not the intended
recipient then you are hereby notified that you have received this document in error and
that any review, distribution or copying of this document is strictly prohibited. If you have 
received  this communication in error, please notify Brendata immediately on: 

+44 (0)1268 466100, or email '[EMAIL PROTECTED]' 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk
_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
--
Jamie Carl <[EMAIL PROTECTED]>
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to