[asterisk-dev] Asterisk 13 GIT Deadlock

[Ross Beer]

Hi All,


I've raised a ticket for a recent deadlock in Asterisk and can't track down the 
cause:


  1.  ASTERISK-26686 
(https://issues.asterisk.org/jira/browse/ASTERISK-26686)


The issue is happening daily on multiple servers at random times.


Can anyone provide assistance on the cause so I can update the ticket with the 
correct information?


Regards,


Ross

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 13 GIT Deadlock

[Joshua Colp]

On Tue, Jan 3, 2017, at 07:56 AM, Ross Beer wrote:
> Hi All,
> 
> 
> I've raised a ticket for a recent deadlock in Asterisk and can't track
> down the cause:
> 
> 
>   1. 
>   ASTERISK-26686
>   (https://issues.asterisk.org/jira/browse/ASTERISK-26686)
> 
> 
> The issue is happening daily on multiple servers at random times.
> 
> 
> Can anyone provide assistance on the cause so I can update the ticket
> with the correct information?

I have already triaged this issue and added the cause.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk or Jansson issue?

[Joshua Colp]

On Wed, Dec 14, 2016, at 09:07 AM, Ross Beer wrote:
> Hi,
> 
> Is the below segfault caused by Asterisk or Jansson? Currently using
> version 2.9 as packaged with Fedora 23.



It is likely in our usage of jansson or memory corruption. An issue
should be filed for it if not already done.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Fw: Caller ID in FXO channel

[dpn]

Hi All,

First of all happy new year to everyone!

I am developing an FXO driver to use with Asterisk.
My driver is working fine and I can receive and originate calls and I have both 
ways audio.

I have issue with the callerid however.  I have set in can_dahdi.conf the 
default bell type starting after the first ring.
For testing I use FXS port which seems to send the calerid properly as it is 
displayed on an analog phone.
Occasionally I get the callerid (on the incoming calls for the FXO channel ) 
working but it is once per 20 calls.
It seems enabling Asterisk debug in the CLI makes the callerid detection a bit 
better as I see it working more often with CLI debug enabled.
This makes me think that I have timing or noise issue. 
On the FXO RING/TIP terminals I do see (with oscilloscope) the callerID FSK 
signals. It I swith about 5Vpp and yes I see some noise.
Not sure how sensitive the demodulator is. 

Before going into more details I want to ask the mailing list. Probably I have 
some simple signaling issue like getting the FXO off hook to early or too late.

I have my FXO context like
[fxo]
exten => s,1,Answer 
  
exten => s,2, Noop(${CALLERID(num)})
 
exten => s,3,Background(/demo-congrats)  
exten => s,4,Hangup   

Bellow I include the log for reference. 
Any thoughts or advices how to narrow the problem are welcome!

d-ff*CLI> [Jan  2 19:35:56] DEBUG[1672]: chan_dahdi.c:12229 do_monitor: 
Monitor doohicky got event Ring Begin on channel 2
[Jan  2 19:35:56] DEBUG[1672]: sig_analog.c:3697 analog_handle_init_event: 
channel (2) - signaling (5) - event (ANALOG_EVENT_RINGBEGIN)
[Jan  2 19:35:56] DEBUG[1672]: chan_dahdi.c:12229 do_monitor: Monitor doohicky 
got event Ring Begin on channel 2
[Jan  2 19:35:56] DEBUG[1672]: sig_analog.c:3697 analog_handle_init_event: 
channel (2) - signaling (5) - event (ANALOG_EVENT_RINGBEGIN)
d-ff*CLI> [Jan  2 19:35:58] DEBUG[1672]: chan_dahdi.c:12229 do_monitor: 
Monitor doohicky got event Ring/Answered on channel 2
[Jan  2 19:35:58] DEBUG[1672]: chan_dahdi.c:12229 do_monitor: Monitor doohicky 
got event Ring/Answered on channel 2
d-ff*CLI> [Jan  2 19:35:58] DEBUG[1672]: sig_analog.c:3697 
analog_handle_init_event: channel (2) - signaling (5) - event 
(ANALOG_EVENT_RINGOFFHOOK)
[Jan  2 19:35:58] DEBUG[1672]: sig_analog.c:3697 analog_handle_init_event: 
channel (2) - signaling (5) - event (ANALOG_EVENT_RINGOFFHOOK)
d-ff*CLI> [Jan  2 19:35:58] DEBUG[1672][C-0007]: dsp.c:482 
ast_tone_detect_init: Setup tone 1100 Hz, 500 ms, block_size=160, 
hits_required=21
[Jan  2 19:35:58] DEBUG[1672][C-0007]: dsp.c:482 ast_tone_detect_init: 
Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21
d-ff*CLI> [Jan  2 19:35:58] DEBUG[1672][C-0007]: dsp.c:482 
ast_tone_detect_init: Setup tone 2100 Hz, 2600 ms, block_size=160, 
hits_required=116
[Jan  2 19:35:58] DEBUG[1672][C-0007]: dsp.c:482 ast_tone_detect_init: 
Setup tone 2100 Hz, 2600 ms, block_size=160, hits_required=116
d-ff*CLI> [Jan  2 19:35:58] DEBUG[1696]: sig_analog.c:1764 
__analog_ss_thread: __analog_ss_thread 2
[Jan  2 19:35:58] DEBUG[1696]: sig_analog.c:1764 __analog_ss_thread: 
__analog_ss_thread 2
-- Starting simple switch on 'DAHDI/2-1'
d-ff*CLI> -- Starting simple switch on 'DAHDI/2-1'
[Jan  2 19:36:02] DEBUG[1696][C-0007]: pbx.c:4883 pbx_extension_helper: 
Launching 'Answer'
[Jan  2 19:36:02] DEBUG[1696][C-0007]: pbx.c:4883 pbx_extension_helper: 
Launching 'Answer'
d-ff*CLI> -- Executing [s@penev_fxo:1] Answer("DAHDI/2-1", "") in new 
stack
-- Executing [s@penev_fxo:1] Answer("DAHDI/2-1", "") in new stack
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: sig_analog.c:1497 
analog_answer: analog_answer 2
[Jan  2 19:36:02] DEBUG[1696][C-0007]: sig_analog.c:1497 analog_answer: 
analog_answer 2
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: sig_analog.c:1528 
analog_answer: Took DAHDI/2-1 off hook
[Jan  2 19:36:02] DEBUG[1696][C-0007]: sig_analog.c:1528 analog_answer: 
Took DAHDI/2-1 off hook
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:5061 
dahdi_enable_ec: No echo cancellation requested
[Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:5061 dahdi_enable_ec: 
No echo cancellation requested
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:5077 
dahdi_train_ec: No echo training requested
[Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:5077 dahdi_train_ec: No 
echo training requested
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:9656 
dahdi_indicate: Requested indication -1 on channel DAHDI/2-1
[Jan  2 19:36:02] DEBUG[1696][C-0007]: chan_dahdi.c:9656 dahdi_indicate: 
Requested indication -1 on channel DAHDI/2-1
d-ff*CLI> [Jan  2 19:36:02] DEBUG[1696][C-0007]: pbx.c:4883 
pbx_e

[asterisk-dev] Local channel variable propagation: expired hack or a bug?

[Kirill Katsnelson]

With Asterisk 1.8 we were relying on the behavior of Originate with 
Local channels as mentioned in 
https://issues.asterisk.org/jira/browse/ASTERISK-17239. This no longer 
works in Asterisk 13.


Specifically, when a call is originated (e. g. via AMI) between 
"channel" Local/x@local-side and "extension" y@remote-side, the 
local-side runs on the Local/xxx;1 channel, and sets some variables in 
the dialplan. The old, 1.8 behavior, was to propagate the variables to 
the Local/xxx;2 channel when it gets it's turn to execute dialplan 
(y@remote-side in the example), after an infinitesimal Wait(), as the 
ticket explains.


This does not happen anymore in Asterisk 13. In fact, no variables are 
set on the remote-side, Local/xxx;2 channel; none of BRIDGEPEER, 
DIALEDPEERNUMBER, SIPCALLID from the ticket flow are set.


Local channel optimization does not occur in this example, as there is 
only one bridge (and the LocalBridge between the Local channels)


So my question is, did we use an undocumented hack, and therefore must 
find a different solution, or the current implementation has a bug that 
should be fixed? I honestly cannot remember where I got the idea 
initially, and whether or not it was documented.


 -kkm

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Local channel variable propagation: expired hack or a bug?

[Richard Mudgett]

On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson 
wrote:

> With Asterisk 1.8 we were relying on the behavior of Originate with Local
> channels as mentioned in https://issues.asterisk.org/ji
> ra/browse/ASTERISK-17239. This no longer works in Asterisk 13.
>
> Specifically, when a call is originated (e. g. via AMI) between "channel"
> Local/x@local-side and "extension" y@remote-side, the local-side runs on
> the Local/xxx;1 channel, and sets some variables in the dialplan. The old,
> 1.8 behavior, was to propagate the variables to the Local/xxx;2 channel
> when it gets it's turn to execute dialplan (y@remote-side in the
> example), after an infinitesimal Wait(), as the ticket explains.
>
> This does not happen anymore in Asterisk 13. In fact, no variables are set
> on the remote-side, Local/xxx;2 channel; none of BRIDGEPEER,
> DIALEDPEERNUMBER, SIPCALLID from the ticket flow are set.
>
> Local channel optimization does not occur in this example, as there is
> only one bridge (and the LocalBridge between the Local channels)
>
> So my question is, did we use an undocumented hack, and therefore must
> find a different solution, or the current implementation has a bug that
> should be fixed? I honestly cannot remember where I got the idea initially,
> and whether or not it was documented.
>

You were definitely depending upon an implementation detail and some luck
on when the optimization would happen.  Asterisk versions before v12 used
masquerades to implement local channel optimizations.  The channel
executing dialplan before the wait turns into a different channel after the
wait because of the masquerade.  The wait simply made the local channel
optimization more likely to happen during the wait because the optimization
could happen any time during the exchange of media frames.  Asterisk v12+
no longer optimizes local channels this way.  Instead it moves a channel
from one bridge to another.  (See discussion on
https://issues.asterisk.org/jira/browse/ASTERISK-26681)

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev