Again back to 'basic-bridge' exited non-zero

Asterisk Asterisk Support
1

Hello,

This “Basic-bridge exited non-zero” title appears to be an old post in Digium forum created in 2016 from @comfine probably (I apologize if the user is not the same anyway) :

https://forums.asterisk.org/viewtopic.php?f=14&t=96509&start=0&sid=8264604a716bb2e92bbe8904de4e646d

Unfortunately this forum seems to be inactive and I had no opportunity to contact or reply there to ask if finally someone solve it or not.

In any case, for those cannot follow the above link, the issue is that you are experiencing random drop on your calls. Incoming or outgoing does not matter. And the debugging shows as following:

    -- Channel SIP/+XXXXXXXXXXXX-00000040 left 'simple_bridge' basic-bridge <a2253316-9659-48f1-8a97-68ffe0e32245>
    -- Channel SIP/191-00000046 left 'simple_bridge' basic-bridge <a2253316-9659-48f1-8a97-68ffe0e32245>
  == Spawn extension (macro-dial, s, 22) exited non-zero on 'SIP/+XXXXXXXXXXXX-00000040' in macro 'dial'
Scheduling destruction of SIP dialog '0f095c225479f39057fe9c783f02e850@192.168.0.78:5060' in 6400 ms (Method: INVITE)
  == Spawn extension (ext-group, 1234567, 18) exited non-zero on 'SIP/+XXXXXXXXXXXX-00000040'
    -- Executing [h@ext-group:1] Macro("SIP/+XXXXXXXXXXXX-00000040", "hangupcall,") in new stack

Drops caused completely randomly. But in almost every call. I’m using Freepbx 14 and Asterisk 13

Any suggestion welcomed

2

Drop calls could be caused by many reasons, like session timer, NAT issue, RTP time out

3

Although the most common cause is that the call was cleared by the peer!

4

For sure NORMAL_CLEARING it is the most common, but this wont be consider an issue at least not on the Asterisk side, I think a SIP trace here is needed to see the real reason of the session termination

5

Most of the cases I’ve seen, reported as an issue, here, have turned out to be normal clearing from the peer. The exited non-zero message looks scary, when it is completely normal.

1 Like
7

You are going to need to turn up the debugging level (and enable the full log), as I can see no reason for the call to drop out of the bridge in the current logs.

9

And uncomment full in logger.conf

10

Thank you so much for your interest guys. Please find a full debug log I put on a google drive…

full.txt

As I see, normal clearing seems to be the reason as @david551 and @ambiorixg12 :

[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge_channel.c: Setting 0x7ff7700223e8(SIP/+XXXXXXXXXX61-00000050) state from:0 to:1
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge_channel.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: pulling 0x7ff7700223e8(SIP/+XXXXXXXXXX61-00000050)
[2018-11-01 14:04:03] VERBOSE[25427][C-00000015] bridge_channel.c: Channel SIP/+XXXXXXXXXX61-00000050 left ‘simple_bridge’ basic-bridge
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge_channel.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: 0x7ff7700223e8(SIP/+XXXXXXXXXX61-00000050) is leaving simple_bridge technology
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: dissolving bridge with cause 16(Normal Clearing)
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge_channel.c: Setting 0x7ff7700a81e8(SIP/201-00000056) state from:0 to:2
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: queueing action type:13 sub:1001
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c is dissolved, not performing smart bridge operation.
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] app_dial.c: Exiting with DIALSTATUS=ANSWER.
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] app_macro.c: Spawn extension (macro-dial,s,22) exited non-zero on ‘SIP/+XXXXXXXXXX61-00000050’ in macro ‘dial’
[2018-11-01 14:04:03] VERBOSE[25427][C-00000015] app_macro.c: Spawn extension (macro-dial, s, 22) exited non-zero on ‘SIP/+XXXXXXXXXX61-00000050’ in macro ‘dial’
[2018-11-01 14:04:03] DEBUG[25427][C-00000015] pbx.c: Spawn extension (ext-group,5131461,18) exited non-zero on ‘SIP/+XXXXXXXXXX61-00000050’
[2018-11-01 14:04:03] VERBOSE[25427][C-00000015] pbx.c: Spawn extension (ext-group, 5131461, 18) exited non-zero on ‘SIP/+XXXXXXXXXX61-00000050’
[2018-11-01 14:04:03] DEBUG[1409] cdr.c: Finalized CDR for SIP/+XXXXXXXXXX61-00000050 - start 1541073009.387293 answer 1541073011.147664 end 1541073843.632981 dispo ANSWERED
[2018-11-01 14:04:03] DEBUG[1422] res_odbc.c: Reusing ODBC handle 0x7ff744000f08 from class ‘asteriskcdrdb’
[2018-11-01 14:04:03] DEBUG[1422] cel_odbc.c: Executing SQL statement: [INSERT INTO cel (eventtype, eventtime, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, uniqueid, linkedid, peer, userdeftype, extra) VALUES (‘BRIDGE_EXIT’, {ts ‘2018-11-01 14:04:03.631550’}, ‘Le Pi’, ‘+XXXXXXXXXX57’, ‘+XXXXXXXXXX57’, ‘’, ‘+XXXXXXXXXX00’, ‘s’, ‘macro-dial’, ‘SIP/+XXXXXXXXXX61-00000050’, ‘Dial’, ‘SIP/114&SIP/124&SIP/134&SIP/144&SIP/175&SIP/181&SIP/191&SIP/201,25,HhtrM(auto-blkvm)b(func-apply-sipheaders^s^1),’, 3, ‘’, ‘1541073006.80’, ‘1541073006.80’, ‘SIP/201-00000056’, ‘’, ‘{“bridge_id”:“a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c”,“bridge_technology”:“simple_bridge”}’)]
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge_channel.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: pulling 0x7ff7700a81e8(SIP/201-00000056)
[2018-11-01 14:04:03] VERBOSE[25444][C-00000015] bridge_channel.c: Channel SIP/201-00000056 left ‘simple_bridge’ basic-bridge
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge_channel.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: 0x7ff7700a81e8(SIP/201-00000056) is leaving simple_bridge technology
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c is dissolved, not performing smart bridge operation.
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] res_rtp_asterisk.c: Changing ssrc from 312725294 to 327649964 due to a source change
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: actually destroying basic bridge, nobody wants it anymore
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: calling basic bridge destructor
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: calling simple_bridge technology stop
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] bridge.c: Bridge a34ddcbe-5ee7-43d3-a359-cdf70c8ba17c: calling simple_bridge technology destructor
[2018-11-01 14:04:03] DEBUG[25444][C-00000015] channel.c: Channel 0x7ff77008dd98 ‘SIP/201-00000056’ hanging up. Refs: 2

But how can I fix this bloody event?

Thanks in advance for your time

11

I can’t find your extract in full.txt!

12

sip trace it is needed to verify on the SIP session, who cleared the call and why

13

Really apologies guys. Check this one

full2.txt

I think I opened all possible debug levels this time. Please let me know

BTW…

What I’ve noticed as well is this:

Reason: Q.850;cause=31,SIP;text=“S.ims.otenet.gr.261.011.310.00045 CSCF released the session because of USER DEREGISTRATION”

And I am thinking IF the problem …could be also… that my accounts (one main number + 5 more msn numbers) are keeping registering at the same provider AND under the same SIP account-credentials during an active call… Then, maybe REGISTER and DEREGISTER cannot be handled correctly on multiple trunks that they are using the same SIP account… :face_with_raised_eyebrow:

Any thoughts about this???

14

My thought in my last reply was right :face_with_raised_eyebrow:

Finally the issue I had with randomly dropped calls seems to be fixed when I deleted all msn numbers I had declared as separated SIP trunks. I just left only my main SIP trunk account and I use my msn numbers as separate DIDs for inbound/outbound routes.

Thanks anyway all guys for your time and especially @david551 and @ambiorixg12

1 Like
15

I’m having the same logs and the same issue with inbound calls.
I have eight ATA lines (obihai) connected to my PBX and they are the only Trunks that are active. I had about nine extensions ring on incoming calls using a ring group.

I’m not sure I understand what your solution was. Could you elaborate on it?
What do you mean by msn numbers? Do you mean you had +5 extensions in one ring group?