00:10.13 | *** join/#asterisk Katty (uid62315@gateway/web/irccloud.com/x-grcincllksvtndwc) |
00:52.25 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
01:56.34 | *** join/#asterisk tsal (~tsal@i59F5F46A.versanet.de) |
01:58.37 | *** join/#asterisk mr44er1 (~mr44er@dynamic-046-114-007-093.46.114.pool.telefonica.de) |
02:23.54 | *** join/#asterisk infernix (~nix@unaffiliated/infernix) |
02:38.52 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-irloqlbgcylpdmsj) |
02:39.45 | *** join/#asterisk sinaowolabi (~Sina@105.112.186.79) |
04:19.06 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
04:21.47 | *** join/#asterisk sysgrammer (~sysgramme@d205-234-59-20.yt.northwestel.net) |
04:26.26 | *** join/#asterisk andrewyager (~andrewyag@114.141.97.1) |
04:40.22 | *** join/#asterisk ganbold (~ganbold@202.21.108.17) |
05:33.38 | *** join/#asterisk andrewya_ (~andrewyag@114.141.97.1) |
05:55.00 | *** join/#asterisk JAunis (~jean@lputeaux-658-1-51-39.w92-154.abo.wanadoo.fr) |
06:14.21 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
06:34.34 | *** join/#asterisk Milos_ (~Milos@pdpc/supporter/student/milos) |
07:13.58 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:2948:682:c4f7:a040) |
07:30.12 | *** join/#asterisk gschanuel4 (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:42.50 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:45.59 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:46.08 | *** join/#asterisk andrewyager (~andrewyag@114.141.97.1) |
07:49.04 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:51.36 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:54.12 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:56.44 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
07:59.23 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:01.14 | *** join/#asterisk daemonwrangler (~daemonwra@li1301-160.members.linode.com) |
08:02.04 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:04.39 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:07.14 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:09.55 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:12.32 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:13.31 | *** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-jiwyfcjhfqecmrfh) |
08:14.30 | *** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
08:15.11 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:17.43 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:20.26 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:23.02 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:25.42 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:28.16 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:30.57 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:33.33 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:36.10 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:38.43 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:41.19 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:43.56 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:46.36 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:49.10 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:51.47 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:54.24 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:56.59 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
08:59.36 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:02.14 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:04.22 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:06.31 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:09.12 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:11.47 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:12.08 | *** join/#asterisk evil_gordita (robert@ip24-254-23-39.rn.hr.cox.net) |
09:12.40 | *** join/#asterisk rpifan (~rpifan@p200300d2670b9500594b46597e7b4272.dip0.t-ipconnect.de) |
09:14.15 | *** join/#asterisk rpifan (~rpifan@p200300d2670b9500d958a5ea8831585f.dip0.t-ipconnect.de) |
09:14.21 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:16.33 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:18.43 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:18.56 | jbg | based on https://markmail.org/message/unhc4rgudla64zvu I'm trying to use `foo = channel.ODBC_GET_FOO("fooname"):get()` in my Lua dialplan, but it complains that `Function ODBC_GET_CONFERENCE_NAME not registered` |
09:19.13 | jbg | er, sorry, channel.ODBC_GET_CONFERENCE_NAME("foo") |
09:19.48 | jbg | I have a `[CONFERENCE_NAME]` block in func_odbc.conf with `prefix = GET` |
09:20.13 | jbg | is that mailing list post correct about the syntax for using ODBC functions from Lua dialplans? I can't find any relevant documentation |
09:20.46 | file | prefix would make it GET_CONFERENCE_NAME, not ODBC_GET_CONFERENCE_NAME |
09:21.22 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:22.09 | jbg | ah, cool, let me try that |
09:22.45 | file | https://github.com/asterisk/asterisk/blob/18/configs/samples/func_odbc.conf.sample#L55 |
09:23.27 | jbg | thanks, I missed that! I'll instead leave prefix out and keep them prefixed with ODBC |
09:23.47 | jbg | can just name the function GET_* |
09:23.55 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:26.38 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:29.16 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:30.27 | *** part/#asterisk JAunis (~jean@lputeaux-658-1-51-39.w92-154.abo.wanadoo.fr) |
09:31.50 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:34.25 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:37.04 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:39.44 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:42.24 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:44.30 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:47.12 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:50.51 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:52.57 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:55.09 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:57.19 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
09:59.28 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
10:18.08 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
10:29.07 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
10:57.37 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
11:09.27 | *** join/#asterisk andrewyager (~andrewyag@114.141.97.1) |
11:24.58 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
11:26.22 | pa | hi, i have a noob question: i had a working dialplan with a working outbound extension. I now cloned it for a new provider, and i get this odd error: |
11:26.31 | pa | <PROTECTED> |
11:26.42 | pa | <PROTECTED> |
11:26.53 | pa | why would asterisk try to resolve "cheapnet-out"? |
11:28.37 | pa | i also get Peer 'cheapnet-out' is now Reachable |
11:28.49 | *** join/#asterisk rpifan (~rpifan@p200300d2670b9500d958a5ea8831585f.dip0.t-ipconnect.de) |
12:24.41 | jbg | any hints as to why after `conference_name = channel.ODBC_GET_CONFERENCE_NAME(pin):get()` in my Lua dialplan, I would find that `conference_name` is truncated to 15 characters compared to what is in the DB? |
12:36.55 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-102-131-177.ks.ok.cox.net) |
12:37.32 | *** join/#asterisk andrewya_ (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
12:50.22 | *** join/#asterisk andrewyager (~andrewyag@114.141.97.1) |
13:38.48 | *** join/#asterisk andrewya_ (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
13:47.15 | *** join/#asterisk sekil (~sekil@178-222-13-110.dynamic.isp.telekom.rs) |
13:53.22 | *** part/#asterisk sekil (~sekil@178-222-13-110.dynamic.isp.telekom.rs) |
14:16.01 | *** join/#asterisk mahlon (~mahlon@martini.nu) |
14:20.59 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-mqviiatwcssfiafe) |
14:20.59 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:38.54 | *** join/#asterisk andrewyager (~andrewyag@114.141.97.1) |
14:49.05 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-scgzthzftuogzfih) |
14:49.05 | *** mode/#asterisk [+o bford] by ChanServ |
14:53.45 | igcewieling | Whoo! Whoo! We have a customer who has started caring about security!!!!!!!!! |
14:55.33 | file | inconceivable |
14:58.23 | orn | igcewieling: without him making thousands of calls that he didn't make first? |
15:02.42 | igcewieling | orn: Yup! |
15:03.17 | igcewieling | Apparently their Cyber-insurance company ran a scan on their IPs and sent them a report. |
15:04.53 | file | ah one of those |
15:05.26 | igcewieling | I've suspected for a long time that insurance companies are going to secure the internet if for no reason other than to pay out less. |
15:10.18 | orn | igcewieling: good to hear -- makes a lot of sense for them. relatively cheap for the insurance companies compared to a fraud payout |
15:11.50 | igcewieling | yup. |
15:14.21 | igcewieling | It also gives them another reason to avoid a payout if the customer doesn't take their advice. |
15:15.21 | igcewieling | Even if the customer does everything right, they still not pay "Zurich American Insurance Company refused to pay out a $100 million claim from Mondelez, saying that since the U.S. and other governments labeled the NotPetya attack as an action by the Russian military their claim was excluded under the âhostile or warlike action in time of peace or warâ exemption" |
15:15.43 | igcewieling | <PROTECTED> |
15:29.01 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
15:32.01 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
15:36.06 | orn | lol |
15:41.19 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
15:46.10 | Samot | Why would you have your firewall opened for Russia? |
15:46.40 | Samot | And even if there was a need, it would be IP based to let it in. |
16:03.19 | *** join/#asterisk rpifan (~rpifan@p200300d2670b95008699823952630035.dip0.t-ipconnect.de) |
16:05.37 | *** join/#asterisk john2gb0 (~john2gb@94-225-47-8.access.telenet.be) |
16:13.39 | igcewieling | why would you think russians would hack from russian Ip addresses? |
16:14.32 | igcewieling | Samot: I managed to convince management to get some Mikrotik HEX boxes to use as simple managed switches |
16:14.48 | igcewieling | instead of Linksys 5-port switches |
16:15.19 | Samot | well they'll need to be configured as such, you know. |
16:15.23 | Samot | Otherwise they are routers. |
16:15.50 | Samot | With a firewall, DHCP server, DHCP client and NAT. |
16:15.56 | igcewieling | *nod* I built a list of commands to send to the box via usb serial to move it into switch mode. |
16:16.29 | igcewieling | With the boxes in hand, I expect we'll use them for more then simple switches eventually. Management is pretty set on only Adtran. |
16:16.29 | Samot | Which includes rebuilding the bridge? |
16:17.28 | igcewieling | https://paste.nyigc.net/view/dea74d48 |
16:18.29 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
16:19.04 | Samot | So then not a switch. |
16:20.58 | igcewieling | resulting config: https://paste.nyigc.net/view/ddf2ebff |
16:21.12 | igcewieling | how is it not a switch? |
16:22.01 | Samot | Well, you have a firewall running which will mean connection tracking |
16:22.59 | igcewieling | How would you configure it as a switch which can be ssh'd into? |
16:24.11 | Samot | Well it would be a switch, on the network, behind a firewall already. |
16:24.26 | igcewieling | ah. |
16:24.37 | igcewieling | this switch will be outside the firewall |
16:24.47 | Samot | I just use the ACLs. |
16:25.10 | Samot | Because in cases where I've had to do this, no firewall can be in place because other vendors are using it. |
16:25.14 | igcewieling | to be fair, without a default gateway or routable address, I could remove it. ACLs are not part of the firewall? I'll go research it. |
16:25.20 | Samot | And it has a public subnet being passed over it |
16:26.04 | Samot | IP -> Services |
16:26.15 | Samot | That's where you control all the ports the router uses for access. |
16:26.22 | Samot | 80, 443, 8291, etc. |
16:26.40 | Samot | Also where you can disable them, edit them and add ACLs for IP/subnets that should have access. |
16:27.05 | igcewieling | should not be tough to replicate the firewall settings as ACLs? |
16:27.11 | *** join/#asterisk hfb (~hfb@193.36.225.39) |
16:27.30 | igcewieling | I use the CLI, but that isn't a big deal |
16:27.37 | Samot | No, you go in and say "10.11.100.0/24" has access to SSH |
16:28.08 | Samot | ip service print |
16:29.23 | igcewieling | instead of rules which cover everything, have individual rules for every service on the box. annoying, but if that is the way it has to be |
16:29.36 | Samot | How many services will you need? |
16:29.46 | Samot | Do you need FTP? I turn that off. |
16:30.03 | Samot | Do you want the GUI accessible? |
16:30.09 | Samot | Because right now, they all are. |
16:30.12 | igcewieling | I need SSH. |
16:30.45 | Samot | Then if you only need SSH you need to disable (since you can't remove) the services you don't need |
16:31.01 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
16:31.13 | Samot | Otherwise right now, 80, 21, 22, 8291 and a few others are wide open. |
16:31.23 | Samot | For direct access to the box. |
16:31.52 | igcewieling | only from the IPs in my current firewall rules, right? |
16:32.09 | Samot | Sure. |
16:32.21 | Samot | If you're going to run a firewall on a switch before the firewall. |
16:42.30 | igcewieling | I'm having trouble setting the address= on ssh. The command doesn't generate an error, but it also does not show in export. |
16:42.57 | igcewieling | nevermind, I found it. |
16:44.33 | jbg | Samot: what if someone in Russia wants to call... |
16:44.39 | igcewieling | it only lets me set one address= |
16:45.02 | Samot | jbg: Unless you are actually peering with that person, the call would traverse the PSTN. |
16:45.22 | Samot | So therefore, the person calling from Russia would be calling you like anyone else. |
16:45.29 | jbg | you'll pry my ENUM from my cold dead hands :p |
16:45.37 | Samot | Oh dear god. |
16:46.32 | jbg | but yeah sure. if you peer with well-known IPs why let any other IPs communicate with you |
16:47.03 | Samot | Oddly enough, me blocking all non ARIN space hasn't stopped people in the UK from calling me. |
16:47.07 | Samot | Strange that. |
16:49.20 | jbg | well obviously, unless you peer with a UK provider for your calls from the UK |
16:49.53 | jbg | but of course there's no reason ARIN space couldn't be announced by a provider in the UK |
16:49.57 | jbg | and it seems like a weird way to do it |
16:50.18 | jbg | you presumably know who you peer with, so why not just selectively allow those IPs instead of basing it on the registry where the IP space was obtained from? |
16:50.39 | *** join/#asterisk hfb (~hfb@193.36.225.39) |
16:51.30 | Samot | It's simple, I run services in the US. |
16:51.49 | Samot | By default if it's not an ARIN space I have no need for it touching my network. So blocked. |
16:52.01 | jbg | ok, but for example I work for a company with PoPs in the US from which we advertise space we obtained from APNIC (because our HQ is in Asia) |
16:52.21 | Samot | OK so my peers are whitelisted. |
16:52.25 | jbg | oh, I see |
16:52.32 | jbg | so what's the point in the ARIN whitelist then? |
16:52.46 | Samot | Because I have customers all over the country. |
16:52.54 | jbg | ... which are whitelisted? |
16:52.59 | Samot | Therefore they come from different IPs from different US providers. |
16:53.14 | Samot | So I allow ARIN space in over SIP |
16:53.16 | jbg | unless one of those providers is multinational and decides to use some space they obtained from another registry |
16:53.20 | jbg | (which is completely normal) |
16:53.37 | Samot | Are you from the US? |
16:53.42 | jbg | maybe not many US providers are multinational? |
16:53.49 | Samot | They can be. |
16:53.58 | Samot | But their US entity is their US entity. |
16:54.00 | jbg | has this policy really never caused you a problem? |
16:54.10 | Samot | T-Mobile deals with things different in the US than in Germany. |
16:54.14 | Samot | No. |
16:54.42 | jbg | in most of the world, the registry that IP space was obtained from is correlated to the location of the endpoint associated with that IP, but it's really not reliable enough to filter based upon |
16:55.00 | jbg | and it's been getting worse with ipv4 exhaustion |
16:55.07 | Samot | haha |
16:55.09 | Samot | I know. |
16:55.23 | Samot | The exhaustion that has been happening since the late 90's. |
16:55.32 | Samot | And is on track to keep happening for another 20 some years |
16:55.46 | jbg | ... |
16:55.49 | Samot | Because full, global IPv6 right now is estimated at about 2045 or so. |
16:56.03 | jbg | the changes in how ipv4 is allocated are easy to observe... |
16:56.12 | igcewieling | I allow media, but block everything else from APNIC, AFRINIC, and RIPE. I seriously doubt it matters in the least. |
16:56.12 | Samot | I'm well aware. |
16:56.32 | Samot | However, there is IPv4 space still in reverse for certain industries. |
16:56.35 | Samot | Such as ISPs. |
16:56.42 | jbg | I didn't say anything about ipv6. ipv4 exhaustion could lead to many different outcomes, and we still get v4 allocated when we need it |
16:56.46 | *** join/#asterisk tecfall (~tecfall@ip68-226-58-248.om.om.cox.net) |
16:56.52 | Samot | And others have released IPv4 space back. |
16:56.55 | jbg | but the reality is that many networks are using v4 space in ways different from how they used to |
16:57.10 | Samot | Such as? |
16:57.26 | jbg | the fact that correlation between "registry the space was obtained from" and "geo that the space is used in" is no longer as reliable as it used to be |
16:57.34 | jbg | it may be different with a US-centric worldview, I'm not sure |
16:57.45 | jbg | I don't work with the US much so I'm not sure |
16:57.56 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
16:58.03 | Samot | Right. So this is why to you my policy seems odd. |
16:58.10 | Samot | But to those in the US, makes sense. |
16:58.14 | tecfall | We have a few small locations that don't have a local PBX box. Instead we register the phones over the internet. We have found that the phones will randomly unregister. Not sure if it due to an internet blip, or whatever. But the only way to get them to reregister is to reboot the phone. |
16:58.21 | tecfall | Anyone else deal with this? |
16:58.23 | jbg | seeing RIPE space announced in Asia or APNIC space announced in Europe is not unusual at all |
16:58.27 | Samot | Because major US providers get their space from ARIN. |
16:58.32 | igcewieling | tecfall: yes, all the time. |
16:59.00 | tecfall | icewieling: any way to remedy this? |
16:59.28 | Samot | tecfall: Fix your network. |
16:59.37 | Samot | tecfall: This is most likely a networking issue. |
17:00.04 | tecfall | Samot: How would this be a networking issue? |
17:00.15 | Samot | Well packets not making it where they should. |
17:00.20 | tecfall | I get that the internet can drop, I can't control that. |
17:00.34 | igcewieling | tecfall: The issue isn't cause by a single problem, so there is no single solution. The most common problem is that firewalls, by default often close UDP connections after 30 seconds of inactivity. SIP usually uses UDP and doesn't always have traffic every 30 seconds or les. If you are a network person, you can see the problems and solutions now. |
17:00.37 | tecfall | But I would expect the phones to re-register without having to reboot them. |
17:00.46 | Samot | When a phone registers it gives the PBX it's IP and port along with an expire time. |
17:00.52 | seanbright | are the phones actually unregistering? like they are sending a REGISTER with an expires of 0? |
17:00.59 | Samot | ^^^ |
17:01.04 | seanbright | or they are just not renewing their registration? |
17:01.13 | Samot | That generally is a device setting, as well. |
17:01.23 | Samot | To unregister on restart/reboot. |
17:01.28 | igcewieling | Switching to TCP can fix that issue. So can setting your firewall to keep "inactive" connections open for 10 mins of inactifity. You could also change your qualify frequency to be less then your firewall UDP timeout. |
17:01.52 | Samot | Wait, seanbright had good questions that should be answered. |
17:02.51 | igcewieling | I use TCP, set my qualify frequency to 20 seconds and use a 600 second UDP timeout on my firewall. |
17:03.05 | igcewieling | ..er...600 second tcp timeout |
17:05.05 | tecfall | igcewieling: where do I change the phone to use TCP? |
17:05.22 | Samot | You just can't only change the phone. |
17:05.31 | Samot | You need to change things on the Asterisk side too. |
17:05.53 | igcewieling | tecfall: depends on the phone, |
17:07.18 | tecfall | igcewieling: Okay. And is there a setting on the sip peer as well in sip.conf that you have to change? |
17:07.49 | igcewieling | tecfall: needs to be set on both Asterisk and the phone. |
17:08.06 | tecfall | igcewieling: and i can do it per phone, correct? |
17:08.11 | tecfall | on the asterisk side.. |
17:08.41 | tecfall | transport=tcp? |
17:10.28 | *** join/#asterisk hfb (~hfb@193.36.225.39) |
17:11.49 | Samot | Perhaps not use chan_sip |
17:12.05 | tecfall | Samot: perhaps one day |
17:12.19 | Samot | Not only is it dead. Chan_PJSIP has better NAT handling. |
17:12.32 | Samot | 3 years |
17:12.45 | Samot | That is basically what you have. |
17:12.58 | tecfall | Samot: we are in the works now. |
17:14.02 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
17:22.24 | tecfall | I just realized I probably left out a pretty big piece of info. When I say over the internet, it is through a vpn tunnel. So I am able to use the internal IP of my PBX for registration. Not NAT. |
17:29.44 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
17:34.12 | *** join/#asterisk Janos (~textual@201.204.94.76) |
17:42.33 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
17:46.04 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
17:58.08 | seanbright | tecfall: are the phones actually unregistering? like they are sending a REGISTER with an expires of 0? or they are just not renewing their registration? |
17:58.56 | tecfall | I wasn't able to dig that deep before having to just reboot them. It is a sales location, so having the phones be down for any amount of time is bad. |
17:58.57 | seanbright | and do you have a pcap of the REGISTER requests/responses? |
17:59.15 | seanbright | so you've switched to TCP at this point? |
17:59.26 | tecfall | No, I have not. |
17:59.48 | seanbright | ok, well having some packet captures to look at would help |
17:59.59 | seanbright | really just REGISTER requests and asterisk's responses |
18:00.08 | tecfall | seanbright: I have a pcap ready to run as soon as they are unreachable again. |
18:00.19 | seanbright | gotcha |
18:00.27 | tecfall | This doesn't happen often. |
18:01.00 | tecfall | In fact, we have multiple locations that connect back to the PBX this way, and a couple locations started doing this as of late. |
18:01.43 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
18:17.22 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
18:22.21 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
18:22.48 | igcewieling | It is almost always safe to blame the firewall. lol. |
18:33.27 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
18:54.41 | *** join/#asterisk hfb (~hfb@193.36.225.18) |
19:10.08 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-102-131-177.ks.ok.cox.net) |
19:14.57 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
19:15.12 | *** part/#asterisk Janos (~Janos@201.204.94.76) |
19:27.09 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
19:38.38 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
19:59.28 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
20:04.05 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
20:17.23 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
20:30.49 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
21:00.04 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
21:02.48 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
21:26.33 | igcewieling | Any idea what might cause this? https://paste.nyigc.net/view/3f231310 It is an older FreePBx. |
21:37.03 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
21:41.04 | igcewieling | The cause was a corrupted database table. |
21:41.22 | Samot | astrundir in '/etc/asterisk' is set to but the directory |
21:41.32 | Samot | That could do it too |
21:45.01 | *** join/#asterisk votality (~votality@193-116-102-189.tpgi.com.au) |
21:46.05 | igcewieling | it isn't, I checked. I assume the script failed to get somethig out of the database and got confused. |
21:46.56 | igcewieling | if I upgrade from 2.11 to 12 using the upgrade tool, should I then be able to upgrade from 12 to 15? IIRC you said something about not being able to upgrade v12 to later versions? |
21:49.50 | Samot | v15 lets you restore from v11 |
21:54.46 | igcewieling | So "not directly, but thee is a way"? |
21:54.58 | igcewieling | s/thee/there/ |
22:16.25 | *** join/#asterisk andrewya_ (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
22:55.35 | Samot | Yes. |
23:02.07 | *** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |
23:16.51 | *** join/#asterisk andrewya_ (~andrewyag@8-104-141-114.static-dsl.realworld.net.au) |