CIC init process and sequence of calls.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jorge:

try second cic starting at 33, not at 32, 3rd at 64 etc ...
skip 1 channel at each span cic definition

-wasim

On Tue, Jan 11, 2011 at 23:04, Jorge Antillon <jantillon at ticom.co.cr> wrote:

>  Hi,
>
> Single DPC, single signalling channel, although we should have a second
> signalling channel available soon.
>
> chan_dadhdi.conf is empty, remember I am using chan_ss7.
>
> thanks,
>
> Jorge.
>
>
> On Mon, 2011-01-10 at 12:34 +0530, bipin singh wrote:
>
>
> Hi,
>          You have single adjpointcode or multiple . can u send youre
> chan_dahdi.conf .
>
>  On Mon, Jan 3, 2011 at 11:37 PM, Jorge Antillon <jantillon at ticom.co.cr>
> wrote:
>
>  Hi,
>
> Ok, so after installing chan_ss7 1.4.3 things got a little better with
> individual CIC handling and how it behaves and performs.
> Brief up:
> Chan_ss7 1.4.3, asterisk 1.4.30, dahdi 2.2.1, libpri 1.4.10.2, 5 OpenVox 4
> ports each distributed across 5 boxes.
>
> We have 20 E1s that should be as clear and working, but for some reason we
> notice the following init differences in CICs; below will be an excerpt of
> our ss7.conf and how the CICs initialize in the 5 boxes, 4 ports each.
>
> Signalling channel is 31 on the first E1.
>
> CICs in config file:
> 1 firstcic => 1
> 1 firstcic => 32
> 1 firstcic => 63
> 1 firstcic => 94
> 2 firstcic => 125
> 2 firstcic => 156
> 2 firstcic => 187
> 2 firstcic => 218
> 3 firstcic => 249
> 3 firstcic => 280
> 3 firstcic => 311
> 3 firstcic => 342
> 4 firstcic => 373
> 4 firstcic => 404
> 4 firstcic => 435
> 4 firstcic => 466
> 5 firstcic => 497
> 5 firstcic => 528
> 5 firstcic => 559
> 5 firstcic => 590
>
>
>
> Box1
> [Dec 26 00:45:29] NOTICE[32216]: l4isup.c:3498 process_gra: Process GRA,
> cic=1, range=29
> [Dec 26 00:45:29] NOTICE[32216]: l4isup.c:3498 process_gra: Process GRA,
> cic=32, range=31
> [Dec 26 00:45:29] NOTICE[32216]: l4isup.c:3498 process_gra: Process GRA,
> cic=64, range=31
> [Dec 26 00:45:29] NOTICE[32216]: l4isup.c:3498 process_gra: Process GRA,
> cic=96, range=28
> Box2
> [Dec 26 00:44:13] NOTICE[18361]: l4isup.c:3498 process_gra: Process GRA,
> cic=125, range=31
> [Dec 26 00:44:13] NOTICE[18361]: l4isup.c:3498 process_gra: Process GRA,
> cic=157, range=31
> [Dec 26 00:44:13] NOTICE[18361]: l4isup.c:3498 process_gra: Process GRA,
> cic=189, range=31
> [Dec 26 00:44:13] NOTICE[18361]: l4isup.c:3498 process_gra: Process GRA,
> cic=221, range=27
> Box3
> [Dec 26 00:43:11] NOTICE[14261]: l4isup.c:3498 process_gra: Process GRA,
> cic=249, range=31
> [Dec 26 00:43:11] NOTICE[14261]: l4isup.c:3498 process_gra: Process GRA,
> cic=281, range=31
> [Dec 26 00:43:11] NOTICE[14261]: l4isup.c:3498 process_gra: Process GRA,
> cic=313, range=31
> [Dec 26 00:43:11] NOTICE[14261]: l4isup.c:3498 process_gra: Process GRA,
> cic=345, range=27
> Box4
> [Dec 26 00:44:08] NOTICE[18418]: l4isup.c:3498 process_gra: Process GRA,
> cic=373, range=31
> [Dec 26 00:44:08] NOTICE[18418]: l4isup.c:3498 process_gra: Process GRA,
> cic=405, range=31
> [Dec 26 00:44:08] NOTICE[18418]: l4isup.c:3498 process_gra: Process GRA,
> cic=437, range=31
> [Dec 26 00:44:08] NOTICE[18418]: l4isup.c:3498 process_gra: Process GRA,
> cic=469, range=27
> Box5
> [Dec 26 01:43:37] NOTICE[28186]: l4isup.c:3498 process_gra: Process GRA,
> cic=497, range=31
> [Dec 26 01:43:37] NOTICE[28186]: l4isup.c:3498 process_gra: Process GRA,
> cic=529, range=31
> [Dec 26 01:43:37] NOTICE[28186]: l4isup.c:3498 process_gra: Process GRA,
> cic=561, range=31
> [Dec 26 01:43:37] NOTICE[28186]: l4isup.c:3498 process_gra: Process GRA,
> cic=593, range=27
>
> Where if you separate and look at the CICs, they initialize in a different
> fashion than programmed.
> for instance, first CIC, third E1 starts at 64 where it should be 63, the
> shifting happens all across the E1s, starting at the second circuit and also
> the range on the last E1 of each box goes down by a 3 CICs.
>
> The problem here is low ASR, where a channel tries to initialize and it
> never actually gets to the other side, but instead, starts ringing busy, as
> if the number was busy, when in reality its all available.
>
> Thanks,
>
>     Jorge.
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
>
>
>
> --
> BIPIN RAGHUVANSHI
> OPERATION HEAD
> ASTERISK (DEVELOPMENT AND RESEARCH)
> WWW.EHORIZONS.IN
> 011-32323262
> 011-46334633
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7
>



-- 
wasim h. baig | principal consultant | convergence pk | +92 30 0850 8070 |
peace be upon you ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110112/f08417dd/attachment.htm>


[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux