|Summary:||ASTERISK-19985: Bridge - not always returning to the right context,priority,extension as it should.|
|Reporter:||Maciej Krajewski (jamicque)||Labels:|
|Date Opened:||2012-06-12 07:44:12||Date Closed:||2012-06-25 11:05:20|
|Environment:||Attachments:||( 0) asterisk.log|
( 1) jira_asterisk_19985_v1.8.patch
|Description:||I've made a simple program which is calling to the firs user (test001), who is dialling local channel (I want him to be "on phone" all the time), after this originate made through AMI connects the new calls (in example made to user test002) with the local channel of test001 user via Bridge command. After the dialled user hangs up the first user (test001) goes to MOH.|
What I found out is that after some calls (sometimes 3, sometimes 30) after the hangup of dialled user, the test001 user does not go to MOH but on hangup.
You can see in attached logs that usually after the bridge ends, there is a log stating:
"features.c: starting new PBX in CC,park,3 for chan Local/12@CC-be4b;2"
but sometimes there is:
"features.c: starting new PBX in CC,h,6 for chan Local/12@CC-be4b;2"
after this log the test001 user is disconnected.
I've tried to pass this problem by. However it seems that the returning context,priority,extension after the bridge is sometimes misplaced.
I've attached the full logs.
|Comments:||By: Maciej Krajewski (jamicque) 2012-06-12 09:14:20.885-0500|
I've found out that sometimes the final_dest_chan is taken from zombie channel
By: Maciej Krajewski (jamicque) 2012-06-13 05:23:18.909-0500
I think that it might be connected to ASTERISK-18975
By: Richard Mudgett (rmudgett) 2012-06-22 13:14:11.497-0500
[^jira_asterisk_19985_v1.8.patch] should fix the race condition.
The code must not touch a clone channel after it has masqueraded it. The clone channel has become a zombie and is starting to hangup.
The code was getting the resume location from the zombie channel.
By: Maciej Krajewski (jamicque) 2012-06-25 03:28:50.088-0500
The patch fixed the issue