06:00.12 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
06:00.12 | *** topic/#asterisk is AstriCon 2019 in Atlanta! http://www.astricon.net/ -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.29.2 (2019/11/21) 16.6.2 (2019/11/21) Standard: 17.0.1 (2019/11/21); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
06:38.43 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
07:02.49 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
07:31.50 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:e1ef:bf20:96a4:f046) |
10:01.03 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
10:09.16 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
10:23.14 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-awksajlbaubcvwey) |
12:15.26 | *** join/#asterisk iq (~iq@47.185.92.236) |
12:15.49 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
12:19.21 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:eccc:5e3f:67ef:896) |
12:32.29 | *** join/#asterisk Kioubit (~Kioubit@de2.g-load.eu) |
12:51.23 | Kioubit | Hi, I have been trying for a few hours now to setup TLS1.2 signaling encryption and media encryption but I haven't gotten very far.. Could somebody take a quick look at my config? |
12:51.23 | Kioubit | https://pastebin.com/V6Rprd9R |
13:01.25 | TandyUK | https://wiki.asterisk.org/wiki/display/AST/SIP+TLS+Transport |
13:01.32 | TandyUK | some of your settings dont look valid |
13:03.02 | sibiria | also avoid ssl. it's no longer secure |
13:05.17 | sibiria | or, uh, maybe chan_sip uses the old openssl methodology, in which case "sslv23" should be able to negotiate for tls 1.x |
13:06.20 | sibiria | either way, i don't think there is a "method" option for chan_sip. it's named tlssomething |
13:06.57 | Kioubit | Yeah I would like to have TLS1.3 for both media and signaling if possible |
13:07.14 | Kioubit | So this is only possible with pjsip? |
13:08.13 | sibiria | "sslv23" in old openssl methodology implies TLS, all supported versions |
13:08.23 | sibiria | i just don't know what chan_sip does, exactly |
13:08.37 | *** join/#asterisk gerhard7_ (~gerhard7@31.161.207.61) |
13:08.45 | sibiria | i've only used SIPS/SRTP with pjsip |
13:09.17 | sibiria | but your configuration options are still not correct. "method" is for pjsip, not chan_sip |
13:09.27 | TandyUK | afaik, chan_sip only does up to tls1.2 |
13:11.15 | Kioubit | I mean i can try switching to pjsip then with the conversion script and try to configure encryption there |
13:13.54 | sibiria | pjsip appears a bit daunting at first, but using the wizard to set up endpoints/contacts helps a lot |
13:15.10 | Kioubit | Is there a wizard? |
13:18.12 | sibiria | pjsip_wizard.conf |
13:32.02 | Kioubit | Hmm the conversion script gives me this: https://pastebin.com/mhb5iz82 which doesnt work either |
13:32.09 | Kioubit | I think I'll give pjsip_wizard.conf a try then and see if that helps me understand pjsip better |
13:32.10 | Kioubit | Thanks anyway for the suggestions |
13:37.11 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
13:45.17 | *** join/#asterisk paulgrmn_ (~paulgrmn@mail2.hartmantyner.com) |
13:46.12 | *** join/#asterisk iq (~iq@47.185.92.236) |
13:47.01 | *** join/#asterisk iq (~iq@47.185.92.236) |
13:48.55 | *** join/#asterisk iq (~iq@47.185.92.236) |
13:57.50 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
13:58.03 | *** join/#asterisk ruied (~ruied@81.84.234.209) |
13:59.32 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
13:59.45 | engine20191 | hello with what tool can I test how many simultaneous calls you can have, I'm trying a banana pi m64 = 4 core arm64 bits and 2 GB ram |
14:07.47 | Samot | How many do you need? |
14:09.02 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
14:19.01 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
14:25.05 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
14:27.32 | engine20191 | I'm trying with this sipp tool |
14:27.40 | engine20191 | https://wiki.asterisk.org/wiki/display/AST/Measuring+SIP+Channel+Performance |
14:31.14 | Samot | That still wasn't an answer to my question. |
14:33.49 | sibiria | engine20191: you can have 150 calls ongoing on that computer without any problems |
14:34.07 | sibiria | assuming you are not transcoding between something more costly than slin<->g.711 |
14:34.35 | engine20191 | sibiria: thanks |
14:34.49 | engine20191 | codec ulaw |
14:35.04 | engine20191 | the machine is for small bussiness |
14:35.17 | engine20191 | 20 extension |
14:35.28 | sibiria | yeah that's peanuts. no problem |
14:37.42 | Samot | sibiria: It's a RasPI |
14:37.49 | Samot | So let's not get crazy. |
14:39.42 | engine20191 | I downloaded ubuntu bionic arm64 with kernel sinovo 4.4 in this asterisk was installed from the apt with freepbx so that the client can easily manage it |
14:41.11 | sibiria | Samot: yes but it's capable of it |
14:41.19 | sibiria | my test rig is a pine64 with 1gb of ram |
14:41.24 | sibiria | similar performance Arm CPU |
14:41.42 | Samot | And what is the life span of the card? |
14:41.45 | sibiria | when i run 100 calls on it during tests, it sits at around 30% total CPU usage across all cores |
14:41.54 | sibiria | 150 calls and it goes up to about 50% total CPU |
14:42.11 | Samot | And what is the life span of the card? |
14:42.14 | sibiria | with a mix of no transcoding and transcoding from 8khz wav -> ulaw/alaw |
14:42.52 | sibiria | card? of the small-board computer? |
14:43.19 | Samot | They use SD cards, yes? |
14:43.25 | Samot | For the HDD. |
14:44.00 | sibiria | yes they do. the lifespan of that depends entirely on how much writing you do and obviously the brand and size of SD card you use |
14:44.09 | Samot | Correct. |
14:44.17 | Samot | So at some point 150 calls will be a lot of I/O |
14:44.19 | sibiria | i recommend logging to RAM and regularly flushing, isntead of directly to the storage |
14:44.29 | sibiria | it depends entirely on how oyu set up logging and CDRs |
14:44.36 | Samot | OK. |
14:44.38 | sibiria | i do batched CDRs and so |
14:44.44 | sibiria | it's a requirement, reall |
14:44.47 | Samot | I would never trust a system that had to do a 150 calls to a RasPI |
14:44.55 | Samot | That's just me. |
14:44.57 | sibiria | impossible to do any heavy writing directly to SD. everything comes to a complete crawl |
14:45.06 | sibiria | so that particular setup does need some effort put into it first |
14:45.47 | sibiria | i'm merely underlining that the RPi (and similar) are efficient enough due to how well-written and high-performing Asterisk is |
14:45.59 | sibiria | but, again, the setup needs specific planning for this to work |
14:46.37 | sibiria | an SBC with eMMC or regular SATA is really preferrable |
14:49.47 | Samot | Yes. |
14:50.07 | Samot | Just because something can do something doesn't mean it should be doing it. |
14:51.16 | Samot | Like right now in another room, a guy wants to use his router as a CA and CRL server. |
14:51.38 | Samot | Which, sure it can do that but that's more for internal stuff not being a public facing CA/CRL. |
14:52.29 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
14:54.54 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
14:58.31 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-yjqphgetitnqmkdx) |
14:58.31 | *** mode/#asterisk [+o kharwell] by ChanServ |
15:14.56 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
15:24.21 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
15:26.55 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-wylqiqmgsuezpyyu) |
15:26.55 | *** mode/#asterisk [+o bford] by ChanServ |
15:32.53 | sibiria | i personally think an SBC like an RPi or Pine64 is perfectly fine for a SoHo setup, even with just SD storage. i wouldn't go close to the idea for anything "Big Corporate" |
15:33.31 | Samot | Sure but a SOHO setup isn't a 150/calls. |
15:33.38 | *** join/#asterisk overyander (~overyande@216.163.24.235) |
15:51.18 | electronic_eel | I think the sd storage is a real problem when using the raspi for some infrastructure thing |
15:51.51 | electronic_eel | I use a odroid-xu4 for some years now as monitoring system at home (Icinga 2) |
15:52.55 | electronic_eel | It has a pluggable emmc storage. That works really well, even if monitoring is a write-heavy workload for such a system (about 100 metrics measured every few minutes, graphing and so on) |
15:53.19 | electronic_eel | I would suggest to use something similar for asterisk too |
15:54.50 | sibiria | SD (just like USB flash storage) is a problem for anything doing small frequent writes |
15:55.44 | sibiria | it's just not a suitable medium for that scenario, no matter how fast the storage is for large sequential writes |
15:56.45 | *** join/#asterisk zBeeble (~zBeeble@2001:1928:1::35) |
15:57.38 | zBeeble | why-oh-why can't we control the codec negotiation in the dialplan? _or_ why-oh-why is codec negotiation so dumb? |
15:58.25 | drmessano | Dumb how? |
15:58.27 | zBeeble | I have traffic where some comes in asking for g.729 and some doesn't. I want to offer g.729 to the outbound side IFF it was offered on the in. |
15:58.48 | zBeeble | it would be sufficient to offer the codecs I get on the incoming. |
15:59.48 | Samot | Does the outbound side support it? |
15:59.58 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
16:00.24 | zBeeble | yes. The problem is I _don't_ support g729 ... but I'm happy to take advantage of the passthru. |
16:00.37 | zBeeble | so I want the in and out codecs to match. |
16:00.41 | drmessano | zBeeble: Do you have g729 at the top of the allow list? |
16:00.47 | igcewieling | No, you don't want to use passthru. |
16:00.55 | electronic_eel | yeah, more influence on the codec selection would be really nice. I have some problems with g.711 - calls from mobile phones sometimes claim to support it, but the calls then have a 20% chance of breaking. So I'd like to disable g.711 for calls from mobile phones (detection based on remote phone number) |
16:01.18 | Samot | That's not how codecs work. |
16:01.23 | zBeeble | I use passthru all the time. The goal is to make the incoming unaware of the identity of the terminating leg. |
16:01.26 | Samot | When the INVITE comes in, they offer what they want to use. |
16:01.36 | Samot | So if it's using g711 they are offering g711 |
16:01.56 | Samot | Both sides must offer the codec. |
16:02.03 | electronic_eel | yes, they are offering g711, but I know that they have a shitty implementation of it |
16:02.10 | Samot | It's the standard. |
16:02.15 | Samot | It is literally the PSTN standard. |
16:02.19 | electronic_eel | so I want to disable it for them |
16:02.19 | zBeeble | sure... but the problem is: I offer to the terminating side and if I offer g.729, they'll always take it. |
16:02.30 | electronic_eel | oh, sorry mixed it up, g722 I meant |
16:02.42 | zBeeble | ... whereas if I don't offer g.729, they'll take g.711. so I need to only offer it when it's offered to me. |
16:02.53 | Samot | electronic_eel: So don't offer g722 |
16:02.58 | Samot | Simple. Done. |
16:03.07 | file | PJSIP provides https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Function_PJSIP_MEDIA_OFFER for control, and there is also a PJSIP_SEND_SESSION_REFRESH to renegotiate as well |
16:03.17 | Samot | ^^^ |
16:03.18 | zBeeble | problem is ... some incoming traffic is g.729 only. |
16:03.25 | Samot | That. I was looking for that in the wiki |
16:03.29 | electronic_eel | no, I want to use g722 for all calls to other peers |
16:03.45 | igcewieling | I found all my G729 problems went away when I got a transcoder card. |
16:03.55 | zBeeble | yeah... I've seen that. Last time I tried pjsip, everything went to heck in a handbasket. |
16:03.57 | Samot | Then you're transcoding. |
16:04.10 | zBeeble | ... and I'm not sure I have time to implement that before lossing the traffic. |
16:04.14 | electronic_eel | file: but PJSIP_MEDIA_OFFER seems to be only for Dial, not for incoming calls |
16:04.23 | Samot | Correct. |
16:04.31 | Samot | Because your offer goes back to them in a reply |
16:04.36 | file | it may work on incoming too, I forget how it works |
16:04.36 | Samot | Not a new request |
16:04.59 | zBeeble | does the dialplan have access to the incoming offer in pjsip? |
16:05.04 | Samot | You maybe able offer a re-invite |
16:05.09 | Samot | Maybe. |
16:05.15 | Samot | To change the codec. |
16:05.29 | file | When read, returns the codecs offered based upon the media choice. |
16:06.39 | Samot | Yeah, I think those two are it. |
16:07.15 | Samot | PJSIP_MEDIA_OFFER() and then PJSIP_SEND_SESSION_REFRESH() to issue an UPDATE/re-INVITE with the new codec offer. |
16:07.56 | Samot | electronic_eel: That might be the answer to your mobile g722. |
16:08.01 | file | I vaguely recall chan_sip has some special dialplan variables for stuff |
16:08.46 | Samot | zBeeble: You can just use PJSIP_MEDIA_OFFER() on the incoming channel to see if it's g729 and then use it to set g729 on the ountbound channel. |
16:08.48 | zBeeble | AFAICT, only SIP_CODEC* ... and they don't seem to be populated with anything on the inbound call. |
16:08.55 | Samot | But I'm not sur ehow that would work with passthru |
16:09.10 | electronic_eel | where would I do the PJSIP_SEND_SESSION_REFRESH in the dialplan? right before doing the dial to my local endpoint? or after the connection to the local endpoint is established? |
16:09.17 | zBeeble | passthru kicks in if the codec are equal. |
16:09.21 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Function_PJSIP_SEND_SESSION_REFRESH |
16:09.33 | file | you don't need to call PJSIP_SEND_SESSION_REFRESH unless you want to initiate a re-negotiate after the session is established and answered |
16:09.44 | Samot | That's what he wants to do. |
16:09.49 | file | ah, then yeah |
16:10.03 | Samot | Not use g722 based on the from user |
16:11.21 | Samot | electronic_eel: It's probably going to be the first thing you do on a matching for an incoming call. |
16:11.45 | zBeeble | nothing in the pjsip doc there say that media_offer is populated by the inbound call. |
16:11.50 | Samot | Check the from user to see if its mobile and then do the session refresh to force it to g711 if it's using g722 |
16:13.21 | electronic_eel | so I do the PJSIP_SEND_SESSION_REFRESH before the Dial() to my local endpoint? |
16:13.49 | Samot | OK |
16:13.50 | file | zBeeble: on 16 it would be it looks like |
16:13.56 | electronic_eel | I'm asking because the docs say " on an established media session", which sounds like after the dial |
16:16.39 | sibiria | is the session established before you Answer() the call? the channel isn't, but maybe these two are not equivalents here |
16:16.44 | Samot | electronic_eel: On the incoming channel you can do Set(IN_CODEC=CHANNEL(rtp,media_type)) |
16:16.57 | Samot | If you're using pjsip. |
16:17.07 | Samot | That will get the codec on the incoming channel that is being used. |
16:17.23 | Samot | You can then check the from user/callerid for the source to see if it is mobile. |
16:17.50 | Samot | You then set PJSIP_MEDIA_OFFER() to g711 if it is mobile _and_ using g722 |
16:18.12 | Samot | Then you do PJSIP_SEND_SESSION_REFRESH to do a re-invite on the incoming channel to make it use g711 |
16:18.24 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
16:18.48 | Samot | Then you can use whatever you want with the other endpoint. |
16:19.37 | Samot | But you'll be transcoding if you want g722 on the endpoint. |
16:19.38 | Samot | So if you don't want that before you Dial(), you use PJSIP_MEDIA_OFFER() again to force g711 |
16:19.39 | Samot | So that the call is g711 on both channels. |
16:26.33 | Samot | https://www.irccloud.com/pastebin/iXn14WFJ/ |
16:27.02 | Samot | file or someone might want to confirm but that should be what can cause you're mobile to not use 722. |
16:27.27 | Samot | Sorry, change that GoSubIf to GoToIf |
16:28.07 | Samot | NM, fixed it. |
16:30.41 | file | tbh, it's easiest to just experiment and play with it |
16:32.52 | drmessano | or only offer the codecs you want to support |
16:33.43 | Samot | I see the issue. |
16:33.48 | Samot | He wants to support g722. |
16:34.01 | Samot | The provider doesn't handle mobile calls over g722 very well. |
16:34.10 | Samot | So only on those calls does he not want to use g722. |
16:34.21 | drmessano | shrug |
16:34.30 | drmessano | Switch to OPUS then |
16:34.40 | Samot | The g729 one though... |
16:35.00 | Samot | I agree the the original assessment. Don't use passthrough. |
16:35.04 | drmessano | Seems like codec order would fix that one |
16:35.47 | zBeeble | codec order doesn't fix it. |
16:36.24 | zBeeble | asterisk uses pass-thru all the time. You have natted phones chatting to carriers... even if the codecs are the same, you're using passthru. |
16:36.56 | Samot | Not if you have direct media disabled. |
16:38.52 | file | if circumstances allow then the media stream contents will be passed through the core, thus passthru |
16:38.59 | file | without being touching |
16:39.01 | file | er touched |
16:39.16 | Samot | OK. |
16:39.33 | Samot | So as long and both channels are g729, it's pass thru. |
16:39.44 | Samot | as* |
16:39.55 | file | and you aren't doing recording, or spying, or other things |
16:40.09 | Samot | Right, DTMF, etc. |
16:40.57 | zBeeble | dtmf is ok as long as it's RFC. |
16:41.03 | Samot | OK. |
16:42.45 | Samot | zBeeble: Why doesn't codec order fix things? |
16:43.08 | Samot | zBeeble: Because direct media/pass thru would state it would. |
16:44.06 | Samot | If phone A only does g729 and only offers g729 then if phone B offers g711 and g729, they are going to use g729. |
16:44.16 | drmessano | ^^^ |
16:44.31 | Samot | If phone B only offers g711 then nothing will happen. |
16:44.36 | Samot | Asterisk will get involved. |
16:44.54 | drmessano | That was my thought from the original description |
16:46.45 | Samot | If 1 phone of 20 only does g729 and you want pass thru, all 20 phones must support and offer g729 |
16:50.28 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
16:53.06 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
17:04.14 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
17:05.13 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
17:27.29 | electronic_eel | Samot: thanks for the snippet, will give it a try |
17:32.35 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
17:39.21 | *** join/#asterisk jkroon (~jkroon@41.114.125.190) |
17:41.41 | *** join/#asterisk hfb (~hfb@47.139.17.106) |
18:00.43 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@41.248.127.25) |
18:04.52 | *** join/#asterisk deavmi (~quassel@165.0.49.28) |
18:47.32 | *** join/#asterisk irrgit (~ch33se@parajsa.chat) |
18:48.07 | irrgit | Hello, is it possible with asterisk, we use digium as our provider, to use multiple long distance providers? |
18:48.35 | [TK]D-Fender | Asterisk can use whatever service you tell it to |
18:48.47 | [TK]D-Fender | It's your dialplan... do whatever you want |
18:49.15 | irrgit | Example: Say we have ATT and Spectrum, we want to use ATT for the first 10,000/inbound minutes since we have a deal with them, but after that the rate goes to $0.03/m , whereas with Spectrum we have a base rate of $0.02 |
18:49.45 | irrgit | Can we configure it so after the 10,000 minutes we use spectrum for the remainder of the month? |
18:50.21 | sibiria | there's no specific configuration for that exact scenario, so you will have to accomplish it yourself manually or programmatically |
18:50.35 | [TK]D-Fender | Again, it's YOUR dialplan |
18:50.47 | [TK]D-Fender | You are in charge of making it do what you want |
18:57.05 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
18:58.10 | *** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk) |
18:59.52 | irrgit | [TK]D-Fender, as long as you are saying that its possible, then thats all I care about. |
19:10.45 | *** join/#asterisk deavmi (~quassel@165.0.49.28) |
19:11.46 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-msecadsrfzbbjkux) |
19:44.17 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
20:14.38 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
20:30.32 | MICROburst | I grabbed the config for WebRTC from https://wiki.asterisk.org/wiki/display/AST/Configuring+Asterisk+for+WebRTC+Clients -- but for some reason only 8088 is shown when doing 'http show status' - how do I get more information? |
20:38.26 | MICROburst | When I connect to port 8088 via browser, I get a Message 'Upgrade'. |
20:42.19 | seanbright | webrtc in asterisk uses sip over websocket |
20:42.38 | seanbright | Upgrade means you need to connect with a websocket client, not just typing it in the browser |
20:45.00 | MICROburst | seanbright: Shouldn't firefox support webrtc? Why does the server not start on 8089? |
20:45.24 | seanbright | firefox does support it, but you can't just go to a URL in the browser and expect something to happen |
20:45.36 | seanbright | you need to have an application that speaks SIP over WebSockets like jssip or sip.js |
20:46.11 | seanbright | the 8089 thing is something to do with your configuration. you should check your asterisk logs for error messages related to HTTP/HTTPS |
20:52.41 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
20:53.15 | MICROburst | Indeed: it complains about problems when loading the private key file. However the file exists and the permissions are 640 owner:group asterisk:asterisk |
21:02.51 | seanbright | i believe in you, i know you can figure it out |
21:03.55 | seanbright | MICROburst: what is the exact error message you are seeing? |
21:04.32 | *** join/#asterisk Kioubit (~Kioubit@de2.g-load.eu) |
21:15.37 | *** join/#asterisk classsic (ba897291@186.137.114.145) |
21:16.26 | classsic | Hi, somebody can recommend any freepbx service? |
21:17.38 | file | you probably want #freepbx and you'd need to define what that means |
21:18.30 | *** join/#asterisk waldo323 (~waldo323@75-151-31-89-Michigan.hfc.comcastbusiness.net) |
21:18.48 | classsic | any SaaS service provider for management my sip phones |
21:21.53 | Samot | You need to be a little more detailed. |
21:24.18 | classsic | I want to login, add,remove and manage my sip phones, I don´t want deplay my own server |
21:24.25 | classsic | *deploy |
21:24.57 | Samot | Managing SIP phones does not mean having a PBX |
21:25.10 | Samot | So you want something more like RingCentral. |
21:31.22 | *** join/#asterisk jeffspeff (~overyande@72-47-93-62.jsbrcmtk02.com.dyn.suddenlink.net) |
21:38.18 | igcewieling | classsic: the term you are looking for is "hosted pbx", or "hosted voip". If you want to find providers where the marketing department runs things, replace "hosted" with "cloud" |
21:40.01 | classsic | ok, I´m very new, I have some doorbells with sip support |
21:40.56 | classsic | and want to get a service for connect them |
21:43.26 | MICROburst | seanbright: ERROR[3172] tcptls.c: TLS/SSL error loading private key file. </etc/asterisk/keys/asterisk.key> |
21:56.49 | MICROburst | seanbright: any idea? |
22:01.01 | seanbright | must not be a valid PEM |
22:01.13 | seanbright | or it doesn't exist or is not readable by asterisk |
22:01.16 | seanbright | those are the only options |
22:10.04 | MICROburst | for the last test I used the ast_tls_cert script. No matter whether .pem or .crt ist doesn't work |
22:13.12 | *** join/#asterisk rShadowhand (~Shadowhan@secretalgorithm.com) |
22:14.49 | seanbright | ok |
22:14.53 | seanbright | it's not asterisk, it's you |
22:15.15 | seanbright | without access to your machine, i would just be guessing |
22:19.02 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
22:22.29 | seanbright | BUT, i would bet $1000 it was: |
22:22.35 | seanbright | 1) invalid PEM |
22:22.38 | seanbright | 2) file does not exist |
22:22.43 | seanbright | 3) file is not readable by asterisk |
22:23.11 | seanbright | once you check all 3 of those things, and you are running on a supported asterisk version, you can open an issue at https://issues.asterisk.org |
22:23.31 | seanbright | but there are plenty of people (myself included) that load the private key just fine |
22:29.56 | MICROburst | seanbright: false. It is asterisk: the docs and the implementation. this posting here was helpful https://community.asterisk.org/t/websocket-tls-certificate-gives-error/81015/6 - but it seems you can't start the http server as tls only - very ugly! |
22:38.26 | MICROburst | so you just lost $1000 :) |
22:48.31 | *** topic/#asterisk by kharwell -> AstriCon 2019 in Atlanta! http://www.astricon.net/ -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.30.0 (2019/12/23) 16.7.0 (2019/12/23) Standard: 17.1.0 (2019/12/23); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
23:14.48 | seanbright | shucks |
23:15.03 | seanbright | i knew you could do it on your own |
23:15.30 | *** join/#asterisk jeffspeff (~overyande@216.163.24.235) |
23:37.23 | *** join/#asterisk AsteriskRoss_ (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |