IRC log for #asterisk on 20210512

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.56jbgbased 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.13jbger, sorry, channel.ODBC_GET_CONFERENCE_NAME("foo")
09:19.48jbgI have a `[CONFERENCE_NAME]` block in func_odbc.conf with `prefix = GET`
09:20.13jbgis that mailing list post correct about the syntax for using ODBC functions from Lua dialplans? I can't find any relevant documentation
09:20.46fileprefix 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.09jbgah, cool, let me try that
09:22.45filehttps://github.com/asterisk/asterisk/blob/18/configs/samples/func_odbc.conf.sample#L55
09:23.27jbgthanks, I missed that! I'll instead leave prefix out and keep them prefixed with ODBC
09:23.47jbgcan 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.22pahi, 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.31pa<PROTECTED>
11:26.42pa<PROTECTED>
11:26.53pawhy would asterisk try to resolve "cheapnet-out"?
11:28.37pai also get Peer 'cheapnet-out' is now Reachable
11:28.49*** join/#asterisk rpifan (~rpifan@p200300d2670b9500d958a5ea8831585f.dip0.t-ipconnect.de)
12:24.41jbgany 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.45igcewielingWhoo!  Whoo!  We have a customer who has started caring about security!!!!!!!!!
14:55.33fileinconceivable
14:58.23ornigcewieling: without him making thousands of calls that he didn't make first?
15:02.42igcewielingorn: Yup!
15:03.17igcewielingApparently their Cyber-insurance company ran a scan on their IPs and sent them a report.
15:04.53fileah one of those
15:05.26igcewielingI'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.18ornigcewieling: good to hear -- makes a lot of sense for them. relatively cheap for the insurance companies compared to a fraud payout
15:11.50igcewielingyup.
15:14.21igcewielingIt also gives them another reason to avoid a payout if the customer doesn't take their advice.
15:15.21igcewielingEven 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.43igcewieling<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.06ornlol
15:41.19*** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au)
15:46.10SamotWhy would you have your firewall opened for Russia?
15:46.40SamotAnd 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.39igcewielingwhy would you think russians would hack from russian Ip addresses?
16:14.32igcewielingSamot: I managed to convince management to get some Mikrotik HEX boxes to use as simple managed switches
16:14.48igcewielinginstead of Linksys 5-port switches
16:15.19Samotwell they'll need to be configured as such, you know.
16:15.23SamotOtherwise they are routers.
16:15.50SamotWith a firewall, DHCP server, DHCP client and NAT.
16:15.56igcewieling*nod*  I built a list of commands to send to the box via usb serial to move it into switch mode.
16:16.29igcewielingWith 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.29SamotWhich includes rebuilding the bridge?
16:17.28igcewielinghttps://paste.nyigc.net/view/dea74d48
16:18.29*** join/#asterisk guerby (~guerby@april/board/guerby)
16:19.04SamotSo then not a switch.
16:20.58igcewielingresulting config: https://paste.nyigc.net/view/ddf2ebff
16:21.12igcewielinghow is it not a switch?
16:22.01SamotWell, you have a firewall running which will mean connection tracking
16:22.59igcewielingHow would you configure it as a switch which can be ssh'd into?
16:24.11SamotWell it would be a switch, on the network, behind a firewall already.
16:24.26igcewielingah.
16:24.37igcewielingthis switch will be outside the firewall
16:24.47SamotI just use the ACLs.
16:25.10SamotBecause in cases where I've had to do this, no firewall can be in place because other vendors are using it.
16:25.14igcewielingto 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.20SamotAnd it has a public subnet being passed over it
16:26.04SamotIP -> Services
16:26.15SamotThat's where you control all the ports the router uses for access.
16:26.22Samot80, 443, 8291, etc.
16:26.40SamotAlso where you can disable them, edit them and add ACLs for IP/subnets that should have access.
16:27.05igcewielingshould not be tough to replicate the firewall settings as ACLs?
16:27.11*** join/#asterisk hfb (~hfb@193.36.225.39)
16:27.30igcewielingI use the CLI, but that isn't a big deal
16:27.37SamotNo, you go in and say "10.11.100.0/24" has access to SSH
16:28.08Samotip service print
16:29.23igcewielinginstead 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.36SamotHow many services will you need?
16:29.46SamotDo you need FTP? I turn that off.
16:30.03SamotDo you want the GUI accessible?
16:30.09SamotBecause right now, they all are.
16:30.12igcewielingI need SSH.
16:30.45SamotThen 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.13SamotOtherwise right now, 80, 21, 22, 8291 and a few others are wide open.
16:31.23SamotFor direct access to the box.
16:31.52igcewielingonly from the IPs in my current firewall rules, right?
16:32.09SamotSure.
16:32.21SamotIf you're going to run a firewall on a switch before the firewall.
16:42.30igcewielingI'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.57igcewielingnevermind, I found it.
16:44.33jbgSamot: what if someone in Russia wants to call...
16:44.39igcewielingit only lets me set one address=
16:45.02Samotjbg: Unless you are actually peering with that person, the call would traverse the PSTN.
16:45.22SamotSo therefore, the person calling from Russia would be calling you like anyone else.
16:45.29jbgyou'll pry my ENUM from my cold dead hands :p
16:45.37SamotOh dear god.
16:46.32jbgbut yeah sure. if you peer with well-known IPs why let any other IPs communicate with you
16:47.03SamotOddly enough, me blocking all non ARIN space hasn't stopped people in the UK from calling me.
16:47.07SamotStrange that.
16:49.20jbgwell obviously, unless you peer with a UK provider for your calls from the UK
16:49.53jbgbut of course there's no reason ARIN space couldn't be announced by a provider in the UK
16:49.57jbgand it seems like a weird way to do it
16:50.18jbgyou 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.30SamotIt's simple, I run services in the US.
16:51.49SamotBy default if it's not an ARIN space I have no need for it touching my network. So blocked.
16:52.01jbgok, 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.21SamotOK so my peers are whitelisted.
16:52.25jbgoh, I see
16:52.32jbgso what's the point in the ARIN whitelist then?
16:52.46SamotBecause I have customers all over the country.
16:52.54jbg... which are whitelisted?
16:52.59SamotTherefore they come from different IPs from different US providers.
16:53.14SamotSo I allow ARIN space in over SIP
16:53.16jbgunless one of those providers is multinational and decides to use some space they obtained from another registry
16:53.20jbg(which is completely normal)
16:53.37SamotAre you from the US?
16:53.42jbgmaybe not many US providers are multinational?
16:53.49SamotThey can be.
16:53.58SamotBut their US entity is their US entity.
16:54.00jbghas this policy really never caused you a problem?
16:54.10SamotT-Mobile deals with things different in the US than in Germany.
16:54.14SamotNo.
16:54.42jbgin 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.00jbgand it's been getting worse with ipv4 exhaustion
16:55.07Samothaha
16:55.09SamotI know.
16:55.23SamotThe exhaustion that has been happening since the late 90's.
16:55.32SamotAnd is on track to keep happening for another 20 some years
16:55.46jbg...
16:55.49SamotBecause full, global IPv6 right now is estimated at about 2045 or so.
16:56.03jbgthe changes in how ipv4 is allocated are easy to observe...
16:56.12igcewielingI allow media, but block everything else from APNIC, AFRINIC, and RIPE.   I seriously doubt it matters in the least.
16:56.12SamotI'm well aware.
16:56.32SamotHowever, there is IPv4 space still in reverse for certain industries.
16:56.35SamotSuch as ISPs.
16:56.42jbgI 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.52SamotAnd others have released IPv4 space back.
16:56.55jbgbut the reality is that many networks are using v4 space in ways different from how they used to
16:57.10SamotSuch as?
16:57.26jbgthe 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.34jbgit may be different with a US-centric worldview, I'm not sure
16:57.45jbgI 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.03SamotRight. So this is why to you my policy seems odd.
16:58.10SamotBut to those in the US, makes sense.
16:58.14tecfallWe 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.21tecfallAnyone else deal with this?
16:58.23jbgseeing RIPE space announced in Asia or APNIC space announced in Europe is not unusual at all
16:58.27SamotBecause major US providers get their space from ARIN.
16:58.32igcewielingtecfall: yes, all the time.
16:59.00tecfallicewieling: any way to remedy this?
16:59.28Samottecfall: Fix your network.
16:59.37Samottecfall: This is most likely a networking issue.
17:00.04tecfallSamot: How would this be a networking issue?
17:00.15SamotWell packets not making it where they should.
17:00.20tecfallI get that the internet can drop, I can't control that.
17:00.34igcewielingtecfall: 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.37tecfallBut I would expect the phones to re-register without having to reboot them.
17:00.46SamotWhen a phone registers it gives the PBX it's IP and port along with an expire time.
17:00.52seanbrightare the phones actually unregistering? like they are sending a REGISTER with an expires of 0?
17:00.59Samot^^^
17:01.04seanbrightor they are just not renewing their registration?
17:01.13SamotThat generally is a device setting, as well.
17:01.23SamotTo unregister on restart/reboot.
17:01.28igcewielingSwitching 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.52SamotWait, seanbright had good questions that should be answered.
17:02.51igcewielingI use TCP, set my qualify frequency to 20 seconds and use a 600 second UDP timeout on my firewall.
17:03.05igcewieling..er...600 second tcp timeout
17:05.05tecfalligcewieling: where do I change the phone to use TCP?
17:05.22SamotYou just can't only change the phone.
17:05.31SamotYou need to change things on the Asterisk side too.
17:05.53igcewielingtecfall: depends on the phone,
17:07.18tecfalligcewieling: Okay. And is there a setting on the sip peer as well in sip.conf that you have to change?
17:07.49igcewielingtecfall: needs to be set on both Asterisk and the phone.
17:08.06tecfalligcewieling: and i can do it per phone, correct?
17:08.11tecfallon the asterisk side..
17:08.41tecfalltransport=tcp?
17:10.28*** join/#asterisk hfb (~hfb@193.36.225.39)
17:11.49SamotPerhaps not use chan_sip
17:12.05tecfallSamot: perhaps one day
17:12.19SamotNot only is it dead. Chan_PJSIP has better NAT handling.
17:12.32Samot3 years
17:12.45SamotThat is basically what you have.
17:12.58tecfallSamot: we are in the works now.
17:14.02*** join/#asterisk andrewyager (~andrewyag@8-104-141-114.static-dsl.realworld.net.au)
17:22.24tecfallI 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.08seanbrighttecfall: 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.56tecfallI 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.57seanbrightand do you have a pcap of the REGISTER requests/responses?
17:59.15seanbrightso you've switched to TCP at this point?
17:59.26tecfallNo, I have not.
17:59.48seanbrightok, well having some packet captures to look at would help
17:59.59seanbrightreally just REGISTER requests and asterisk's responses
18:00.08tecfallseanbright: I have a pcap ready to run as soon as they are unreachable again.
18:00.19seanbrightgotcha
18:00.27tecfallThis doesn't happen often.
18:01.00tecfallIn 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.48igcewielingIt 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.33igcewielingAny 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.04igcewielingThe cause was a corrupted database table.
21:41.22Samotastrundir in '/etc/asterisk' is set to  but the directory
21:41.32SamotThat could do it too
21:45.01*** join/#asterisk votality (~votality@193-116-102-189.tpgi.com.au)
21:46.05igcewielingit isn't, I checked.   I assume the script failed to get somethig out of the database and got confused.
21:46.56igcewielingif 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.50Samotv15 lets you restore from v11
21:54.46igcewielingSo  "not directly, but thee is a way"?
21:54.58igcewielings/thee/there/
22:16.25*** join/#asterisk andrewya_ (~andrewyag@8-104-141-114.static-dsl.realworld.net.au)
22:55.35SamotYes.
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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.