[asterisk-dev] 1.6.1.20 regression: Tones not always generated

[Jonathan Thurman]

On Tue, May 25, 2010 at 9:36 PM, Pavel Troller <patrol at sinus.cz> wrote:
>> On Tue, May 25, 2010 at 12:20 PM, Pavel Troller <patrol at sinus.cz> wrote:
>> > After reverting just this single change, i.e. moving the ast_prod() call,
>> > where it was, all the tones are on their correct places again. I'm aware of
>> > that I've reintroduced the local channel deadlock, but it is less important
>> > for me (not using chan_local very often) than missing tones.
>> >
>> Do you see the same problem is you use the 1.6.2 branch?  I only ask
>> because 1.6.0 and 1.6.1 are now closed for bug fixes (only security).
>> If this is a regression, the fix would be applied to 1.6.2.
>>
>> I would also create a new ticket on https://issues.asterisk.org to
>> track any potential fixes.
>
> Hi Paul,
>  the problem is that I currently don't operate any 1.6.2.x system. I have
> about 12 1.6.1.x installations, and my plan was to run them until 1.8 is out -
> I don't see so much new things in 1.6.2 to convince me for upgrading, 1.6.1 is
> otherwise stable in my environment and I'm happy with it. Upgrading asterisk
> is not very easy for me, I have many patches in it, which I would have to adapt
> (for example, I have all the asterisk self-contained in /opt/asterisk without
> any files dropped to the general system directories like /etc, /lib etc., which
> still cannot be done with just configure --prefix=/opt/asterisk because of
> paths hardcoded to the source, documentation etc.).
>  To help with searching for a possible cause, I've made two calls to the
> Ringing() app, one with the bug present, and the other without it (with the
> ast_prod() call moved back to its original place). The non-functional version
> produces the following debug:
>
> [May 25 18:17:00] DEBUG[31312] pbx.c: Launching 'Ringing'
> [May 25 18:17:00] DEBUG[31312] channel.c: Driver for channel 'SIP/2122-00000004' does not support indication 3, emulating it
> [May 25 18:17:00] DEBUG[31312] channel.c: Set channel SIP/2122-00000004 to write format slin
> [May 25 18:17:00] DEBUG[31312] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
> [May 25 18:17:00] DEBUG[31312] channel.c: Prodding channel 'SIP/2122-00000004'
> [May 25 18:17:00] DEBUG[31312] channel.c: Set channel SIP/2122-00000004 to write format alaw
> [May 25 18:17:00] DEBUG[31312] channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
> [May 25 18:17:00] DEBUG[31312] pbx.c: Launching 'Wait'
> [May 25 18:17:01] DEBUG[31312] rtp.c: Got RTCP report of 52 bytes
> ... and nothing regarding RTP being sent
>
>  The functional one looks like this:
>
> [May 26 06:25:45] DEBUG[28291] pbx.c: Launching 'Ringing'
> [May 26 06:25:45] DEBUG[28291] channel.c: Driver for channel 'SIP/2122-00000018' does not support indication 3, emulating it
> [May 26 06:25:45] DEBUG[28291] channel.c: Prodding channel 'SIP/2122-00000018'
> [May 26 06:25:45] DEBUG[28291] channel.c: Set channel SIP/2122-00000018 to write format slin
> [May 26 06:25:45] DEBUG[28291] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
> [May 26 06:25:45] DEBUG[28291] pbx.c: Launching 'Wait'
> [May 26 06:25:45] DEBUG[28291] rtp.c: Ooh, format changed from unknown to alaw
> [May 26 06:25:45] DEBUG[28291] rtp.c: Created smoother: format: 8 ms: 20 len: 160
> [May 26 06:25:45] DEBUG[28291] rtp.c: Got RTCP report of 52 bytes
> ... and RTP is happily running.

If you can, try adding an Answer().  It seems to work around the issue for me.

> These debugs were created by calling this extension:
> exten => 13006,1,Macro(stdserv,0,"Ring Tone Check")
> exten => 13006,n,Proceeding()
> exten => 13006,n,Wait(1)
> exten => 13006,n,Progress()
> exten => 13006,n,Wait(1)

exten => 13006,n,Answer()

> exten => 13006,n,Ringing()
> exten => 13006,n,Wait(60)
> exten => 13006,n,Hangup()

In my specific case adding the Answer doesn't hurt anything.

-Jonathan