Pri Channels Locked

Home » Asterisk Users » Pri Channels Locked
Asterisk Users 3 Comments

Hi everyone!

Everyday some channels go to this situation:

# asterisk -rx ‘pri show channels’| head -n 32 | grep ‘Yes No Idle
Yes’
PRI B Chan Call PRI Channel Span Chan Chan Idle Level Call Name
1 1 Yes No Idle Yes
1 2 Yes No Idle Yes
1 6 Yes No Idle Yes
1 13 Yes No Idle Yes
1 14 Yes No Idle Yes
1 17 Yes No Idle Yes
1 18 Yes No Idle Yes
1 19 Yes No Idle Yes
1 20 Yes No Idle Yes
1 21 Yes No Idle Yes
1 22 Yes No Idle Yes
1 23 Yes No Idle Yes
1 24 Yes No Idle Yes
1 25 Yes No Idle Yes
1 26 Yes No Idle Yes
1 29 Yes No Idle Yes

This is an incoming calls only, and all calls on this channels are be rejected. Telco delivery calls on minor channel available, empowering my problem.

Any investigation suggestion?

3 thoughts on - Pri Channels Locked

  • You have not specified the Asterisk nor libpri versions involved. I know your Asterisk version has to at least be mid-v1.8 in order to have the
    “pri show channels” command.

    The PRI call column being Yes is why those channels don’t get any more calls. You will need to find out what abnormal signalling causes the libpri call structure to be left associated with the B channel. It could be glare, call aborted early, hangup never completed, channel got RESTARTed, etc.

    You will need to read [1] and use the CLI “pri set debug on span x” command.

    Richard

    [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

  • Ops! Sorry Richard, more information:

    # asterisk -V
    Asterisk 11.17.1
    # asterisk -rx ‘pri show version’
    libpri version: 1.4.15

    I found some information: my asterisk forward calls to a lot of equipments, and the last call on channel 1 was to a equipment that was restarted (SO fail). And seconds later on my messages:
    [2016-02-23 12:41:06] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c018c70). Dropping call.
    [2016-02-23 12:41:19] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c03bf90). Dropping call.
    [2016-02-23 12:41:26] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c000f70). Dropping call.
    [2016-02-23 12:41:32] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c0258b0). Dropping call.
    [2016-02-23 12:41:38] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c0305c0). Dropping call.
    [2016-02-23 12:41:57] WARNING[24348] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x7fc52c0a7040). Dropping call.

    Any way to restart only this channels?
    I have scheduled ‘service dahdi restart’ at maintenance window. It’s sufficient?

    Is efficient a debug on span after ‘Idle’ status?

    Em 2016-02-23 17:33, Richard Mudgett escreveu:

  • No. You cannot restart single channels, you can only restart all dahdi channels in asterisk.

    It is not the DAHDI service that needs to be restarted but the DAHDI
    channels in asterisk. You need to either restart asterisk or use the CLI “dahdi restart”. Restarting asterisk is better because the dahdi restart command by necessity is going to leak memory.

    To figure out why the stuck channel happens, what is needed is the debug logs and the “pri set debug on span x” output of the last successful call on the stuck channel to when you see the “Got SETUP with duplicate…” rejecting the next call. In other words, the log needs to cover from when the last successful incoming call starts on the stuck channel to when the next rejected call completes.

    This looks like a bug in asterisk when handling an abnormal condition.

    Richard