| 00:16.30 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 00:54.21 | *** join/#asterisk rpifan (~rpifan@p4fca2260.dip0.t-ipconnect.de) |
| 01:03.52 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-130-220.yt.northwestel.net) |
| 01:20.53 | *** join/#asterisk GameGamer43 (sid5533@gateway/web/irccloud.com/x-byjnwbntrlwbpyhf) |
| 01:20.53 | *** mode/#asterisk [+o GameGamer43] by ChanServ |
| 01:22.48 | *** join/#asterisk moy (sid47040@gateway/web/irccloud.com/x-mjgjqmifwhzmnybk) |
| 01:25.09 | *** join/#asterisk X-Rob (X-Rob@gateway/web/irccloud.com/x-hzfgkfcyajkkqcxz) |
| 02:03.05 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 02:03.09 | *** join/#asterisk idtentee (sid101023@gateway/web/irccloud.com/x-codfaughkekspfkr) |
| 02:54.07 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 03:11.15 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-ccqesvugdgiyqrgx) |
| 03:50.53 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-130-220.yt.northwestel.net) |
| 04:04.08 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 04:34.32 | *** join/#asterisk Deeewayne (~dwayne@136.53.88.111) |
| 04:48.44 | *** join/#asterisk Deeewayne (~dwayne@2605:a601:a816:5000:f7ce:535c:c78:9ec3) |
| 05:38.22 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 06:11.14 | *** join/#asterisk eXistenZ (~pectic@bzq-109-65-211-127.red.bezeqint.net) |
| 06:24.43 | *** join/#asterisk tsal (~tsal@i59F4A86F.versanet.de) |
| 06:43.34 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 07:03.47 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
| 07:17.38 | *** join/#asterisk Gugge (gugge@guggemand.dk) |
| 07:17.50 | *** join/#asterisk waldo323 (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 07:28.00 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 07:33.58 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 07:57.05 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:a1c4:95db:8644:625d) |
| 08:42.34 | *** join/#asterisk matrix1233 (~matrix123@78.250.186.66) |
| 09:24.36 | *** join/#asterisk eXistenZ (~pectic@bzq-109-65-211-127.red.bezeqint.net) |
| 09:29.44 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 10:55.21 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1156:c6f3:719e:2da6:a75d:87e4) |
| 11:05.25 | *** join/#asterisk stux16777216Away (stux2@grid9.quadspeedi.net) |
| 11:23.53 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 12:26.53 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:07.04 | *** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 13:48.36 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
| 13:55.38 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-mtwqccukgrjzbtok) |
| 13:55.39 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:15.04 | *** join/#asterisk rpifan_ (~rpifan@p200300d2671a932778a4a070c9af2117.dip0.t-ipconnect.de) |
| 14:29.08 | gruetzkopf | hey, i'm trying (for PA) to bridge audio from one party to two others - i want to discard audio going the other way |
| 14:31.29 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 14:32.13 | gruetzkopf | ah, Page() should work |
| 14:34.24 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-pwpjmvzkucpxttln) |
| 14:34.24 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:45.39 | *** join/#asterisk miralin (~Thunderbi@178.34.160.154) |
| 14:48.38 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
| 14:52.25 | igcewieling | Eternal September |
| 15:07.35 | gruetzkopf | another question: how to get at the sip url sent in the To: header |
| 15:20.29 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
| 15:24.56 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 15:32.46 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 15:35.42 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-grxrhdbzrzqxpjqz) |
| 15:36.30 | *** join/#asterisk Ryushin (~Ryushin@2001:470:4b:38f:777::8762) |
| 15:43.47 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 16:09.12 | *** join/#asterisk troggie (a90125a9@169-1-37-169.ip.afrihost.joburg) |
| 16:10.09 | troggie | hi all. I know this is a long shot but has anyone tried to get Asterisk paging and Grandstream HT814 to auto answer ? |
| 16:13.19 | drmessano | troggie: Impossible |
| 16:13.30 | troggie | oh shucks, thank you |
| 16:13.42 | drmessano | An ATA can't auto-answer |
| 16:14.00 | troggie | ah perfect, thank you so so much! |
| 16:19.54 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 16:33.54 | *** join/#asterisk vandyk (~vandyk@179.232.69.179) |
| 16:35.37 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 16:40.52 | avb | [Jun 12 18:09:26] WARNING[16176]: chan_sip.c:3782 __sip_xmit: sip_xmit of 0x7fcb542b2d00 (len 545) to 10.125.94.67:61022 returned -1: Invalid argument |
| 16:41.09 | avb | gentlemen, any hints what this is happening? breaking my head for a day |
| 16:41.46 | avb | pbx been working normaly for a year, and since yesterday its going crazy. pretty sure there is something related to the firewall |
| 16:42.06 | avb | this server have quite a bit of extensions registered and about 200 live calls |
| 16:45.11 | TandyUK | generlly i see that from either drive-by registration attempts, or TLS traffic, where the original connetion has been closed |
| 16:45.39 | TandyUK | so asterisk is trying to respond to it, but no longer has a connection to use |
| 16:45.45 | TandyUK | TCP traffic that is |
| 16:46.13 | avb | worst part is that asterisk is crashing after this |
| 16:46.24 | TandyUK | the other possibility, if you have NAT going on, is that it doesnt keep states for long enough |
| 16:46.34 | TandyUK | hmm thts bad - never had that happen personally |
| 16:46.54 | TandyUK | oh actually, im mixing shit up... |
| 16:47.38 | TandyUK | [2020-06-12 17:42:07] WARNING[14943]: chan_sip.c:3967 __sip_xmit: sip_xmit of 0x7f8a140ca840 (len 778) to a.b.c.d:12259 returned -2: Interrupted system call |
| 16:47.39 | TandyUK | [2020-06-12 17:42:07] ERROR[14943]: chan_sip.c:4456 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data |
| 16:47.50 | TandyUK | thats what i see regularly... |
| 16:48.14 | TandyUK | and... |
| 16:48.15 | TandyUK | <PROTECTED> |
| 16:48.32 | avb | yeh |
| 16:48.41 | avb | > the other possibility, if you have NAT going on, is that it doesnt keep states for long enough |
| 16:48.47 | avb | thats what im thinking |
| 16:49.10 | TandyUK | just not sure why its "invalid argument" rather than "timed out" though |
| 16:49.33 | TandyUK | unless the pbx thinks the session/state is still alive |
| 16:49.45 | avb | same here |
| 16:50.15 | TandyUK | im guessing you know what 10.125.94.67 is? |
| 16:51.51 | Samot | avb: Are you using TCP or TLS? |
| 16:52.12 | avb | thats udp |
| 16:52.22 | Samot | OK so totally different things. |
| 16:52.28 | avb | TandyUK: yes, 10.125.94.67 is a softphone |
| 16:53.07 | avb | pjproject: <?>: tsx0x7fcb48116068 .Transport error, terminating transaction. Err=120022 (Invalid argument) |
| 16:53.21 | avb | thats what fails from the pjsip (my trunk side) |
| 16:54.11 | avb | i can understand a lot, but 'Invalid argument' shows its kinda internal pbx issue |
| 16:54.15 | Samot | Wait. |
| 16:54.33 | avb | ive checked my rtp ports ranges, and i have 30k range defined |
| 16:54.38 | Samot | Chan_PJSIP is throwing transport errors and Chan_SIP is throwing transmissions errors? |
| 16:54.57 | avb | yeh |
| 16:55.23 | avb | whole load of fun :) |
| 16:55.24 | Samot | So there is something bigger going on, unless you've manage to break both SIP drivers some how. |
| 16:55.39 | avb | its a fortigate (c) |
| 16:56.01 | avb | pbx is behind a fortigate with a funny admin team who likes to play |
| 16:56.02 | Samot | But why would you think it was related to the firewall? Did you make changes to the firewall recently? |
| 16:56.10 | avb | they wont say :-D |
| 16:57.09 | avb | they say that 'nothing been changed' and then you see new subnets |
| 16:57.12 | avb | then you see new nat |
| 16:57.20 | avb | then something else, etc, etc |
| 17:00.45 | igcewieling | you can assume often those sorts of transport errors indicate the remote side is no long reachable, perhaps the source port changed or something. I'd put qualifyfreq=20 |
| 17:01.23 | igcewieling | If you switch to TCP, many NAT translation timeout problems go away. |
| 17:02.31 | avb | that might work indeed |
| 17:02.37 | avb | thank you igcewieling |
| 17:02.51 | Samot | Yo control all the endpoints right? |
| 17:06.49 | avb | yeh, i can make a switch to tcp in the provisioning |
| 17:07.27 | avb | but seems I got a better solution. ive finally managed to convience them that issue is in nat handling and we need to remove it |
| 17:08.27 | igcewieling | It is better if you don't have to trust the firewall admin to do the right things. |
| 17:08.47 | avb | you mean the tcp change? |
| 17:09.22 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 17:11.17 | igcewieling | *nod* Firewalls do things like use 60 seconds of idleness before closing UDP connections, but wait MUCH longer like an hour of idleness before closing TCP connections. |
| 17:12.28 | igcewieling | on Adtran UDP defaults to 60 seconds and TCP defaults to 600 seconds. |
| 17:13.25 | igcewieling | Make sure you open SIP TCP on your Asterisk firewall too. |
| 17:14.48 | avb | got you |
| 17:15.01 | avb | thank you gentlemen for your help |
| 17:15.08 | avb | i appreciate it |
| 17:18.14 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 17:23.13 | *** join/#asterisk gavlee (~gav@unaffiliated/gavlee) |
| 17:31.58 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 17:37.38 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:a1c4:95db:8644:625d) |
| 18:18.47 | *** join/#asterisk dacod (~dacod@177.96.148.51) |
| 18:24.21 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 18:58.03 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 19:00.29 | *** join/#asterisk dakudos (~dakudos@2607:fb90:6c2f:c1e1:e135:baef:85ad:da2d) |
| 20:57.13 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 21:01.25 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
| 22:25.59 | ilius | I hope the following doesn't apply to "Eternal September"... :) |
| 22:26.03 | ilius | I have stripped-down "border" asterisk instances that only talk to our trunk providers and my core asterisk system. All extensions are defined on the intnernal system, so there's zero threat of hanky-panky with crackers guessing a password. |
| 22:26.09 | ilius | All the border instances do is rtp audio, MixMonitor to tmpfs, and route sip signaling to and from the main system, offloading rtp with direct audio to make sure audio doesn't get dropped if the main system has high load because of app_queue or Agi blocking or whatever. |
| 22:26.28 | ilius | Until today, they were Asterisk 13 with chan_sip. Their dialplan and sip configuration is super simple -- all incoming calls go internal, out outgoing calls try several providers in turn. Most of the modules that I can turn off are turned off. I use mulaw only, no transcoding. |
| 22:26.39 | ilius | I tested Asterisk 16.8-cert2 and got it working with pjsip in a test instance and tried it in production today. The configuraion works, and pjsip works. It just doesn't seem to perform efficiently. |
| 22:26.50 | ilius | Just moving to Asterisk 16 and res_pjsip seems to have increased CPU usage by at least an order of magnitude, if not two. Before, I had enough CPU oompf to never break a sweat of 0.5 load. Now, after upgrading to 16/pjsip, each thread uses at least 5 to 15% of a vcpu core (vs 0.1 to 0.5%). |
| 22:26.52 | ilius | I tried giving the virtual machine more CPU cores, but that only made the load skyrocket more, and interestingly actual CPU usage too. |
| 22:26.59 | ilius | Is it just me, or is pjsip actually more cpu intensive with more kernel-wide SMP mutex locks? |
| 22:27.43 | ilius | These instances are just bucket passers. There should be no number crunching or other cpu bottlenecks. Take phone packet, send it to provider. Take provider packet, send it to phone. |
| 22:28.25 | Samot | Except this is a B2BUA |
| 22:28.26 | ilius | I am currently testing running one of my border instances with only a single vcpu core. Interestingly, it is doing the best I have seen 16/pjsip so far, averaging at or under about 1, with about 5 - 15 channels. |
| 22:31.33 | ilius | I have to do a centralized rtp bucket passer somewhere to be able to record calls. If not, heck, I'd just do direct rtp to the provider. |
| 22:35.27 | ilius | I don't know that this is truly pjsip and/or B2BUA... It is the RTP streams that load. Only really have 7 SIP endpoints on these machines, half of thoser are for backups/testing/monitoring. |
| 22:36.58 | sibiria | my experience with pjsip is that it's pretty lean and high-performing. your increased load might be something else |
| 22:37.57 | ilius | sibiria, that's what I'm hoping... I can find very little for optimizing rtp, so that's why I'm whining in here. :) |
| 22:39.21 | sibiria | how many calls in parallel is your SBC handling? |
| 22:39.22 | ilius | I don't know where else to look. There's not much one can to do to tune rtp streams. |
| 22:39.27 | sibiria | no more than 15? |
| 22:39.31 | sibiria | i mean that's peanuts... |
| 22:40.54 | sibiria | my weak little test platform - a 1 ghz Arm device - can shuffle 150 calls simultaneously without being overburdened |
| 22:41.05 | ilius | I know, right? Yeah, 15 is just what's going on right now, late Friday. I need to handle way more on busy days, possibly >50 calls. |
| 22:42.41 | ilius | Hrm. This is still the samw QEMU KVM platform, same OS. Just new Asterisk, pjsip, and dialplan that talks PJSIP instead of SIP. |
| 22:47.57 | ilius | Is there some way you guys use to find what the bottlneck is? I mean, strace just shows the network traffic going back and forth, perf top shows constant clock queries on the vm host) and nothing specific pegging anything on the guest except for mutex locks and hundreds of things inside libgcc_s.so.1. :) |
| 22:50.34 | *** join/#asterisk retentiveboy (~retentive@c-73-43-121-243.hsd1.ga.comcast.net) |
| 22:51.36 | ilius | Multi-core seems to exacerbate load though. It seems to be doing better with a single core. |
| 22:51.56 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 22:52.48 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 22:53.58 | ilius | I guess I might have to resort to recompiling asterisk with debug flags and running a profiler. |
| 23:00.43 | ilius | gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p 6069 | grep " poll () " | wc -l |
| 23:00.44 | ilius | 16 |
| 23:00.54 | ilius | lots of polling. :) |
| 23:05.23 | Samot | Why are you using asterisk for this? |
| 23:08.02 | sibiria | before tracing to see where it's spending time i'd first throw some basic exclusion methods on the problem |
| 23:08.08 | sibiria | e.g. is it ast 16 or is it pjsip |
| 23:08.10 | ilius | For... a border sip/rtp? Because Asterisk is what I know. I guess I could research using OpenSER or whatever, but I've ever been an Asterisk fanatic, I guess. |
| 23:09.13 | Samot | Yes but asterisk instead a switch |
| 23:09.25 | Samot | Isnt* |
| 23:10.14 | Samot | Kamialio/OpenSER wouldn't even notice that traffic |
| 23:10.44 | ilius | I stripped out border asterisks because of other load issues with app_queue. |
| 23:12.37 | Samot | You mean on the "internal" instances |
| 23:12.45 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 23:18.06 | ilius | Yeah, I was trying to reduce audio choppiness by putting RTP and border SIP signalling on a different virtual machine. That worked great, for years. |
| 23:19.49 | ilius | Host cpu is a E3-1270v6 at 3.8GHz. |
| 23:40.32 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
| 23:48.54 | ilius | Samot, are you saying that Asterisk is not the right software for B2BUA? |
| 23:52.33 | *** join/#asterisk thansen (~thansen@192.74.130.86) |