[Home]

Summary:ASTERISK-11222: app_channelredirect relies on ast_parseable_goto which fails to redirect channels
Reporter:Johan Wilfer (johan)Labels:
Date Opened:2008-01-12 16:43:37.000-0600Date Closed:2008-02-18 09:43:36.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_channelredirect
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:It seems like ChannelRedirect isn't working very well in trunk. I patched ChannelRedirect to report the status in bug 0011553 for asterisk 1.4-trunk.
When I was porting this patch to trunk I stumbled on this issue.

The source av ast_parseable_goto that seems to fail even if there is a vaild channel and destination. I have tested the following scenarious:
I place call #1 in either MusicOnHold(), Meetme(), Playback() then I've a call #2 that makes a Channelredirect(call-numer-1-channelname,newcontext,newexten,1)
This always fails.

However if you do a core show channels after this unsucessful redirect you will se:
Channel              Location             State   Application(Data)
Zap/pseudo-598993578 s@default:1          Rsrvd   (None)
SIP/callnumer1-08222 s@newcontext:0       Up      MeetMe(1,dm)

Note the newcontext:0...

And in the case you redirect channel #1 where it does a Playback() the redirect will occur after the Playback is finished. This will not happen with the other applications thou.

Maybe I'm making a misstake, but this confuses me a lot...
Comments:By: Joshua C. Colp (jcolp) 2008-01-14 13:50:11.000-0600

Do you mean in Asterisk 1.4 or Asterisk trunk? They are two separate branches, and I just tested trunk and it behaves fine.
By: Johan Wilfer (johan) 2008-01-14 15:49:16.000-0600

I mean trunk. I was asked to port my patch in 0011553 to trunk and had a lot of problems - related to this. After some testing I realized that this behaviour was the same before my patch.

First I tested it on trunk running under Xen (no Zaptel available) thinking it was a Zaptel issue... Then I tried it on another machine with the same results.

If you want to I can pull together my extensions.ael and configuration. Maybe I use the application wrong - I've looked through upgrade and changes and found nothing about changed syntax...

I you have the opportunity to look into 0011553 and try this patch it should be great - however I've always run into the problems described in this bug while trying to port it to trunk (it works perfectly for 1.4-trunk thou).

Meanwhile I will update to the latest trunk and trying to reproduce the error one more time.


By: Johan Wilfer (johan) 2008-01-30 19:57:28.000-0600

I've tried this once again hoping I was mistaken.

I checked out revision SVN-trunk-r101344
and tried the following extensions.ael

context catchall {
       _X. => {
               Answer();
               Wait(1);
               Wait(888);
              }
}
context test {
       s => {
               Answer();
               Wait(1000);
            }
}

After having one call waiting in Wait(888) I added the following row before Wait(888), and of course SIP/xxxx has to be replaced with a valid channelname in your system, in mine this is the first call:
               ChannelRedirect(SIP/0303350971-082294c8,test,s,1);

Then I called in on another phone.
The output, starting with the first call, was the following:
   -- Executing [0303350971@catchall:1] Answer("SIP/0303350971-082294c8", "") in new stack
   -- Executing [0303350971@catchall:2] Wait("SIP/0303350971-082294c8", "1") in new stack
   -- Executing [0303350971@catchall:3] Wait("SIP/0303350971-082294c8", "888") in new stack
mio*CLI> ael reload

<snip ael reload, second call:>

mio*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/0303350971-08229 0303350971@catchall: Up      Wait(888)
1 active channel
1 active call
1 call processed
 == Using SIP RTP CoS mark 5
   -- Executing [0303350971@catchall:1] Answer("SIP/0303350971-0822ea30", "") in new stack
   -- Executing [0303350971@catchall:2] Wait("SIP/0303350971-0822ea30", "1") in new stack
   -- Executing [0303350971@catchall:3] ChannelRedirect("SIP/0303350971-0822ea30", "SIP/0303350971-082294c8,test,s,1") in new stack
   -- Executing [0303350971@catchall:4] Wait("SIP/0303350971-0822ea30", "888") in new stack
mio*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/0303350971-0822e 0303350971@catchall: Up      Wait(888)
SIP/0303350971-08229 s@test:0             Up      Wait(888)
2 active channels
2 active calls
2 calls processed
mio*CLI> core show version
Asterisk SVN-trunk-r101344 built by root @ mio on a i686 running Linux on 2008-01-31 01:43:24 UTC


By: Digium Subversion (svnbot) 2008-02-04 09:13:25.000-0600

Repository: asterisk
Revision: 102272

U   trunk/main/pbx.c

------------------------------------------------------------------------
r102272 | file | 2008-02-04 09:13:23 -0600 (Mon, 04 Feb 2008) | 6 lines

Update handling of asyncgoto so it properly works on channels that are currently executing a PBX.
(closes issue ASTERISK-11367)
Reported by: arnd
(closes issue ASTERISK-11222)
Reported by: johan

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=102272
By: Johan Wilfer (johan) 2008-02-04 19:12:35.000-0600

Still broken.

If do a asyncgoto on a line that do Wait(1000) to a place that do playback(somefile). Then the CLI will show the correct context / priority BUT still do execute Wait insted of Playback.

mio*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/0303350971-0822a beeping@test:1       Up      Wait(888)

In this paticular case I've done a ChannelRedirect on a channel that sits and wait(888) to beeping in the context test that looks like:
   while (true) {
       Playback(demo-congrats);
   }


By: jmls (jmls) 2008-02-17 14:37:54.000-0600

file, seems as if it is still broken ...
By: Digium Subversion (svnbot) 2008-02-18 09:43:35.000-0600

Repository: asterisk
Revision: 103765

U   trunk/apps/app_channelredirect.c
U   trunk/include/asterisk/pbx.h
U   trunk/main/pbx.c

------------------------------------------------------------------------
r103765 | file | 2008-02-18 09:43:33 -0600 (Mon, 18 Feb 2008) | 4 lines

Add an API call (ast_async_parseable_goto) which parses a goto string and does an async goto instead of an explicit goto.
(closes issue ASTERISK-11222)
Reported by: johan

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=103765