| 00:00.13 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:c82e:eb6f:1b73:fc06) |
| 00:00.24 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-vexjteqbwdaopyth) |
| 01:30.37 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:49.36 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-rnzznkzdeyxskkjn) |
| 06:34.27 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 06:53.15 | *** join/#asterisk-dev oej (~oej@static-213-115-76-42.sme.bredbandsbolaget.se) |
| 06:53.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:58.32 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:15.25 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:c82e:eb6f:1b73:fc06) |
| 10:55.29 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:c82e:eb6f:1b73:fc06) |
| 11:27.00 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 11:35.50 | WIMPy | The "Asterisk 11 AMI Events"-page on the wiki is missing the "channelreload" and "reload" events. And "Asterisk 11 ManagerEvent_DNDState" has its contents doubled. Do you want an issue for that? |
| 11:36.22 | WIMPy | And the "Bridge" event seems to always report "Bridgetype: core" even if it's a native bridge. |
| 11:36.36 | file | sure |
| 11:36.50 | WIMPy | ok |
| 11:37.10 | file | although those are produced from the source code, so they can be contributed in the form of a submission otherwise someone else will get to them eventually |
| 11:40.17 | WIMPy | Erm. The documentation type of issue seems to have vanished. |
| 11:41.35 | file | there's never been a documentation type |
| 11:42.15 | file | it's a Bug and then Documentation component |
| 12:09.25 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:31.08 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 12:40.18 | *** join/#asterisk-dev mjordan_ (mjordan@nat/digium/x-mgsvpxkpalpnopjy) |
| 12:40.18 | *** mode/#asterisk-dev [+o mjordan_] by ChanServ |
| 12:49.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:09.08 | WIMPy | Looks like the Bridgetype has never been implemented. All calls to manager_bridge_event have a constant 1 as type. |
| 13:19.26 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 13:24.04 | WIMPy | struggle to find anythign that might indicate if a bridge is a native bridge anywhere. |
| 13:30.26 | file | older versions didn't really have much info, 13+ does |
| 13:31.44 | WIMPy | 13 may have to write til next life :-( |
| 13:32.08 | WIMPy | Is the result of finding a native bridge really not stored anywhere? |
| 13:33.01 | file | in 11 and below a native bridge isn't found, and there isn't much bridge state or information at all |
| 13:33.27 | WIMPy | But somewhere it has to find out what kind of bridge to use. |
| 13:33.37 | file | it's a pointer on the channel technology |
| 13:33.57 | file | which the main bridge function uses |
| 13:34.13 | WIMPy | Yes, I know that one. |
| 13:46.39 | WIMPy | Is it just a case of a simple ast_channel_tech(c0)->bridge == ast_channel_tech(c1)->bridge? |
| 13:47.55 | file | that tells you if they are compatible, looking at the AST_FLAG_NBRIDGE flag on the channel may tell you if it's in a native bridge |
| 13:49.27 | WIMPy | hunts that one. |
| 13:50.51 | WIMPy | Ok. Bad thing. That is set long after the bridge event is sent. |
| 13:51.44 | file | entirely possible |
| 13:58.45 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-fekldqtxjoogiwpf) |
| 14:05.40 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 14:12.48 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 14:12.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:34.17 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-hzkxgovsqwjjbmqb) |
| 14:34.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:43.10 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 14:45.50 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-dwcpbyvpczxtckuk) |
| 14:46.00 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:46.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:01.51 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:01.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:06.41 | *** join/#asterisk-dev opticron (~opticron@75.76.201.152) |
| 15:06.41 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 15:08.53 | WIMPy | Ok, I think I've got it, but I got some questions regarding desired behaviour. |
| 15:10.17 | WIMPy | With what I've got now, a failed attempt to set up a native bridge would first send a bridge/link/native event and then a bridge/link/core event. The 2nd message would be easy to supress. |
| 15:11.08 | file | changing messages is not acceptable in 11 |
| 15:11.34 | WIMPy | Also so far if a bridge cannot be set up it would generate a bridge/link and a bridgeunlink event. Does that make sense? |
| 15:12.13 | WIMPy | Well, the current situation does not comply with the documentation. So isn't it a bug? |
| 15:12.32 | file | that doesn't matter, changing messages WILL break things |
| 15:12.39 | file | and that CAN NOT happen in a release branch |
| 15:14.15 | WIMPy | The other option would be to insert a bridge/unlink message in between. That way there's no change to what could happen anyway. |
| 15:14.39 | WIMPy | couldn't |
| 15:15.05 | WIMPy | wonders is that correction made sense. |
| 15:50.15 | *** join/#asterisk-dev dms1 (~dms1@162.207.112.26) |
| 15:55.35 | stefan27 | The sip channel leak i mentioned yesterday actually happend on a non-clean asterisk (I should have checked that first) so it's not a real issue |
| 15:56.49 | file | WIMPy, I don't... know... |
| 15:56.56 | file | stefan27, as a result of the changes? |
| 16:01.08 | stefan27 | yes, it's an legacy patch created for asterisk1.2 6 years ago by someone else but I migrated this patch to a asterisk13 because I thought I still needed the functionality, but it seems to do something bad: http://pastebin.com/sWWRgLh1 |
| 16:01.43 | stefan27 | is it the case that when you call peer = ast_channel_bridge_peer(chan) you bump the ref-count for peer or something? |
| 16:02.27 | stefan27 | (that pastebin is not in patch-format, it's a copy-paste from main/bridge.c post patch) |
| 16:05.19 | stefan27 | the transferer channel is never cleared when i added those 4 lines in the else clause, when i removed those 4 lines, the leak disappeared |
| 16:15.18 | stefan27 | Hmm, it seems ast_channel_ref(peer) is called somewhere within ast_channel_bridge_peer(). That means I should call ast_channel_unref(peer) when I'm done copying data from the peer fetched from peer = ast_channel_bridge_peer(chan)? |
| 16:24.11 | file | yes, you must the reference |
| 16:34.01 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 17:02.10 | stefan27 | Is that the meaning of the doxygen-doc for ast_channel_bridge_peer "Return values: ... non-NULL ***Reffed*** peer channel at time of calling.'". I guess I have to get more accustomed to the general 'contracts' of the asterisk internal functions. |
| 17:03.58 | file | yes |
| 17:06.49 | stefan27 | OK yeah that fixed it, thanks |
| 17:06.49 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 17:07.19 | file | yay for not being a bug in mainline |
| 17:07.23 | file | boo for your patch :P |
| 17:09.20 | stefan27 | the design of that patch wasn't really mine, someone else wrote that patch to make a certain dialplan-idea work in the case of DTMF-transfers |
| 17:10.19 | stefan27 | yeah my only remaining mainline jiras are those obscure pjnath ones that are hard to debug |
| 17:11.16 | stefan27 | other than that asterisk13.5 is very stable compared to the old asterisk1.2. 99% asterisk installations have 180+ days uptime |
| 17:12.05 | stefan27 | only those that use webrtc still have occasional crashes but only within stun now, not dtls anymore |
| 17:13.55 | file | go go dtls fixes |
| 17:14.25 | WIMPy | How do I make a verbose make with dahdi? |
| 17:15.36 | stefan27 | I wish Dade Brandon would write some update in the pjnath-department, he has better user-base and debugdata than me, and he even had some ideas what might be wrong within pjnath (or of asterisk's calling of it) |
| 17:23.03 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:c82e:eb6f:1b73:fc06) |
| 17:24.52 | stefan27 | have a nice weekend! |
| 18:28.01 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 19:26.14 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:26.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:45.48 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:18.29 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-fekldqtxjoogiwpf) |
| 22:58.24 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:9dce:5a9:846f:45cd) |