On Thu, Feb 20, 2020 at 8:41 AM Abhay Gupta <ab...@avissol.com> wrote:
> Hi > > > > In case of issue manager event of BridgeDestroy does not come and as seen > it never enters the destroy_bridge() function . > > > > [Feb 20 15:33:07] DEBUG[25464] http.c: HTTP Request URI is > /ari/bridges/1029 > [Feb 20 15:33:07] DEBUG[25464] http.c: match request [ari/bridges/1029] > with handler [httpstatus] len 10 > [Feb 20 15:33:07] DEBUG[25464] http.c: match request [ari/bridges/1029] > with handler [phoneprov] len 9 > [Feb 20 15:33:07] DEBUG[25464] http.c: match request [ari/bridges/1029] > with handler [static] len 6 > [Feb 20 15:33:07] DEBUG[25464] http.c: match request [ari/bridges/1029] > with handler [ari] len 3 > [Feb 20 15:33:07] DEBUG[25464] http.c: Match made with [ari] > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Finding handler for bridges/1029 > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Finding handler for bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari > applications: Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari > deviceStates: Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari asterisk: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari recordings: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari sounds: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari endpoints: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari events: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari playbacks: > Didn't match bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking ari bridges: > Explicit match with bridges > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Finding handler for 1029 > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: Checking bridges > bridgeId: Matched wildcard. > [Feb 20 15:33:07] DEBUG[25464] res_ari.c: No explicit handler found for > 1029. Using wildcard bridgeId. > [Feb 20 15:33:07] DEBUG[25464] bridge.c: Bridge 1029: telling all channels > to leave the party > [Feb 20 15:33:07] DEBUG[25464] bridge.c: Bridge 1029: dissolving bridge > with cause 16(Normal Clearing) > [Feb 20 15:33:07] DEBUG[25464] bridge.c: Bridge 1029: queueing action > type:13 sub:1001 > > > > In case where it is successfully deleted > > > > [Feb 20 15:34:30] DEBUG[29018] bridge.c: Bridge 1013: telling all channels > to leave the party > > [Feb 20 15:34:30] DEBUG[29018] bridge.c: Bridge 1013: dissolving bridge > with cause 16(Normal Clearing) > > [Feb 20 15:34:30] DEBUG[29018] bridge.c: Bridge 1013: queueing action > type:13 sub:1001 > > [Feb 20 15:34:30] DEBUG[4070][C-000019bf] bridge.c: Bridge 1013: actually > destroying stasis bridge, nobody wants it anymore > > [Feb 20 15:34:30] DEBUG[29018] http.c: HTTP keeping session open. > status_code:204 > > [Feb 20 15:34:30] DEBUG[4070][C-000019bf] bridge.c: Bridge 1013: calling > stasis bridge destructor > > [Feb 20 15:34:30] DEBUG[4070][C-000019bf] bridge.c: Bridge 1013: calling > simple_bridge technology stop > > [Feb 20 15:34:30] DEBUG[4070][C-000019bf] bridge.c: Bridge 1013: calling > simple_bridge technology destructor > Destruction is an asynchronous operation. Are you depending on it being synchronous, and it actually does complete but just after a period of time? -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and 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
