| 00:20.22 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:20.22 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.20.0 (2018/03/15), Standard: 15.3.0 (2018/03/15); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 01:44.18 | *** join/#asterisk zmisc (~zcm@unaffiliated/zmisc) |
| 01:45.09 | [J]oules | still don't get any symbols in the output of this |
| 01:45.29 | [J]oules | gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core.host.domain.tld-2018-04-21T00:47:09-0400 > /tmp/backtrace.txt |
| 02:57.34 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.100) |
| 03:55.46 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 03:56.32 | *** join/#asterisk beachdog (~beachdog@mobile-166-176-56-67.mycingular.net) |
| 05:02.03 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 07:06.04 | *** join/#asterisk rpifan (~rpifan@45.77.193.213) |
| 07:06.05 | rpifan | hi |
| 07:07.35 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 07:37.02 | *** join/#asterisk miralin (~Thunderbi@194.8.128.51) |
| 08:18.13 | *** join/#asterisk sibyakin (~sibyakin@188.162.238.100) |
| 08:38.11 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 10:41.46 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:32.25 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.28) |
| 12:08.32 | *** join/#asterisk chiggins (~chiggins@unaffiliated/chiggins) |
| 12:28.10 | *** join/#asterisk andresmujica (~andresmmu@ubuntu/member/andresmujica) |
| 13:47.16 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 13:55.33 | *** join/#asterisk wdoekes (~walter@wjd.osso.nl) |
| 13:55.33 | *** mode/#asterisk [+o wdoekes] by ChanServ |
| 14:12.13 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 14:47.24 | *** join/#asterisk Eloy (~Eloy@195.191.28.250) |
| 15:24.13 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
| 15:25.03 | *** join/#asterisk CatCow97 (~mine9@c-24-22-38-85.hsd1.or.comcast.net) |
| 15:42.40 | *** join/#asterisk Typhon (~Typhon@ipservice-092-211-215-022.092.211.pools.vodafone-ip.de) |
| 15:48.31 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 15:55.05 | *** join/#asterisk Eloy (~Eloy@83.136.43.12) |
| 15:57.14 | *** join/#asterisk Gugge_ (gugge@92.246.2.105) |
| 16:06.49 | *** join/#asterisk gringo (~gringo@unaffiliated/gringo) |
| 16:16.03 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:5c36:7044:abeb:368a) |
| 16:16.20 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 16:25.29 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 16:25.29 | *** join/#asterisk nathani (~nathani@2607:f2f8:ac88::) |
| 16:25.29 | *** join/#asterisk Martin` (~martin@shell.ipv6.octocore.net) |
| 16:30.44 | *** join/#asterisk justinmrkva (~justinmrk@unaffiliated/justinmrkva) |
| 16:31.32 | *** join/#asterisk J0hnSteel (~J0hnSteel@62.162.164.77) |
| 16:34.23 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 16:36.33 | *** join/#asterisk Eloy (~Eloy@83.136.45.12) |
| 16:42.51 | *** join/#asterisk nathani (~nathani@fire.mnathani.com) |
| 16:51.05 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:07.00 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 17:28.05 | *** join/#asterisk miralin (~Thunderbi@194.8.128.51) |
| 17:28.47 | *** join/#asterisk bmg505 (~leon@196-210-25-57.dynamic.isadsl.co.za) |
| 17:31.33 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:49.04 | *** join/#asterisk pushpop (~pushpop@unaffiliated/pushpop) |
| 17:49.25 | pushpop | Is it possible to use Asterisk with Cisco 8851 phones? How do you provision them? |
| 18:19.19 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 18:35.00 | *** join/#asterisk Typhon (~Typhon@ipservice-092-211-215-022.092.211.pools.vodafone-ip.de) |
| 18:44.15 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:5c36:7044:abeb:368a) |
| 18:50.14 | *** join/#asterisk Oooohboy (~Oooohboy@cpe-67-11-10-120.satx.res.rr.com) |
| 19:33.43 | *** join/#asterisk z3ntu (z3ntumatri@gateway/shell/matrix.org/x-qvtqylqgdpbfffpg) |
| 19:47.55 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 19:49.35 | *** join/#asterisk moreentropy (markuslind@gateway/shell/matrix.org/x-unzovvoqulmytugn) |
| 19:55.47 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 19:59.16 | *** join/#asterisk Qwell (~north@asterisk/developer/Qwell) |
| 19:59.16 | *** mode/#asterisk [+o Qwell] by ChanServ |
| 20:00.21 | *** join/#asterisk s-mutin (~s-mutin@85.234.114.134) |
| 21:01.15 | jkroon | res_pjsip_transport_management.c:133 idle_sched_cb: Shutting down transport 'TCP to 165.16.204.170:39489' since no request was received in 32 seconds |
| 21:01.34 | jkroon | that can't be right? There is an active registration on that connection - surely shutting it down is a bad thing? |
| 21:03.23 | file | if a request flowed over that connection it wouldn't be shutdown |
| 21:04.07 | jkroon | ok, so after initial register, won't the phone just sit there waiting for incoming INVITE, or when it has call to make out send an INVITE on the connection? |
| 21:04.28 | file | yes, but the message you provided only shows up if absolutely no traffic flowed over it |
| 21:04.50 | jkroon | interesting ... |
| 21:05.18 | jkroon | ok, so if the phone sent even REGISTER over it, and then stayed idle the above would not happen? |
| 21:05.40 | file | right. |
| 21:06.18 | jkroon | and for a TCP connection that would be kinda a requirement ... if TCP connection breaks, re-establishes, and re-registers. will have to report this one to Yealink then. |
| 21:06.37 | jkroon | thanks file. |
| 21:09.23 | *** join/#asterisk tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 21:13.01 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 21:13.08 | jkroon | it's rather amazing. new host on the internet, never run SIP before, less than a week live and as I'm sitting here I'm seeing 5 separate IP addresses probe for usernames and passwords ... (there are none, really just looking for info on how these probes function ... and what exactly asterisk's security stuff reports). |
| 21:15.39 | Samot | They scan blocks |
| 21:15.44 | Samot | Not one at a time |
| 21:19.39 | jkroon | Samot, so what i've gathered so far is I'm ONLY seeing IPV4 probes, I presume they scan blocks to look for open ports on 5060, once found they seem to start hammering them with sequencial 3 and 4 digit extensions, presumably with typical passwords. |
| 21:19.48 | jkroon | some remote hosts are more aggressive than others. |
| 21:22.12 | Samot | Sounds right |
| 21:22.16 | Samot | This is common |
| 21:22.18 | jkroon | so far the probes also only seem to care about udp, not tcp either. |
| 21:22.44 | jkroon | Samot, based on what I've seen in the last 30 minutes I'm surprised there aren't more incidents of compromised sip hosts. |
| 21:28.31 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 22:07.15 | *** join/#asterisk mutin-s (~s-mutin@85.234.114.134) |
| 22:15.37 | dan_j | I'm trying to put 19 members into a queue. However, when a call comes in and asterisk dials, it doesn't handle it very well. The caller starts hearing the music on hold but it's distorted while the 19 calls are dialled. Is there any way to slow down the dialling to make it handle things a little better? Maybe delay 500ms in between each call setup to allow for more graceful performance? |
| 22:16.50 | dan_j | Note that the 'members' being added into the queue are in fact Local channels which then dial a mobile number on a PJSIP trunk. |
| 22:21.21 | [TK]D-Fender | You shold already know your answer for this |
| 22:21.33 | [TK]D-Fender | if you want to delay them .. then delay them. Its your dialplan... |
| 22:24.02 | dan_j | My dialplan isn't starting the dialling process. I'm just sending the call to Queue() in the dialplan. Then Queue() is just dumping calls to the 19 local channels. I can change the code in the Local channels but have no way to knowing what the delay should be as it's the same Local channel dialplan, just with different EXTEN. |
| 22:24.05 | dan_j | 1sec |
| 22:24.46 | dan_j | https://www.irccloud.com/pastebin/ZgkQbgpn/ |
| 22:25.23 | dan_j | That's my Local dialplan, and this is an example of a queue member. LOCAL/MOBILE_NUMBER_HERE@queue_outgoing_press1 |
| 22:25.34 | [TK]D-Fender | So go do something different |
| 22:25.59 | [TK]D-Fender | You don't get to say "it just the same thing". Go choose to do something different |
| 22:26.42 | [TK]D-Fender | maybe make it a RANDOM delay. Maybe keep a counter that gets incremented to determine the delay time |
| 22:27.07 | [TK]D-Fender | Maybe change what you dial so you can determine that automatically |
| 22:28.23 | dan_j | Ok. However, if Asterisk is scale-able, I thought there might be a built-in way to slow down the Queue's dialling process when it spins up the outbound calls to queue members. |
| 22:28.30 | dan_j | hence my original query. |
| 22:28.42 | dan_j | before i start trying to 'bake my own' workaround |
| 22:28.48 | [TK]D-Fender | "if Asterisk is scale-able" <- that doesn't mean or imply anything |
| 22:29.08 | [TK]D-Fender | next there is no such thing as "outbound" |
| 22:29.12 | [TK]D-Fender | a call is a call is a call |
| 22:29.16 | dan_j | ie. surely asterisk is intended to handle more than 19 agents in a queue? |
| 22:29.29 | dan_j | without causing performance issues |
| 22:29.29 | [TK]D-Fender | Who says * is what can't handle it? |
| 22:29.56 | [TK]D-Fender | Maybe your link has issues |
| 22:30.01 | [TK]D-Fender | maybe your provider has issues |
| 22:30.09 | dan_j | nah |
| 22:30.13 | [TK]D-Fender | Some other piece involved |
| 22:32.08 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 22:42.09 | [TK]D-Fender | Where do you see anyone else reporting issues matching your secnario? You don't get to just say "nah". There are lots of people running far larger setups than yours who would have run into this |
| 22:46.12 | dan_j | when I said 'nah', i was responding to the provider comment |
| 22:46.43 | dan_j | they handle too many calls for me to have run into an unidentified issue. |
| 22:47.37 | [TK]D-Fender | Go look at your own server and networking load |
| 22:51.00 | dan_j | I'm using phpagi to look up the client's account balance on a mysql server running on the same machine. I'm going to remove the agi and just do it in the dialplan which might help. |
| 22:51.17 | dan_j | But it's the middle of the night and everything is idle apart from my tests. |
| 22:52.44 | [TK]D-Fender | What AGI? |
| 22:52.52 | dan_j | phpagi |
| 22:52.58 | [TK]D-Fender | WHERE? |
| 22:53.04 | [TK]D-Fender | You never showed anything using that |
| 22:53.17 | dan_j | [outgoing] |
| 22:54.07 | dan_j | but i've used [outgoing] without a Queue and 19 dials without any performance loss. |
| 22:54.58 | [TK]D-Fender | https://www.irccloud.com/pastebin/ZgkQbgpn/ |
| 22:55.00 | [TK]D-Fender | no AGI there |
| 22:55.39 | dan_j | exten => _0[123456789].,5,Dial(LOCAL/44${EXTEN:1}@outgoing/n,,M(press1)) The AGI is in the 'outgoing' context following this dialplan. I did just say that. |
| 22:55.41 | [TK]D-Fender | Now you're also using 1 Local channel... to call ANOTHER Local channel |
| 22:55.49 | [TK]D-Fender | this is nested crap. |
| 22:55.54 | dan_j | I had to |
| 22:56.00 | [TK]D-Fender | What are you forcing * to generate ANOTHER channel? |
| 22:56.17 | [TK]D-Fender | Feel free to explain why you felt this was necessary |
| 22:58.29 | dan_j | The 'Outgoing' context handles to actual dialling. All outbound calls go back that context as it handles routing. The 'queue_outgoing_press1' context is the context used for each queue member. The macro within that allows the queue member to accept the call by pressing 1, or reject the call by simply hanging up. |
| 22:58.47 | dan_j | The 'Outgoing' context handles to actual dialling. All outbound calls go via that context as it handles routing. The 'queue_outgoing_press1' context is the context used for each queue member. The macro within that allows the queue member to accept the call by pressing 1, or reject the call by simply hanging up. |
| 22:59.20 | [TK]D-Fender | I actually should have read back to that point myself.... |
| 22:59.29 | [TK]D-Fender | Yes, that is at least valid. |
| 23:00.01 | [TK]D-Fender | That aside, still plenty of poeple running larger queues than yours, so it is still an issue of your specific circumstances |
| 23:00.27 | dan_j | I'm going to try to remove as much agi/php stuff from my outbound dialling so that asterisk deals with all that. I'll still have to performa DB lookup for each of the 19 dials to check the call credit available. |
| 23:00.28 | [TK]D-Fender | So look at system , network load, and whatever else those channels are doing that might impact it |
| 23:01.35 | dan_j | one php script just contains a few 'if' statements and changes the callerid. not sure why i used agi for that. I think it's old code that never got reviewed and replaced. |
| 23:01.55 | sibiria | or, at the least, switch to something else than PHP - it's quite cumbersome to fire up |
| 23:02.05 | sibiria | (it executes fast; starts very slowly) |
| 23:02.17 | sibiria | perl or lua are good choices for lower overhead AGI |
| 23:02.20 | sibiria | lua in particular |
| 23:02.47 | dan_j | ok. noted. I'll see what I can do with it. thanks. |
| 23:05.03 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.214) |