[asterisk-users] pri channels locked

Richard Mudgett rmudgett at digium.com
Tue Feb 23 15:53:43 CST 2016


On Tue, Feb 23, 2016 at 3:01 PM, Jefferson B. Limeira <
jbl at internexxus.com.br> wrote:

> 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?
>

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


> I have scheduled 'service dahdi restart' at maintenance window. It's
> sufficient?
>

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.


>
> Is efficient a debug on span after 'Idle' status?


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160223/014f3b01/attachment.html>


More information about the asterisk-users mailing list