| 00:00.57 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 00:02.01 | *** join/#asterisk zopsi (zopsi@2600:3c00::f03c:91ff:fe14:551f) |
| 00:10.53 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 00:11.42 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 00:48.22 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 01:07.20 | *** join/#asterisk paulgrmn__ (~paulgrmn@mail.hartmantyner.com) |
| 01:09.48 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 01:18.33 | *** join/#asterisk paulgrmn_ (~paulgrmn@mail.hartmantyner.com) |
| 01:20.27 | *** join/#asterisk pearce15 (uid332392@gateway/web/irccloud.com/x-bjwfqdlelscwbghu) |
| 01:21.07 | pearce15 | https://www.irccloud.com/pastebin/xQsEt8vO/ |
| 01:21.34 | pearce15 | Been getting this message from a client trying to register with TLS, not sure where to begin. |
| 01:21.34 | pearce15 | <PROTECTED> |
| 01:21.35 | pearce15 | pjproject: <?>: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151576> <SSL routines-ssl3_read_bytes-tlsv1 alert unknown ca> len: 0 peer: 10.0.0.51:5061 |
| 01:28.14 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:29.24 | drmessano | Are you using self-signed certs? |
| 01:45.25 | pearce15 | @drmessano Yes. |
| 01:46.05 | drmessano | read the message |
| 01:46.09 | drmessano | "unknown ca" |
| 01:46.24 | drmessano | So the client is trying to validate the cert |
| 01:50.14 | pearce15 | Thanks, so I generated the client cert/keys and generated a PEM file with the CA cert to the phone. That should work right? Not sure what else I am missing here. |
| 01:52.54 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:53.17 | drmessano | If the phone has the whole chain, sure |
| 01:53.18 | drmessano | But |
| 01:53.30 | drmessano | Most client have an option to ignore the cert validity |
| 01:53.40 | drmessano | If you're using a self-signed, you may as well check it |
| 01:53.52 | drmessano | It's not like it's doing anything more than securing the channel at a basic level |
| 01:53.59 | drmessano | There's really no trust level to assure here |
| 02:26.36 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 02:32.12 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 02:41.35 | *** join/#asterisk electronic_eel (~quassel@213.240.182.67) |
| 02:42.23 | *** join/#asterisk paulgrmn__ (~paulgrmn@mail.hartmantyner.com) |
| 02:44.32 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 03:04.04 | *** join/#asterisk tsal (~tsal@i59F5220C.versanet.de) |
| 03:42.45 | *** join/#asterisk electronic_eel (~quassel@213.240.182.43) |
| 03:55.43 | *** join/#asterisk cation21 (cation21@gateway/vpn/protonvpn/cation21) |
| 04:37.10 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 04:45.05 | avb | file: https://github.com/avbdr/asterisk-res_json |
| 04:47.07 | avb | sorry, it took me a bit to get the final code without cJson library. I think im missing one more code review to fix couple small memleaks and this week ill work out licensing question with an initial module developer |
| 04:49.24 | avb | in what form do you want me to get this permission to upstream the code? |
| 04:49.44 | avb | some kind of an email to the mailing list or? |
| 04:49.52 | avb | thank you |
| 05:33.17 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 06:44.34 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 06:45.32 | *** join/#asterisk erichowey (uid462861@gateway/web/irccloud.com/x-qkrtemaanhhfaizd) |
| 06:47.23 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 07:30.22 | Zombie | Can I ask an insane question? |
| 07:30.54 | Zombie | Would there be a way to interconnect a Skype call with a SIP Conference call? |
| 07:31.06 | Zombie | Or Discord... |
| 07:38.26 | drmessano | You can pay $7 a month or so add SIP to Skype |
| 07:38.29 | drmessano | per channel |
| 07:59.05 | *** join/#asterisk jkroon (~jkroon@165.16.204.102) |
| 08:50.13 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 09:15.36 | *** join/#asterisk PyJ (8ae80312@c102-rj.uibk.ac.at) |
| 09:27.31 | *** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm64777d632380.cpe.net.cable.rogers.com) |
| 09:52.35 | *** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:58.09 | file | avb: license agreements are signed on https://issues.asterisk.org/jira |
| 10:59.02 | *** join/#asterisk rpifan (~rpifan@p200300d2670b1d00531a37959204c721.dip0.t-ipconnect.de) |
| 12:10.32 | *** join/#asterisk cation21 (cation21@gateway/vpn/protonvpn/cation21) |
| 12:16.05 | *** join/#asterisk Ravenheart (~Ravenhear@95-43-74-160.ip.btc-net.bg) |
| 12:39.35 | *** join/#asterisk MarkS- (~mark@unaffiliated/mark21) |
| 12:45.52 | *** part/#asterisk MarkS- (~mark@unaffiliated/mark21) |
| 13:02.02 | *** join/#asterisk MarkS- (~mark@unaffiliated/mark21) |
| 13:02.42 | MarkS- | Hello, short question. Is it possible to completely move extensions.conf to the database? without having to set anything in extensions.conf for every context |
| 13:08.29 | Samot | You would need to look into Real-Time. |
| 13:10.42 | MarkS- | I did and could not find any examples/documentation for this part |
| 13:25.25 | avb | they are all over |
| 13:25.42 | avb | https://www.voip-info.org/asterisk-realtime-extensions/ |
| 13:25.45 | avb | for example here |
| 13:29.51 | file | such an action has consequences, though |
| 13:30.10 | file | you tightly couple your phone system to another process - the database |
| 13:34.55 | nbjoerg | file: sounds like something a phone company would do, just without COBOL |
| 13:35.46 | avb | file: i always do :) |
| 13:36.30 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 13:50.11 | MarkS- | I want to create a web interface for it, so file isn't the thing I'm hoping for and looking for an alternative |
| 13:50.40 | MarkS- | < avb> https://www.voip-info.org/asterisk-realtime-extensions/ << that seems to still require every context to be in the file |
| 14:00.29 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:02.07 | Samot | So why does a GUI need real-time? |
| 14:05.58 | MarkS- | when clients change something they want to get the change at that time |
| 14:06.11 | MarkS- | And the gui will be on a central system |
| 14:06.21 | MarkS- | (not on the asterisk server) |
| 14:06.36 | MarkS- | so a database connection from the gui to the asterisk server is easier than file access |
| 14:09.18 | Samot | You do realize that pretty much all the GUI based PBX systems using Asterisk do not rely on Real-Time? |
| 14:12.28 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 14:14.14 | TandyUK | id suggest totally decoupling your web interface and the config... or have fun when a user does somethign stupid, and kills your pbx |
| 14:15.05 | TandyUK | also needs multiple layers of snaity checking what $user tries to do imho |
| 14:15.12 | TandyUK | sanity* |
| 14:17.47 | MarkS- | Samot: this will be something created in house and yes it will have sanity checking where possible |
| 14:18.35 | Samot | MarkS-: I understand that. I'm just pointing out that major projects don't use Real-Time. |
| 14:24.58 | MarkS- | We at least need something else later this year than what we are doing now (manually changing extensions.conf). We already have all users in the database (and we will not change that). |
| 14:25.00 | *** join/#asterisk retentiveboy (~retentive@c-24-125-16-104.hsd1.ga.comcast.net) |
| 14:26.15 | Samot | No one said a database cant be used to store data |
| 14:27.39 | nbjoerg | well, I'd say one major advantage of using a database is that you don't need to reinvent a parser |
| 14:28.19 | Samot | What parser? |
| 14:28.29 | nbjoerg | for extensions.conf |
| 14:28.43 | nbjoerg | or you depend on noone else touching things which is asking for trouble as well |
| 14:28.56 | Samot | You mean to generate it? |
| 14:29.31 | nbjoerg | Samot: dealing with existing config files falls into one of two categories. understanding them or requiring everyone else to keep their hands off them |
| 14:29.41 | nbjoerg | Samot: both are problematic requirements |
| 14:29.56 | nbjoerg | so manipulating structured data certainly is attractive |
| 14:30.07 | Samot | Sane for the database |
| 14:30.14 | Samot | Same |
| 14:30.37 | Samot | You put something wrong in the DB you are in the same spot |
| 14:30.44 | nbjoerg | you don't parse free text for the database |
| 14:31.00 | Samot | You still need to make DB calls |
| 14:31.09 | Samot | More of them. There is a cost |
| 14:32.38 | nbjoerg | there are tradeoffs, sure. but dealing with a database (and one that enforces at least some basic constraints) makes things a lot less fragile for an UI |
| 14:33.13 | Samot | No one said the GUI required anyone to touch configs |
| 14:36.48 | *** join/#asterisk rpifan (~rpifan@p200300d2670b1d00531a37959204c721.dip0.t-ipconnect.de) |
| 14:43.33 | avb | databases is the best what happened with an IT world :) |
| 14:44.02 | avb | but I do not recommend using dialplans from the database |
| 14:44.06 | avb | in short its a mess |
| 14:44.44 | avb | the best shot to make it is to utilize regular dialplans + func_odbc + curl |
| 14:45.33 | avb | func_odbc is a bit funky with default settings, but its very handy |
| 14:46.11 | avb | I would suggest to read via func_odbc and to write its better to utilize rest api with curl |
| 14:46.30 | *** join/#asterisk rmudgett (~rmudgett@170.249.191.178) |
| 14:46.31 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:46.38 | avb | func_odbc on a high load can lead to the deadlocks on write |
| 14:48.21 | Samot | Well my original intent was just pointing out that a GUI management system does not require the use of Real-Time. |
| 14:48.33 | avb | not at all, correct |
| 14:48.35 | Samot | As just about all major projects don't use it. |
| 14:48.40 | avb | huh |
| 14:48.50 | avb | i think so |
| 14:48.57 | Samot | FreePBX is the biggest. |
| 14:49.01 | Samot | It doesn't use it. |
| 14:49.20 | Samot | There are limitations to Real-Time. |
| 14:49.25 | avb | i wouldnt consider freepbx as an example of the best solution :) |
| 14:49.47 | Samot | So to give everyone a real PBX experience you would either have to not do Real-Time or do pieces outside of Real-Time |
| 14:50.06 | Samot | And what you would consider an example of a best solution? |
| 14:51.06 | avb | if we are talking about boxed solutions, Thirdlane |
| 14:52.28 | avb | they dont use realtime too if you will ask :-D |
| 14:52.44 | *** join/#asterisk zapata_ (~zapata@2a02:1748:fad4:7260:6c18:e1de:523a:8d7a) |
| 14:52.58 | avb | realtime works pretty good for the queues,extensions,vms,etc |
| 14:53.05 | avb | but not for the dialplan |
| 14:53.07 | Samot | Yes, I know Thirdlane doesn't do it. |
| 14:53.16 | Samot | queues have limitations. |
| 14:53.31 | avb | asterisk queues is a mess even without a realtime :-D |
| 14:54.12 | avb | realtime queues work fine, its a queue members which a problem |
| 14:54.57 | avb | if you pull queues lists from the db and then using QueueMember* apps to manage agents, it works pretty good |
| 14:55.07 | Samot | Well that would then be a limitation to using queues. |
| 14:55.17 | avb | the only problem that if you have like 1000 queues -- asterisk would die :( |
| 14:55.21 | avb | yes, indeed |
| 14:55.54 | avb | what i been saying that if you know the bottlenecks, it works pretty good :) |
| 14:55.55 | Samot | So again, an offering like Thirdlane or FreePBX would have to do a bit in Real-Time and the rest static. |
| 14:56.15 | Samot | Instead of trying to support two different methods... |
| 14:56.49 | avb | plus i do not see any pos of managing dialplan out of the dialplan since its just a pure mess |
| 14:57.16 | avb | its waaaay easier to make a static dailplan and use curl/odbc to manage the data |
| 14:57.32 | Samot | And as I said before, there's a cost to that |
| 14:57.42 | Samot | So I guess it all depends on the costs you are willing to pay. |
| 15:00.14 | *** join/#asterisk tmoore (~tmoore@2600:1702:4110:3d10:70e8:ed2d:f280:46a0) |
| 15:01.02 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 15:10.30 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-eheuyipikhhbtwgg) |
| 15:10.30 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:10.33 | *** join/#asterisk rmudgett (~rmudgett@170.249.191.178) |
| 15:10.34 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:14.51 | *** join/#asterisk vasilakisfil (~vasilakis@51.15.225.200) |
| 15:17.56 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-qwrjpkfacgrgqyis) |
| 15:17.56 | *** mode/#asterisk [+o bford] by ChanServ |
| 16:02.41 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
| 16:05.35 | *** join/#asterisk cryptic (~cryptic@142-196-139-017.res.spectrum.com) |
| 16:07.39 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 16:08.51 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 16:14.24 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 17:50.13 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 18:07.21 | *** join/#asterisk detha (~detha@unaffiliated/detha) |
| 18:10.23 | *** join/#asterisk rmudgett (~rmudgett@170.249.191.178) |
| 18:10.23 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 19:08.49 | *** join/#asterisk rpifan (~rpifan@p200300d26713d300eb3d07ac4ec15c00.dip0.t-ipconnect.de) |
| 20:18.40 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:1533:a126:4b22:1ff7) |
| 20:19.51 | *** join/#asterisk koltrast_ (adedee7b@h77-53-57-114.cust.a3fiber.se) |
| 20:20.50 | *** join/#asterisk joako_ (~joako@opensuse/member/joak0) |
| 20:22.02 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 20:23.20 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 20:29.06 | *** join/#asterisk Champi (Champi@damn.e-leet.be) |
| 20:31.23 | *** join/#asterisk tsal (~tsal@i59F5220C.versanet.de) |
| 20:33.44 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:8596:216:3eff:fefe:444f) |
| 20:56.39 | *** join/#asterisk catphish (~charlie@unaffiliated/catphish) |
| 20:58.08 | catphish | i'm having fun trying to make some shoretel sip phones work with asterisk this week, no idea if this is a worthwhile endeavour but it's interesting, it has a proprietary config and claims to be SIP, but it's TLS only, think i'm getting there |
| 21:57.26 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 22:13.31 | catphish | is it possible for TCP-SIP to use the same connection for requests in both directions? it seems like this would be essential for NAT, but i can't work out how to configure it in PJSIP |
| 22:14.16 | catphish | i specifically mean, when a telephone device with no fixed address registers, i'd like the TCP connection it initiates to be used for SIP requests to that device |
| 22:18.29 | Samot | Do you want them to exclusively use TCP? |
| 22:18.57 | Samot | You just need to setup a TCP based transport and statically set that transport in the endpoint. |
| 22:19.43 | catphish | yes, i didn't set the transport in the endpoint, i will try that, thanks |
| 22:20.27 | file | rewrite_contact=yes which cause connection reuse |
| 22:26.05 | catphish | file: that worked, thank you, it also deletes the contact when the connection is terminated which is cool |
| 22:27.09 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 22:36.10 | catphish | looks like what i actually needed was "sip outbound" which isn't supported in asterisk 16, but should be in 18, i'll upgrade |
| 22:38.07 | *** join/#asterisk rpifan (~rpifan@p200300d26713d300eb3d07ac4ec15c00.dip0.t-ipconnect.de) |
| 22:50.52 | catphish | oh, i don't think this is supported for inbound connections :( |
| 22:55.34 | catphish | one more question: is it possible to rewrite the contact and not tell the registering device you've done it? |
| 23:04.59 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 23:27.20 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 23:36.53 | catphish | at this point, i fear this phone's sip implementation is just too bespoke to work with asterisk, it registers with a fake contact (a sips: address that doesn't listen) and expects connection reuse, but will disconnect if the contact header is rewritten, it then sends NOTIFY messages that expect an OK response, but asterisk rejects them because they have no contact header |
| 23:38.24 | Samot | They were designed for a specific platform. |
| 23:38.44 | Samot | So thats a downside |
| 23:39.09 | catphish | indeed, they are sip, but not designed for compatibility |
| 23:39.30 | catphish | i was just hoping i could breathe some new life into them |
| 23:40.01 | catphish | but i think it would involve hacking asterisk and i don't have that much dedication this |
| 23:40.14 | catphish | thanks for the help anyway |
| 23:42.17 | Samot | Yup |