| 01:26.55 | Kobaz | zerocool: also pay attention to context-switches/second |
| 01:27.40 | Kobaz | high cpu isn't necessary the end-all. You could even have low cpu usage, but seriously high context switches, and be bogged down |
| 01:29.03 | Kobaz | I had a server shit the bed pretty hard with 8 cores and 25% cpu per core across the board when context switches spiked from 50k a second to 600k/sec |
| 01:35.40 | Samot | He failed to mention it was FreePBX |
| 01:36.03 | Kobaz | ah, well, who knows what it's doing with those 50 channels then |
| 01:36.07 | *** join/#asterisk cation21- (cation21@gateway/vpn/protonvpn/cation21) |
| 01:36.23 | Samot | Well there is also other things running |
| 01:36.37 | Kobaz | yup |
| 01:36.46 | Samot | So there is more eating at the cpu |
| 02:17.00 | Kobaz | oh, speaking of asterisk |
| 02:17.25 | Kobaz | so, i'm having an issue with pjsip where i get expiration of the AOR just prior to a re-register |
| 02:18.29 | Kobaz | or, is that just the logging playing tricks on me |
| 02:18.41 | Kobaz | https://dpaste.com/6FQ3AES3G |
| 02:18.52 | Kobaz | unreachable/reachable |
| 02:21.17 | Kobaz | i wonder if there could be a race condition where if it's in the fraction of a second in between unreach/reach, you'll get a fail |
| 02:22.07 | igcewieling | Kobaz: looks to me like there is both TLS and UDP registrations? |
| 02:22.20 | Kobaz | oh |
| 02:22.24 | Kobaz | right |
| 02:22.27 | Kobaz | they are fighting |
| 02:22.31 | Kobaz | good point |
| 02:34.11 | *** join/#asterisk tsal (~tsal@i59F5F64C.versanet.de) |
| 02:47.42 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 02:52.14 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 03:02.28 | Kobaz | uhh |
| 03:02.36 | Kobaz | pjsip show contacts -- Objects found: 33 |
| 03:02.51 | Kobaz | AMI: PJSIPShowContacts -- ListItems: 5 |
| 03:08.03 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 03:12.04 | *** join/#asterisk Pectic1 (~pectic@bzq-109-66-195-86.red.bezeqint.net) |
| 03:21.26 | Kobaz | oh i think PJSIPShowContacts is only dynamic contacts |
| 03:22.08 | Kobaz | which disagrees with the docs/help (PPJSIPShowContacts Provides a listing of all Contacts) |
| 03:32.46 | *** join/#asterisk eXistenZ (~pectic@bzq-79-180-209-254.red.bezeqint.net) |
| 03:42.47 | *** join/#asterisk electronic_eel (~quassel@213.240.182.147) |
| 03:56.32 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 04:42.29 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 05:18.24 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 06:07.12 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 06:28.11 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 06:39.10 | *** join/#asterisk anthm (~anthm@freeswitch/developer/anthm) |
| 07:21.41 | *** join/#asterisk BakaKuna (~Thunderbi@2a02-a446-ae46-1-5be8-4ea1-6955-7714.fixed6.kpn.net) |
| 08:02.49 | *** join/#asterisk BakaKuna1 (~Thunderbi@2a02-a446-ae46-1-dbd2-74df-af65-82e1.fixed6.kpn.net) |
| 08:09.36 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
| 08:47.37 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 10:06.44 | *** join/#asterisk sekil (~sekil@79-101-146-239.dynamic.isp.telekom.rs) |
| 10:32.35 | *** join/#asterisk drathir87 (~drathir@gateway/tor-sasl/drathir) |
| 11:01.13 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 11:04.37 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 11:08.00 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 11:37.44 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:42.42 | *** join/#asterisk Ravenheart (~Ravenhear@95-43-74-160.ip.btc-net.bg) |
| 11:53.42 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00770fe15cf8995f9e.dip0.t-ipconnect.de) |
| 12:21.15 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:adca:7f56:33c:667e) |
| 12:52.48 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 13:01.47 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 13:51.05 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 14:06.14 | *** join/#asterisk ganjajim (~anon@bras-base-mtrlpq2848w-grc-40-70-55-209-2.dsl.bell.ca) |
| 14:08.06 | *** join/#asterisk broccolistem (~anon@bras-base-mtrlpq2848w-grc-40-70-55-209-2.dsl.bell.ca) |
| 14:09.43 | broccolistem | Hi, does anyone here have experience setting custom channel variables in a LUA dialplan? |
| 14:12.45 | broccolistem | For instance, in my default context I set a channel variable like this: |
| 14:12.49 | broccolistem | channel["newVar"] = "value" |
| 14:13.03 | broccolistem | and in my hangup function, I try to call back that variable: |
| 14:13.47 | broccolistem | app.verbose("CHANNEL VARIABLE TEST: "..channel.newVar:get()) |
| 14:13.54 | broccolistem | which results in: |
| 14:14.16 | broccolistem | [2021-02-23 09:11:26] ERROR[26777][C-00000002]: pbx_lua.c:1456 exec: Error executing lua extension: |
| 14:14.16 | broccolistem | [string "extensions.lua"]:254: attempt to concatenate a nil value |
| 14:14.34 | broccolistem | notably : if I set the variable in the same way inside of the hangup context, it prints the variable correctly. |
| 14:14.35 | sibiria | so take a look at what's going on at line 254 |
| 14:15.00 | broccolistem | yes indeed! line 254 is where I call back newVar using channel.newVar:get() |
| 14:16.03 | sibiria | have you tried the alternate versions? |
| 14:16.18 | sibiria | channel.newVar = 'blah' |
| 14:16.52 | broccolistem | yes I have tried a couple different ways of setting the variable, with the same result. but let me just try that one more time, 1 sec. |
| 14:17.04 | sibiria | there's a third way i can't recall right now |
| 14:17.25 | sibiria | var = channel.newVar; var:set( 'blah' ) or so |
| 14:20.30 | broccolistem | The same problem exists when I set newVar as you suggested: |
| 14:20.34 | broccolistem | channel.newVar = "value" |
| 14:20.46 | broccolistem | however, when placed inside the hangup function, it reads the variable fine |
| 14:20.51 | broccolistem | let me double check method 3 |
| 14:26.11 | broccolistem | same problem, in setting the variable inside default context like this: |
| 14:26.17 | broccolistem | testVar = channel.newVar; |
| 14:26.17 | broccolistem | testVar:set("value") |
| 14:26.23 | broccolistem | and calling it from within hangup function like this: |
| 14:26.43 | broccolistem | app.verbose("CHANNEL VARIABLE TEST: "..channel.newVar:get()) |
| 14:26.56 | broccolistem | however: when I set the variable in the same fashion inside of hangup context, it works :S |
| 14:27.07 | broccolistem | *hangup function |
| 14:34.15 | broccolistem | Incase anyone has a moment to peak at my dialplan on this strange lua channel variable setup issue, I have uploaded my current dialplan: http://petervanhaaften.net/files/extensions_current_feb23_1.lua |
| 14:35.33 | broccolistem | I set the channel variable on line 184, 192, 200, 208, and 216 (one of these 5 extensions is automatically chosen when the user calls in). |
| 14:36.14 | broccolistem | Then on line 227, I try to call back the variable, and receive an error like this (except not on line 254, it is line 227 now): |
| 14:36.31 | broccolistem | [2021-02-23 09:11:26] ERROR[26777][C-00000002]: pbx_lua.c:1456 exec: Error executing lua extension: |
| 14:36.40 | broccolistem | [string "extensions.lua"]:254: attempt to concatenate a nil value |
| 14:41.45 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:43.35 | EmleyMoor | Is it possible to JabberSend to two identities in one shot, or is it simple to build something that will do it? |
| 14:46.16 | Samot | You'd have to write a while loop to send to each |
| 14:46.30 | Samot | But you can only send to one account with the command |
| 15:00.34 | broccolistem | I've posted my query on the Asterisk forum. Hopefully someone else has had this problem before:) |
| 15:00.36 | broccolistem | https://community.asterisk.org/t/setting-custom-channel-variable-in-lua-dialplan/87672 |
| 15:00.43 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-pfwzipfugolkhbte) |
| 15:00.43 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:00.59 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 15:10.07 | EmleyMoor | Hmmm... I'll have to work out how to implement a while loop to do it |
| 15:11.11 | *** join/#asterisk Pectic (~pectic@bzq-79-176-204-189.red.bezeqint.net) |
| 15:23.26 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:29.44 | *** join/#asterisk derPlexus (~plexus@ip-178-203-128-187.hsi10.unitymediagroup.de) |
| 15:32.23 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 15:36.20 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-declshwaxjayscem) |
| 15:36.21 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:38.25 | igcewieling | Any anyone thing of ANY reason a PCAP received from a carrier would show some SIP packets being sent from 192.168.20.x to our Asterisk box? |
| 15:39.06 | nbjoerg | igcewieling: in the IP header or as part of the SIP payload? |
| 15:39.26 | igcewieling | nbjoerg: wiershark shows it as part of the IP header. |
| 15:39.39 | nbjoerg | that shouldn't happen |
| 15:39.55 | nbjoerg | any self respecting router shold be dropping them |
| 15:39.56 | igcewieling | If it was part of the payload, I'd still be a bit confused, but at least I might see a reason for it. |
| 15:40.19 | nbjoerg | as part of the payload juts means someone is not using a sip proxy |
| 15:40.41 | igcewieling | nbjoerg: That is what I thought. I can post the PCAP somewhere if anyone wants to look. |
| 15:40.59 | nbjoerg | sure |
| 15:41.08 | igcewieling | give me a few mins |
| 15:42.48 | igcewieling | http://help.nyigc.net/tmp/6467258861.pcap |
| 15:43.05 | igcewieling | I'm really terrible with SIP, so am not confident in my own findings. |
| 15:44.55 | nbjoerg | hm. |
| 15:45.06 | nbjoerg | where did you capture this, on the router or on the endpoint? |
| 15:45.39 | igcewieling | nbjoerg: the original "problem" was we were not getting back a final OK when sending BYE to the carrier. |
| 15:45.48 | igcewieling | nbjoerg: the CARRIER captured it on their network. |
| 15:46.15 | nbjoerg | because it looks like you are dealing with multiple copies of the same packet in different firewall/nat stages? |
| 15:46.17 | igcewieling | Apparently Verizon SIP captures every call. |
| 15:46.42 | igcewieling | nbjoerg: *nod*, but at least on my side, there is no NAT involved. |
| 15:46.56 | nbjoerg | you sure you are not a victom of cgnat? |
| 15:47.05 | igcewieling | I sent a reply to the carrier asking about the 192.168 addresses. |
| 15:48.18 | igcewieling | nbjoerg: I'm reasonably sure nat is no involved, but I honestly don't know about the carrier side. We certainly pay enough for our 1G fiber to VZ business. |
| 15:49.06 | igcewieling | Verizon SIP requires an IPSEC tunnel for signalling, which makes every thing more complex. |
| 15:49.55 | nbjoerg | you had my condolences at verizon :) |
| 15:51.30 | igcewieling | Verizon bought MCI's SIP service about a decade or two ago. It isn't really part of Verizon Cell Phone, Verizon Internet, or Verizon POTS |
| 15:51.40 | igcewieling | But they still suck. |
| 16:04.16 | Samot | Did you look at the flow sequence? |
| 16:05.47 | igcewieling | Hmm? |
| 16:06.23 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 16:06.26 | Samot | Telephony -> VoIP Calls |
| 16:06.33 | Samot | In wireshark. |
| 16:06.55 | Samot | It will filter out anything not a voip call, show you a list of those and you can then look at each of them. |
| 16:07.03 | Samot | Including the Flow Sequence. |
| 16:07.17 | Samot | Verizon is doing a Public/Private deal. |
| 16:07.22 | Samot | Not NAT. |
| 16:07.56 | Samot | They have a public IP you send requests to, they receive it over the public IP and then they relay the request over an internal socket. |
| 16:08.11 | Samot | The 182.168.x.x address is their private LAN socket iP. |
| 16:08.16 | Samot | 192.168.x.x |
| 16:08.33 | igcewieling | Right. so why is it sending packets direct to me? |
| 16:09.09 | igcewieling | the flow sequence also shows 192.168.x.x sending direct to 209.220.119.17 |
| 16:09.27 | Samot | No it doesn't. |
| 16:09.32 | Samot | Look at the headers |
| 16:09.42 | Samot | Your IP -> Public IP -> Private IP |
| 16:09.47 | Samot | It's flowing through their proxy |
| 16:10.06 | Samot | The SIP ladder is building a view so you can see the full route. |
| 16:10.38 | igcewieling | Ah, so if it flows through a proxy, S |
| 16:10.57 | igcewieling | Ah, so if it flows through a proxy, Wireshark wont show the packet terminating at the proxy? |
| 16:11.59 | igcewieling | I figured the actual UDP headers would show the actual IP. |
| 16:13.51 | Samot | Well I think it's your PRACKing. |
| 16:15.24 | igcewieling | I figured this was pretty unambigious: 11:27:53.624393 IP 192.168.20.16.5119 > 209.220.119.17.sip: SIP: SIP/2.0 100 Trying |
| 16:16.24 | igcewieling | Are you saying that does not indicate 192.168.20.16 sent a packet to 209.220.119.17 |
| 16:16.31 | Samot | Yes, well now this is the opposite of the other day |
| 16:16.42 | Samot | They are sending you the BYE and you're not responding. |
| 16:16.54 | Samot | The other day you were sending the BYE and they weren't responding. |
| 16:16.57 | Samot | When did all this start? |
| 16:17.12 | igcewieling | Samot: this is the carrier PCAP side of same call. |
| 16:17.29 | Samot | Well their PCAP shows them sending the BYE |
| 16:17.30 | igcewieling | Samot: no idea. only happens on some calls, not many calls as far as I can tell. |
| 16:39.41 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:b867:8b6:dd7e:73a7) |
| 17:13.12 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 17:30.47 | *** join/#asterisk electronic_eel (~quassel@213.240.182.228) |
| 17:38.46 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00274619cef5b0f8da.dip0.t-ipconnect.de) |
| 18:35.28 | *** join/#asterisk jayjo (~jayjo@unaffiliated/jayjo) |
| 19:00.53 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 19:10.40 | igcewieling | If anyone using Twillio for SIP Trunking (and is paying attention), what do you think of them? |
| 19:10.52 | Samot | They're fine. |
| 19:11.09 | Samot | I use them as a backup backup backup |
| 19:11.23 | igcewieling | Samot: how about their portals, like for porting in, etc. |
| 19:11.24 | Samot | Just keep in mind about what Twilio really is. |
| 19:11.34 | Samot | Oh I don't use them for inbound. |
| 19:11.45 | Samot | I haven't ported numbers to them. |
| 19:12.25 | Samot | Twilio is nice but at the end of the day they are an applications platform not a carrier. |
| 19:13.30 | file | there was a period of time were they were being clever with their elastic stuff and it resulted in a lot of posts in places saying stuff didn't work |
| 19:13.33 | file | I haven't seen any in recent times |
| 19:14.05 | Samot | Right because their main target is application developers |
| 19:14.16 | Samot | Large scale app deployment. |
| 19:14.24 | igcewieling | They have access to their API docs without needing to be a customer. That at least got my attention. Intellequent makes you talk to a <gaging noises> sales person to learn anything. |
| 19:14.37 | Samot | Because they want developers |
| 19:14.42 | igcewieling | Samot: who do you use for trunking? |
| 19:14.49 | Samot | Primary? Bandwidth |
| 19:15.36 | igcewieling | The thing I like about Level 3 and Verizon Business is that they don't compete with us. |
| 19:15.57 | Samot | In what way? |
| 19:16.41 | igcewieling | Twillio and Bandwidth.com both provide service to small businesses as well as having a hosted service |
| 19:18.05 | Samot | Yes, Bandwidth had a retail section. |
| 19:18.16 | Samot | ARe you saying that Verizon doesn't do business in your market area? |
| 19:18.31 | Samot | Aren't they who you get your circuits from? |
| 19:19.18 | Samot | And Level 3 doesn't do anything in your market? |
| 19:19.21 | igcewieling | Samot: Verizon SIP is not the same as Verizon circuits. |
| 19:19.35 | Samot | So Verizon SIP doesn't exist in your market? |
| 19:19.55 | Samot | Verizon does not sell SIP to anyone in your market but you? |
| 19:19.56 | igcewieling | Samot: sure it does. Requires commitments no small business would commit to. |
| 19:20.07 | Samot | Sigh |
| 19:20.11 | Samot | Let me try this again |
| 19:20.27 | Samot | Verzion, in any shape or form, doesn't market to consumers or businesses in your market area? |
| 19:20.56 | Samot | No business in your market area can go to Verizon and get service? |
| 19:21.15 | igcewieling | Verizon markets to consumers or businesses in your market area. |
| 19:21.17 | igcewieling | next! |
| 19:21.24 | igcewieling | well, my area |
| 19:21.28 | Samot | So they compete with you. |
| 19:21.49 | igcewieling | Not in very many areas. |
| 19:22.08 | igcewieling | "areas" == services not markets |
| 19:24.03 | igcewieling | It is also misleading to think of Verizon as a single company. |
| 19:24.31 | Samot | I don't. |
| 19:26.39 | igcewieling | bandwidth.com's website astonishingly informative. |
| 19:27.39 | Samot | I've been using them for almost 15 years or more |
| 19:34.22 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 19:40.46 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 19:51.30 | igcewieling | Do you use their CNAM service? If so, what do you think of it? |
| 20:12.04 | *** join/#asterisk sinaowolabi (~Sina@105.112.69.65) |
| 20:14.55 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda0085037fd6b5ddc17a.dip0.t-ipconnect.de) |
| 20:40.29 | Samot | igcewieling: Yes, I use their CNAM services. It's pretty accurate. |
| 20:40.45 | Samot | I mean considering there isn't a centralized LIDB. |
| 20:42.54 | igcewieling | *nod* I consider CallerID on a Verizon POTS line to be "official enough". We keep one around just for that. |
| 20:54.09 | igcewieling | BulkCNAM (which is what we use) seems to be pretty accurate |
| 21:01.58 | *** join/#asterisk Samot (sid133316@gateway/web/irccloud.com/x-nwybpqrwezbuyfxz) |
| 21:02.48 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 21:04.39 | *** join/#asterisk giesen (~ggiesen@ego.giesen.me) |
| 21:21.10 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 21:44.27 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 21:45.05 | *** join/#asterisk lambda (~xiretza@mail.xiretza.xyz) |
| 22:45.03 | *** join/#asterisk marus (58993cd7@ip-88-153-60-215.hsi04.unitymediagroup.de) |
| 22:50.47 | *** join/#asterisk Champi (Champi@damn.e-leet.be) |
| 22:52.20 | *** join/#asterisk tsal (~tsal@i59F5F64C.versanet.de) |
| 23:01.05 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 23:02.00 | *** join/#asterisk gschanuel (~gschanuel@201.89.125.40) |
| 23:48.30 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |