Probably you should make sure that telco assigns control
channel at 16th timeslot. Seems E1 works but you don't have
Controll channel.
On 19 March 2006 01:07, ADEGOKE ARUNA wrote:
> Thank you for the help,
>
> However, When I set my settings as advised I have the
> status as not aligned with the error as stated below
>
> ss7 link status
> linkset siuc, link l1, schannel 16, NOT_ALIGNED, rx: 0,
> tx: 2/4, sentseq/lastack: 127/127, total 0,
> 64 Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20976!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20976!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20979!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20978!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20976!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20977!
> Mar 18 21:01:21 WARNING[5553]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20976!
>
> Thank you
>
>
>
> -----Original Message-----
> From: Anton [mailto:anton.vazir@xxxxxxxxx]
> Sent: Saturday, March 18, 2006 8:44 PM
> To: asterisk-ss7@xxxxxxxxxxxxxxxx
> Cc: ADEGOKE ARUNA; 'Kai Militzer'
> Subject: Re: [asterisk-ss7] my chan_ss7 status is going
> up and down
>
> ADEGOKE,
>
> Are you shure that you NEED crc4 enabled on spans? It's
> rarely used and improper settings causes E1 link to be
> down. When you get link into the operation you should
> first receive message that channels have been allocated
> from asterisk debug messages. Until then there is no SS7
> link
>
> I do use sangoma A102 - and it's working.
>
> My advice to try simple way first. Configure single SS7
> link - when you succeed with it - process furher
> configuring more links.
>
> See my working configs below, hopy it can help
>
> I have empty zapata.conf
>
> SS7.conf
>
> [linkset-siuc]
> enabled => yes
> enable_st => no
> use_connect => no
> hunting_policy => even_mru
> context => ss7
> language => en
> subservice => auto
>
> [link-l1]
> linkset => siuc
> channels => 1-15,17-31
> schannel => 16
> firstcic => 1
> enabled => yes
>
> [link-l2]
> linkset => siuc
> channels => 1-15,17-31
> schannel => 16
> firstcic => 1
> enabled => yes
>
> [host-ss7-1]
> enabled => yes
> opc => 9000
> dpc => siuc:4065
> links => l1:1
>
>
> ZAPTEL.CONF
>
> #
> # Zaptel Configuration File
> #
> # This file is parsed by the Zaptel Configurator, ztcfg
> #
> #
> # First come the span definitions, in the format
> # span=<span num>,<timing source>,<line build out
> (LBO)>,<framing>,<coding>[,yellow]
> #
> # All T1/E1 spans generate a clock signal on their
> transmit side. The
> # <timing source> parameter determines whether the clock
> signal from the far
> # end of the T1/E1 is used as the master source of clock
> timing. If it is, our
> # own clock will synchronise to it. T1/E1's connected
> directly or indirectly to
> # a PSTN provider (telco) should generally be the first
> choice to sync to. The
> # PSTN will never be a slave to you. You must be a slave
> to it.
> #
> # Choose 1 to make the equipment at the far end of the
> E1/T1 link the preferred
> # source of the master clock. Choose 2 to make it the
> second choice for the master
> # clock, if the first choice port fails (the far end
> dies, a cable breaks, or
> # whatever). Choose 3 to make a port the third choice,
> and so on. If you have, say,
> # 2 ports connected to the PSTN, mark those as 1 and 2.
> The number used for each
> # port should be different.
> #
> # If you choose 0, the port will never be used as a
> source of timing. This is
> # appropriate when you know the far end should always be
> a slave to you. If the
> # port is connected to a channel bank, for example, you
> should always be its
> # master. Any number of ports can be marked as 0.
> #
> # Incorrect timing sync may cause clicks/noise in the
> audio, poor quality or failed
> # faxes, unreliable modem operation, and is a general all
> round bad thing.
> #
> # The line build-out (or LBO) is an integer, from the
> following table:
> # 0: 0 db (CSU) / 0-133 feet (DSX-1)
> # 1: 133-266 feet (DSX-1)
> # 2: 266-399 feet (DSX-1)
> # 3: 399-533 feet (DSX-1)
> # 4: 533-655 feet (DSX-1)
> # 5: -7.5db (CSU)
> # 6: -15db (CSU)
> # 7: -22.5db (CSU)
> #
> # The framing is one of "d4" or "esf" for T1 or "cas" or
> "ccs" for E1
> #
> # Note: "d4" could be referred to as "sf" or "superframe"
> #
> # The coding is one of "ami" or "b8zs" for T1 or "ami" or
> "hdb3" for E1
> #
> # E1's may have the additional keyword "crc4" to enable
> CRC4 checking
> #
> # If the keyword "yellow" follows, yellow alarm is
> transmitted when no
> # channels are open.
> #
>
> span=1,0,0,ccs,hdb3
> bchan=1-31
> span=2,0,0,ccs,hdb3
> bchan=32-62
>
> #span=1,0,0,esf,b8zs
> #span=2,1,0,esf,b8zs
> #span=3,0,0,ccs,hdb3,crc4
> #
> # Next come the dynamic span definitions, in the form:
> # dynamic=<driver>,<address>,<numchans>,<timing>
> #
> # Where <driver> is the name of the driver (e.g. eth),
> <address> is the
> # driver specific address (like a MAC for eth),
> <numchans> is the number
> # of channels, and <timing> is a timing priority, like
> for a normal span.
> # use "0" to not use this as a timing source, or
> prioritize them as
> # primary, secondard, etc. Note that you MUST have a
> REAL zaptel device
> # if you are not using external timing.
> #
> # dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
> #
> # Next come the definitions for using the channels. The
> format is:
> # <device>=<channel list>
> #
> # Valid devices are:
> #
> # "e&m" : Channel(s) are signalled using E&M
> signalling (specific
> # implementation, such as Immediate, Wink, or
> Feature Group D
> # are handled by the userspace library).
> # "fxsls" : Channel(s) are signalled using FXS
> Loopstart protocol.
> # "fxsgs" : Channel(s) are signalled using FXS
> Groundstart protocol.
> # "fxsks" : Channel(s) are signalled using FXS
> Koolstart protocol.
> # "fxols" : Channel(s) are signalled using FXO
> Loopstart protocol.
> # "fxogs" : Channel(s) are signalled using FXO
> Groundstart protocol.
> # "fxoks" : Channel(s) are signalled using FXO
> Koolstart protocol.
> # "sf" : Channel(s) are signalled using in-band
> single freq tone.
> # Syntax as follows:
> # channel# =>
> sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
> # rxfreq is rx tone freq in hz, rxbw is rx notch (and
> decode)
> # bandwith in hz (typically 10.0), rxflag is either
> 'normal' or
> # 'inverted', txfreq is tx tone freq in hz, txlevel is
> tx tone
> # level in dbm, txflag is either 'normal' or 'inverted'.
> Set
> # rxfreq or txfreq to 0.0 if that tone is not desired.
> # "unused" : No signalling is performed, each channel in
> the list remains idle
> # "clear" : Channel(s) are bundled into a single span.
> No conversion or
> # signalling is performed, and raw data is
> available on the master.
> # "indclear": Like "clear" except all channels are
> treated individually and
> # are not bundled. "bchan" is an alias for
> this.
> # "rawhdlc" : The zaptel driver performs HDLC encoding
> and decoding on the
> # bundle, and the resulting data is
> communicated via the master
> # device.
> # "fcshdlc" : The zapdel driver performs HDLC encoding
> and decoding on the
> # bundle and also performs incoming and
> outgoing FCS insertion
> # and verification. "dchan" is an alias for
> this.
> # "nethdlc" : The zaptel driver bundles the channels
> together into an
> # hdlc network device, which in turn can be
> configured with
> # sethdlc (available separately).
> # "dacs" : The zaptel driver cross connects the
> channels starting at
> # the channel number listed at the end, after
> a colon
> # "dacsrbs" : The zaptel driver cross connects the
> channels starting at
> # the channel number listed at the end, after
> a colon and
> # also performs the DACSing of RBS bits
> #
> # The channel list is a comma-separated list of channels
> or ranges, for
> # example:
> #
> # 1,3,5 (channels one, three, and five)
> # 16-23, 29 (channels 16 through 23, as well as channel
> 29 #
> # So, some complete examples are:
> # e&m=1-12
> # nethdlc=13-24
> # fxsls=25,26,27,28
> # fxols=29-32
> #
> #fxoks=1-24
> #bchan=25-47
> #dchan=48
> #fxols=1-12
> #fxols=13-24
> #e&m=25-29
> #nethdlc=30-33
> #clear=44
> #clear=45
> #clear=46
> #clear=47
> #fcshdlc=48
> #dacs=1-24:48
> #dacsrbs=1-24:48
> #
> # Finally, you can preload some tone zones, to prevent
> them from getting
> # overwritten by other users (if you allow non-root users
> to open /dev/zap/*
> # interfaces anyway. Also this means they won't have to
> be loaded at runtime.
> # The format is "loadzone=<zone>" where the zone is a two
> letter country code.
> #
> # You may also specify a default zone with
> "defaultzone=<zone>" where zone
> # is a two letter country code.
> #
> # An up-to-date list of the zones can be found in the
> file zaptel/zonedata.c
> #
> loadzone = us
> #loadzone = us-old
> #loadzone=gr
> #loadzone=it
> #loadzone=fr
> #loadzone=de
> #loadzone=uk
> #loadzone=fi
> #loadzone=jp
> #loadzone=sp
> #loadzone=no
> #loadzone=hu
> #loadzone=lt
> #loadzone=pl
> defaultzone=us
> #
> # Section for PCI Radio Interface
> # (see http://www.zapatatelephony.org/app_rpt.html)
> #
> # The PCI Radio Interface card interfaces up to 4 two-way
> radios (either
> # a base/mobile radio or repeater system) to Zaptel
> channels. The driver
> # may work either independent of an application, or with
> it, through
> # the driver;s ioctl() interface. This file gives you
> access to specify
> # load-time parameters for Radio channels, so that the
> driver may run
> # by itself, and just act like a generic Zaptel radio
> interface.
> #
> # Unlike the rest of this file, you specify a block of
> parameters, and
> # then the channel(s) to which they apply. CTCSS is
> specified as a frequency
> # in tenths of hertz, for example 131.8 HZ is specified
> as 1318. DCS
> # for receive is specified as the code directly, for
> example 223. DCS for
> # transmit is specified as D and then the code, for
> example D223.
> #
> # The hardware supports a "community" CTCSS decoder
> system that has
> # arbitrary transmit CTCSS or DCS codes associated with
> them, unlike
> # traditional "community" systems that encode the same
> tone they decode.
> #
> # this example is a single tone DCS transmit and receive
> #
> # # specify the transmit tone (in DCS mode this stays
> constant)
> # tx=D371
> # # specify the receive DCS code
> # dcsrx=223
> #
> # this example is a "community" CTCSS (if you only want a
> single tone, then
> # only specify 1 in the ctcss list)
> #
> # # specify the default transmit tone (when not
> receiving) # tx=1000
> # # Specify the receive freq, the tag (use 0 if none),
> and the transmit code.
> # # The tag may be used by applications to determine
> classification of tones.
> # # The tones are to be specified in order of presedence,
> most important first.
> # # Currently, 15 tones may be specified..
> # ctcss=1318,1,1318
> # ctcss=1862,1,1862
> #
> # The following parameters may be omitted if their
> default value is acceptible
> #
> # # set the receive debounce time in milliseconds
> # debouncetime=123
> # # set the transmit quiet dropoff burst time in
> milliseconds
> # bursttime=234
> # # set the COR level threshold (specified in tenths of
> millivolts)
> # # valid values are
> {3125,6250,9375,12500,15625,18750,21875,25000}
> # corthresh=12500
> # # Invert COR signal {y,n}
> # invertcor=y
> # # set the external tone mode; yes, no, internal {y,n,i}
> # exttone=y
> #
> # Now apply the configuration to the specified channels:
> #
> # # We are all done with our channel parameters, so now
> we specify what
> # # channels they apply to
> # channels=1-4
>
> On 19 March 2006 00:28, ADEGOKE ARUNA wrote:
> > Thank you for the past responses,
> >
> > Can someone please help me point out my flaws again?
> >
> > I am working on fedora core 3 with sangoma a104d and
> > lastest stable asterisk and libs.
> >
> > I have disabled my chan_zap.so
> >
> > After compiling my chan_ss7-0.8.3
> >
> > WIRELESS2*CLI> load chan_ss7.so
> > Loaded /usr/lib/asterisk/modules/chan_ss7.so => (SS7
> > Protocol Support) Mar 18 19:10:08 NOTICE[11525]:
> > config.c:320 load_config_linkset: Using default
> > language '' for linkset 'siuc'
> > Mar 18 19:10:08 NOTICE[11525]: config.c:463
> > load_config_link: Configured link 'l1' on linkset
> > 'siuc', firstcic=1
> > Mar 18 19:10:08 NOTICE[11525]: config.c:463
> > load_config_link: Configured link 'l2' on linkset
> > 'siuc', firstcic=33
> > Mar 18 19:10:08 NOTICE[11525]: config.c:463
> > load_config_link: Configured link 'l3' on linkset
> > 'siuc', firstcic=65
> > Mar 18 19:10:08 NOTICE[11525]: config.c:463
> > load_config_link: Configured link 'l4' on linkset
> > 'siuc', firstcic=97
> > Mar 18 19:10:08 WARNING[11525]: config.c:622
> > load_config_host: Missing interface entries for host
> > 'WIRELESS2'.
> > Mar 18 19:10:08 NOTICE[11525]: config.c:772
> > load_config: Configuring DPC 60 for linkset 'siuc'.
> > -- Starting cluster thread, pid=3976.
> > Mar 18 19:10:09 NOTICE[11525]: mtp.c:1934 mtp_init:
> > Initialising 1 signalling links
> > -- Starting MTP thread, pid=3976.
> > -- Starting continuity check thread, pid=3976.
> > == Registered channel type 'SS7' (SS7 Protocol
> > Driver) -- SS7 channel loaded successfully.
> > -- Starting monitor thread, pid=3976.
> > Mar 18 19:10:09 WARNING[14785]: mtp.c:1539
> > mtp_thread_main: Empty Zaptel output buffer detected,
> > outgoing packets may have been lost on link 'l1'.
> > WIRELESS2*CLI> ss7
> > block cluster dump linestat link reset
> > unblock WIRELESS2*CLI> ss7 li
> > linestat link
> > WIRELESS2*CLI> ss7 linestat
> > Linkset: siuc>
> > Mar 18 19:11:24 WARNING[14785]: mtp.c:393 t2_timeout:
> > MTP2 timer T2 timeout (failed to receive 'O', 'N', or
> > 'E' after sending 'O'), initial alignment failed on
> > link 'l1'.
> >
> >
> > when I dialed 6210006
> > i get this:
> >
> > -- Executing Dial("IAX2/marko-2", "ss7/6210010|60") in
> > new stack -- SS7 request (ss7/6210010) format = 0x8.
> > Mar 18 20:15:59 WARNING[5495]: chan_ss7.c:425
> > cic_hunt_even_mru: No idle circuit found.
> > Mar 18 20:15:59 WARNING[5495]: chan_ss7.c:646
> > ss7_requester: SS7 requester: No idle circuit
> > available. Mar 18 20:15:59 NOTICE[5495]:
> > app_dial.c:1011
> > dial_exec_full: Unable to create channel of type 'ss7'
> > (cause 17 - User busy) == Everyone is busy/congested at
> > this time (1:1/0/0) == Auto fallthrough, channel
> > 'IAX2/marko-2' status is 'BUSY'
> >
> > :22:37 WARNING[14785]: mtp.c:1438 mtp_thread_main:
> > : Excessive poll delay
> >
> > 20978!
> > Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> > mtp_thread_main: Excessive poll delay 20979!
> > Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> > mtp_thread_main: Excessive poll delay 20977!
> > Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> > mtp_thread_main: Excessive poll delay 20978!
> > Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> > mtp_thread_main: Excessive poll delay 20978!
> > Mar 18 19:22:38 WARNING[14785]: mtp.c:1438
> > mtp_thread_main: Excessive poll delay 20979!
> >
> >
> >
> > Mar 18 19:25:20 WARNING[15612] mtp.c: Excessive poll
> > delay 20979! Mar 18 19:25:20 WARNING[15624] chan_ss7.c:
> > No idle circuit found. Mar 18 19:25:20 WARNING[15624]
> > chan_ss7.c: SS7 requester: No idle circuit available.
> > Mar 18 19:25:20 NOTICE[15624] app_dial.c: Unable to
> > create channel of type 'SS7' (cause 17 - User busy)
> >
> >
> > Extensions.conf
> > [default]
> > Exten => _621XXXX,1,Dial(ss7/${EXTEN},60)
> >
> > zaptel.conf
> >
> > loadzone = uk
> > defaultzone = uk
> >
> > #span definitions
> > span = 1,1,0,ccs,hdb3,crc4,yellow
> > span = 2,2,0,ccs,hdb3,crc4,yellow
> > span = 3,3,0,ccs,hdb3,crc4,yellow
> > span = 4,4,0,ccs,hdb3,crc4,yellow
> >
> > #channel definitions
> > #bchan = 1-124
> > #bchan = 1-15,17-124
> > #dchan = 16
> >
> >
> >
> > zapata.conf
> >
> > ;[trunkgroups]
> > ;trunkgroup => 1, 16
> >
> > ;spanmap
> > ;spanmap => 1,1,1
> > ;spanmap => 2,1,2
> > ;spanmap => 3,1,3
> > ;spanmap => 4,1,4
> >
> >
> > [channels]
> > ;context = default
> > ;switchtype = Euroisdn
> > ;usecallerid = yes
> > ;echocancel = yes
> > ;echocancelwhenbridged = yes
> > ;rxgain = 0.0
> > ;txgain = 0.0
> >
> > ;signalling = pri_cpe
> > ;group = 1
> > ;channel = 1-15,17-31
> >
> >
> > one of the wanpipe#.conf that controls sangoma
> > interface
> >
> > #================================================
> > # Sangoma Technologies Inc.
> > #================================================
> >
> > [devices]
> > wanpipe1 = WAN_AFT_TE1, Comment
> >
> > [interfaces]
> > w1g1 = wanpipe1, , TDM_VOICE, Comment
> >
> > [wanpipe1]
> > CARD_TYPE = AFT
> > S514CPU = A
> > CommPort = PRI
> > AUTO_PCISLOT = NO
> > PCISLOT = 13
> > PCIBUS = 6
> > FE_MEDIA = E1
> > FE_LCODE = HDB3
> > FE_FRAME = CRC4
> > FE_LINE = 1
> > TE_CLOCK = NORMAL
> > TE_REF_CLOCK = 0
> > TE_HIGHIMPEDANCE = NO
> > LBO = 120OH
> > FE_TXTRISTATE = NO
> > MTU = 1500
> > UDPPORT = 9000
> > TTL = 255
> > IGNORE_FRONT_END = NO
> > TDMV_SPAN = 1
> > TDMV_DCHAN = 0
> >
> > [w1g1]
> > ACTIVE_CH = ALL
> > TDMV_ECHO_OFF = NO
> > TDMV_HWEC = YES
> >
> >
> > ss7.conf is as below
> > [linkset-siuc]
> > enabled => yes
> > enable_st => no
> > use_connect => no #bcos am connect to alcatel s12 which
> > doesn't lik con hunting_policy => even_mru
> > subservice => auto
> >
> > [link-l1]
> > linkset => siuc
> > channels => 1-15,17-31
> > schannel => 16
> > firstcic => 1
> > enabled => yes
> >
> > [link-l2]
> > linkset => siuc
> > channels => 1-31
> > schannel =>
> > firstcic => 33
> > enabled => yes
> >
> > [link-l3]
> > linkset => siuc
> > channels => 1-31
> > schannel =>
> > firstcic => 65
> > enabled => yes
> >
> > [link-l4]
> > linkset => siuc
> > channels => 1-31
> > schannel =>
> > firstcic => 97
> > enabled => yes
> >
> > [host-WIRELESS2]
> > enabled => yes
> > opc => 900
> > dpc => siuc:60
> > links => l1:1,l2:2,l3:3,l4:4
> >
> >
> >
> >
> > The following output is produced
> > Mar 18 19:25:24 WARNING[15612] mtp.c: Excessive poll
> > delay 20979! Mar 18 19:25:25 WARNING[15612] mtp.c:
> > Excessive poll delay 20978! Mar 18 19:25:25
> > WARNING[15612] mtp.c: Excessive poll delay 20979! Mar
> > 18 19:25:25 WARNING[15612] mtp.c: Excessive poll delay
> > 20979! Mar 18 19:25:25 WARNING[15612] mtp.c: Excessive
> > poll delay 20979! Mar 18 19:25:25 WARNING[15612] mtp.c:
> > Excessive poll delay 20979! Mar 18 19:25:25
> > WARNING[15612] mtp.c: Excessive poll delay 20980!
> >
> >
> > and its just to much and that the log growths in MB per
> > minute
> >
> >
> > after I rebooted my pc and applying the kai Militzer's
> > patch I got the following error
> > Verbosity is at least 3
> > Mar 18 20:13:30 WARNING[5478]: mtp.c:414 t3_timeout:
> > MTP2 timer T3 timeout (failed to receive 'N', or 'E'
> > after sending 'O'), initial alignment failed on link
> > 'l1'. Mar 18 20:13:33 WARNING[5478]: mtp.c:414
> > t3_timeout: MTP2 timer T3 timeout (failed to receive
> > 'N', or 'E' after sending 'O'), initial alignment
> > failed on link 'l1'. Mar 18 20:13:36 WARNING[5478]:
> > mtp.c:414 t3_timeout: MTP2 timer T3 timeout (failed to
> > receive 'N', or 'E' after sending 'O'), initial
> > alignment failed on link 'l1'. Mar 18 20:13:38
> > WARNING[5478]: mtp.c:414 t3_timeout: MTP2 timer T3
> > timeout (failed to receive 'N', or 'E' after sending
> > 'O'), initial alignment failed on link 'l1'. Mar 18
> > 20:13:41 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> > timer T3 timeout (failed to receive 'N', or 'E' after
> > sending 'O'), initial alignment failed on link 'l1'.
> > Mar 18 20:13:44 NOTICE[5478]: mtp.c:1197 mtp2_read_su:
> > MTP2 bitstream frame format error, entering octet
> > counting mode on link 'l1'. Mar 18 20:13:46
> > WARNING[5478]: mtp.c:414 t3_timeout: MTP2 timer T3
> > timeout (failed to receive 'N', or 'E' after sending
> > 'O'), initial alignment failed on link 'l1'.
> > Mar 18 20:13:49 WARNING[5478]: mtp.c:414 t3_timeout:
> > MTP2 timer T3 timeout (failed to receive 'N', or 'E'
> > after sending 'O'), initial alignment failed on link
> > 'l1'. Mar 18 20:13:52 WARNING[5478]: mtp.c:414
> > t3_timeout: MTP2 timer T3 timeout (failed to receive
> > 'N', or 'E' after sending 'O'), initial alignment
> > failed on link 'l1'.
> >
> >
> >
> >
> >
> >
> > ss7 link status
> > linkset siuc, link l1, schannel 16, ALIGNED, rx: 3, tx:
> > 0/4, sentseq/lastack: 127/127, total 73792,
> > 73856
> >
> >
> > WIRELESS2*CLI> ss7 linestat
> > Linkset: siuc>
> > CIC 1 Idle Reset pending
> > CIC 2 Idle Reset pending
> > CIC 3 Idle Reset pending
> >
> >
> >
> > CIC 125 Idle Reset pending
> > CIC 126 Idle Reset pending
> > CIC 127 Idle Reset pending
> >
> >
> >
> >
> > -----Original Message-----
> > From: Kai Militzer [mailto:km@xxxxxxxxxxx]
> > Sent: Friday, March 17, 2006 4:39 PM
> > To: ADEGOKE ARUNA
> > Subject: Re: chan_ss7.c: Failure in ZT_SPECIFY for
> > circuit 1: Device or resource busy
> >
> > Hi Goksie,
> >
> > ADEGOKE ARUNA wrote:
> > > What do you ask to disable?
> >
> > If you had this system at first running with ISDN E1s
> > (no SS7) you have to disable your config for that at
> > first.
> >
> > And did you tell your Telco that they have to configure
> > the S12 to talk SS7 instead of ISDN to you? For me it
> > doesn't look that way. Nevertheless it's not that easy
> > to find your problem without more information.
> >
> > I am off into the weekend now, if you need more help
> > send me an email, i will answer you on monday.
> >
> > Regards,
> > Kai
|