| 00:15.15 | *** join/#asterisk pedro__ (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 00:15.44 | *** join/#asterisk TandyUK2 (~admin@TandyUK/staff/James) |
| 00:18.47 | *** join/#asterisk puzzola_ (~puzzola@unaffiliated/puzzola) |
| 00:19.40 | *** join/#asterisk wyoung_ (~wyoung@wesleyy.com) |
| 00:24.53 | *** join/#asterisk gregs (sid160074@gateway/web/irccloud.com/x-tvxscnahkcubqtaj) |
| 00:25.40 | *** join/#asterisk leftleg_ (sid291906@gateway/web/irccloud.com/x-ohpngjbayrzqsopj) |
| 00:25.48 | *** join/#asterisk _0x5eb_ (~seb@seb-hpws2.w1.tele.crt1.net) |
| 00:26.13 | *** join/#asterisk Samot (sid133316@gateway/web/irccloud.com/x-lbnxfweqocpezoql) |
| 00:26.14 | *** join/#asterisk JohnWigley (uid264251@gateway/web/irccloud.com/x-suffxwfmhoqwkqpp) |
| 00:26.17 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-qosfdyzudndhifri) |
| 00:26.17 | *** mode/#asterisk [+o bford] by ChanServ |
| 00:27.05 | *** join/#asterisk chandoo (~chandoo@pool-108-50-150-199.nwrknj.fios.verizon.net) |
| 00:27.44 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 00:27.53 | *** join/#asterisk dadrc (~quassel@unaffiliated/drc) |
| 00:28.52 | *** join/#asterisk spammy (~pihahirot@2607:5300:201:3100::1d28) |
| 00:29.14 | *** join/#asterisk kamyl (~user@unaffiliated/kamyl) |
| 00:31.34 | *** join/#asterisk skrusty (~skrusty@88.150.145.104) |
| 00:31.34 | *** mode/#asterisk [+o skrusty] by ChanServ |
| 00:33.06 | *** join/#asterisk Typhon (~Typhon@dslb-084-056-168-141.084.056.pools.vodafone-ip.de) |
| 01:00.15 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:00.30 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:12.03 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 02:02.55 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 02:05.12 | *** join/#asterisk MICROburst1 (~Thunderbi@x4d0babb0.dyn.telefonica.de) |
| 03:14.25 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 03:21.31 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 04:16.24 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 04:22.46 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 04:46.23 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 05:09.23 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 05:44.10 | *** join/#asterisk bmg505 (~leon@169-0-148-131.ip.afrihost.co.za) |
| 06:08.20 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:40.37 | *** join/#asterisk ih8wndz (jwpierce3@mail.000.srv.trnkmstr.com) |
| 06:56.55 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |
| 07:09.46 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 07:15.22 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 07:50.04 | *** join/#asterisk gentoora- (~gentoorax@gateway/tor-sasl/gentoorax) |
| 08:15.14 | *** join/#asterisk hehol (~Adium@ip-176-199-151-97.hsi06.unitymediagroup.de) |
| 08:24.53 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:cd94:5ad5:8469:7070) |
| 08:49.25 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 08:49.26 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 10:36.18 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 10:57.19 | *** join/#asterisk Helenah1 (~s98259@unaffiliated/iveeee) |
| 11:21.35 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 11:21.35 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 12:39.46 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 13:23.14 | *** join/#asterisk Helenah1 (~s98259@unaffiliated/iveeee) |
| 14:01.20 | *** join/#asterisk alexandre9099 (~alexandre@unaffiliated/alexandre9099) |
| 14:02.03 | *** join/#asterisk JohnWigley (uid264251@gateway/web/irccloud.com/x-vhiblxvlwiavwecj) |
| 14:03.15 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:03.15 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:10.11 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 14:21.37 | *** join/#asterisk GoldenBear (~gb@104.200.131.8) |
| 14:21.59 | *** join/#asterisk jkroon (~jkroon@41.113.55.160) |
| 14:43.40 | *** join/#asterisk jkroon (~jkroon@41.113.49.172) |
| 15:04.24 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 15:10.23 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
| 15:14.17 | *** join/#asterisk Helenah1 (~s98259@unaffiliated/iveeee) |
| 15:23.13 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-hujtxskkcfvvncfp) |
| 15:23.13 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:25.33 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-jgegdbzavyywfohj) |
| 15:25.33 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:28.47 | *** join/#asterisk MICROburst (~Thunderbi@x4d0babb0.dyn.telefonica.de) |
| 15:40.54 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 15:51.46 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 15:54.48 | *** join/#asterisk JohnWigley (uid264251@gateway/web/irccloud.com/x-aovvckdgnxhcflse) |
| 16:08.36 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 16:13.34 | *** join/#asterisk netman (~netman@185.94.249.222) |
| 16:31.48 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 16:34.09 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-goxzpqsptpcpgblb) |
| 16:50.23 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 16:50.34 | MLC | Is anyone using rtp_timeout in pjsip.conf? I'm trying to get some experience with it in my lab setup. I'm using iptables to block the RTP packets, and I can verify with "rtp set debug" that they aren't getting through, but the channel never drops as it should. |
| 16:52.30 | sibiria | are you enabling the option for the correct endpoint? |
| 16:53.13 | sibiria | (and as an endpoint setting) |
| 16:53.29 | MLC | yes. I put it on both the trunk provider and the phone. rtp_timeout = 120 |
| 16:53.29 | MLC | rtp_timeout_hold = 120 |
| 16:54.01 | MLC | in the type = endpoint section |
| 17:09.01 | Samot | Why are you blocking RTP packets? |
| 17:09.30 | MLC | I'm simulating a problem that we occasionally have in production with voip.ms. |
| 17:09.41 | Samot | Which is? |
| 17:10.14 | MLC | The audio goes silent. When I rtp set debug on, there is no RTP coming from voip.ms. |
| 17:10.42 | Samot | Does voip.ms confirm this? |
| 17:10.48 | Samot | Or do they say they see audio flowing? |
| 17:11.12 | MLC | They haven't ever tried to debug. They did admit that the server we were using "had some problems". |
| 17:11.43 | Samot | So have you done a capture outside of Asterisk? |
| 17:11.58 | *** join/#asterisk jkroon (~jkroon@165.16.203.109) |
| 17:12.13 | Samot | rtp debug is going to show what Asterisk gets. |
| 17:12.30 | MLC | No. That would be a good idea for next time. I can do that at my firewall and make sure it is not blocking for some reason. |
| 17:12.34 | Samot | Have you confirmed at the server level the RTP is coming in, what port, etc? |
| 17:12.50 | Samot | RTP is not new traffic. |
| 17:13.05 | Samot | VoIP.ms only knows your RTP ports when you tell them. |
| 17:13.22 | MLC | Have not at the server level either. Also a good idea for next time. |
| 17:13.41 | Samot | I don't have anything open at my firewalls for RTP. |
| 17:13.56 | MLC | The purpose in using rtp_timeout is to get some logging of the issue when it occurs while I'm not around. |
| 17:14.10 | MLC | firewall = me either |
| 17:14.19 | Samot | Is this box behind NAT? |
| 17:14.21 | MLC | yes |
| 17:14.32 | Samot | OK so you have NAT rules? |
| 17:15.34 | sibiria | are you sure it's not just that they now and then negotiate an RTP peer whose IP address isn't let through your firewall? |
| 17:16.01 | Samot | And you have NAT rules? |
| 17:16.03 | MLC | no nat rules. have never need them. |
| 17:16.09 | sibiria | e.g. did you look in the SDP of calls where you're getting a low (or zero) rxcount? |
| 17:16.10 | Samot | OK firewall != NAT |
| 17:16.28 | Samot | What type of router/firewall is this? |
| 17:16.56 | MLC | negotiate IP not getting through: I woudn't think that is the case because the calls start off OK and then go silent part way through |
| 17:17.07 | Samot | MLC: This is sounding like a NAT issue. |
| 17:17.14 | Samot | A standard NAT issue. |
| 17:17.18 | sibiria | and they're not renegotiating? |
| 17:17.29 | sibiria | are you by any chance using iptables on linux? |
| 17:17.37 | Samot | Or the router isn't handing NAT well. |
| 17:17.50 | sibiria | i ran into this problem before because of iptables' retarded mismanagement of certain RTP traffic |
| 17:17.59 | MLC | Next time it happens I'll defiintely check that the tunnel is still open in the firewall. |
| 17:18.01 | MLC | iptables = no |
| 17:18.04 | sibiria | resulting in RTCP packets disappearing -> sudden silence |
| 17:18.13 | Samot | MLC: What is the firewall/router in front of the PBX? |
| 17:18.18 | MLC | firewall = pfSense |
| 17:18.22 | Samot | Oh dear god. |
| 17:18.30 | Samot | This is a pfsense problem, I'll put money on it. |
| 17:18.39 | Samot | It's a common pfsense problem as well. |
| 17:19.13 | MLC | I also have an ongoing SIP trace, so I can check if the RTP port is being renegotiated |
| 17:19.27 | Samot | Not just the port. |
| 17:19.29 | Samot | The IP |
| 17:19.52 | MLC | ok |
| 17:20.16 | Samot | But this is a common issue I've seen with pfsense boxes. |
| 17:20.53 | Samot | All related to NAT. |
| 17:21.12 | MLC | Now I know more what to look for next time. Of course, hasn't happened in a couple of days since I switched servers at voip.ms |
| 17:21.26 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 17:21.51 | Samot | Well in this case, it could be voip.ms. |
| 17:21.56 | Samot | They are having a few issues. |
| 17:22.23 | Samot | Like a bunch of compromised accounts. |
| 17:22.31 | MLC | could be. I'm pressing them for more info on the problems of that server. |
| 17:22.50 | MLC | Didin't hear about that. Do you have more info on that? a link or ... ? |
| 17:23.12 | MLC | Back to the rtp_timeout question... Should it be dropping the call when I intentionally block the RTP with iptables? |
| 17:23.32 | Samot | https://www.dslreports.com/forum/r32512300-Voip-ms-Hacked-Voip-ms-accounts |
| 17:23.44 | Samot | Started back in Sept. People are just noticing it more now. |
| 17:24.11 | Samot | MLC: it's a phone call. No audio means no call. |
| 17:24.17 | sibiria | MLC: it should, but are you sure you're dropping the traffic? you're working with a state-keeping firewall and you're likely using rtp_symmetric |
| 17:24.36 | MLC | That must be why they added IP restrictions as a security measure |
| 17:24.55 | sibiria | meaning you've "punched a hole"; a state; and traffic is now allowed back in the same way, as a proper state-keeping firewall should allow |
| 17:25.40 | MLC | In my lab environment, I'm blocking RTP from my phone using iptables on the server, so the firewall is not involved. |
| 17:26.03 | sibiria | just tcpdump the receiving interface to be sure |
| 17:26.22 | sibiria | no need to generate a packet capture. you can just monitor it directly in your terminal |
| 17:26.25 | *** join/#asterisk pqatsi (~leonardo@elt/member/pqatsi) |
| 17:27.00 | MLC | in those situations rtp set debug shows no rtp, but I'll do the dump to make sure |
| 17:27.53 | pqatsi | Hello! In musiconhold, a custom application can write to stdout the audio that will be played on call. ulaw (ffmpeg mulaw) are the only format supported by asterisk in this case? |
| 17:30.23 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 17:37.20 | *** join/#asterisk i9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 17:39.16 | MLC | Interesting - asterisk shows no RTP from the phone, but the TCP dump (wireshark) does. Maybe the TCP dump is before iptables drops it? |
| 17:39.32 | Samot | It is. |
| 17:39.51 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 17:44.08 | pqatsi | Well, found in a try-and-error that s16 is supported by musiconhold too. |
| 17:44.33 | sibiria | MLC: it depends on if you're sniffing packets on the way in or out |
| 17:44.59 | sibiria | in this case tcpdump squeezes in before iptables |
| 17:46.21 | igcewieling | you should be blocking them at your firewall and capturing at the PBX |
| 17:47.53 | MLC | Wireshark offers an "any" interface which appears to be after the OUTPUT iptables chain, but before the INPUT chain. Not seeing any way to capture after the INPUT chain. |
| 17:49.42 | MLC | igcewieling: I did it internally because I can force my phone client to specific RTP ports. I wouldn't know the upstream RTP port until the call is established, then there is a tunnel and a new firewall rule wouldn't block it |
| 17:50.10 | MLC | I guess I could block ALL udp from upstream |
| 17:50.28 | MLC | except 5060 |
| 17:50.32 | Samot | Why? |
| 17:50.48 | MLC | Just responding to igcewieling's suggestion to block at the firewall |
| 17:50.53 | Samot | I guess I'm still lost at what you are trying to achieve. |
| 17:51.07 | Samot | Clearly voip.ms had issues and things you are describing are NAT issues. |
| 17:51.32 | MLC | I want to trigger the rtp_timeout so that I know how it operates and what to look for in the logs when it does happen |
| 17:53.10 | Samot | I get that. |
| 17:53.14 | Samot | But why? |
| 17:53.25 | Samot | What is rtp_timeout going to do for you? |
| 17:53.32 | Samot | What is the need for testing this? |
| 17:54.04 | MLC | Because I won't always be around to debug when the problem happens in the live system, so I need some what to document what the problem is in those cases. |
| 17:54.16 | MLC | *some way |
| 17:54.54 | Samot | So you just want to know when a call disconnects due to no RTP? |
| 17:55.05 | MLC | yes |
| 17:56.48 | Samot | Are all the endpoints on the same network? |
| 17:56.51 | Samot | As the PBX? |
| 17:57.15 | MLC | my lab testing has not been that way, but I could easily make it so |
| 17:57.20 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 17:57.37 | Samot | OK |
| 17:57.41 | Samot | The production one? |
| 17:57.49 | Samot | Are the endpoints on the same network as the PBX? |
| 17:58.03 | MLC | All the phones are, but not voip.ms |
| 17:58.28 | Samot | Obliviously the provider isn't. |
| 17:58.56 | Samot | So you only need this to track voip.ms? Or are you going to track all the endpoints? |
| 17:59.23 | MLC | Really just voip.ms, although all endpoints would be nice |
| 18:05.08 | Samot | Well I'm sure it logs just like the RTP timeout for chan_SIP where it tells you there was no RTP activity for X seconds. |
| 18:05.40 | Samot | Which is based on Chan_SIP rtptimeout setting. |
| 18:05.55 | Samot | So as a troubleshooting tool, that's what it's going to tell you. |
| 18:06.12 | Samot | Now this is a SIP trunk for a PBX behind NAT and pfsense specifically. |
| 18:06.24 | Samot | So those would be NAT related issues. |
| 18:07.12 | Samot | Apparently in your lab you only have firewall rules but not NAT rules, so that's a problem. |
| 18:07.28 | Samot | Because firewall just tells it what to let in and from where. NAT tells it where to go. |
| 18:08.46 | Samot | So that RTP packets can come in from VoIP.ms and the firewall can allow it. But the PBX is at X IP so now you need to tell it to route those RTP packets sent to your WAN IP:Port to the proper LAN IP:port for the PBX. |
| 18:12.17 | MLC | Right. When a call is active, pfSense sets up a tunnel for the RTP. I can see it in their "state" table. |
| 18:13.20 | MLC | There is a "kill" button on the page in pfSense. Just for fun I'm going to kill that tunnel and see what happens. |
| 18:13.31 | Samot | Yes and pfsense is horrible for maintain that |
| 18:14.01 | igcewieling | you mean NAT? Tunnels are different. |
| 18:14.46 | MLC | Tunnel may have been the wrong term. |
| 18:15.40 | *** join/#asterisk deavmi (~quassel@165.0.49.28) |
| 18:16.32 | Samot | Here's what I know. For the past 5 years of being on IRC and doing this pfsense is notorious for handling SIP/NAT poorly. |
| 18:16.56 | Samot | Hours spent with people trying to fix things. Generally, they swap out pfsense for something else and boom, issues go away. |
| 18:17.16 | MLC | what kind of firewalls are better? I'm not opposed to changing. |
| 18:17.23 | Samot | I use Mikrotik. |
| 18:17.33 | Samot | They handle SIP the best I've seen. |
| 18:17.57 | Samot | I don't need firewall rules or NAT rules at my end user locations. |
| 18:18.03 | Samot | It just works. |
| 18:18.20 | MLC | https://mikrotik.com/ ? |
| 18:18.25 | Samot | I got hotels with 100+ endpoints connecting to my hosted systems. |
| 18:18.35 | Samot | Not a single issue with NAT or RTP. |
| 18:18.50 | Samot | Yes. |
| 18:19.45 | Samot | You could spend $70 USD and have a SOHO router that handles 1Gbps throughput, IPSec with accel. |
| 18:20.11 | sibiria | it's not a problem making pfsense manage RTP correctly. pf is among the most capable packet filters available. what you're facing is a misconfiguration problem |
| 18:20.13 | Samot | Doesn't even matter, the $25 home router still does VLANs, MLPS, VRRP, etc, etc. |
| 18:20.44 | Samot | https://imgur.com/a/A9vJo |
| 18:22.08 | sibiria | to pf it's just UDP traffic. it doesn't concern itself with what's in the packet, but pfSense may configure pf to do things that get in the way of NAT (stuff like not keeping state etc.) |
| 18:37.46 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 18:54.42 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 19:18.57 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 19:58.23 | *** join/#asterisk irrgit (~ch33se@parajsa.chat) |
| 20:10.03 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 20:15.28 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1004:7678:d9c4:ae52:e2cd:94bf) |
| 20:25.38 | *** join/#asterisk joepublic (~joepublic@fsf/member/joepublic) |
| 20:34.33 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:b019:ad9:d540:d402) |
| 21:09.46 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 21:31.55 | *** join/#asterisk sysgrammer (~sysgramme@d205-234-49-246.yt.northwestel.net) |
| 21:38.06 | *** join/#asterisk zicada (~zicada@shell01.copyleft.no) |
| 21:43.34 | Samot | Any rumblings on where AstriCon will be this year? |
| 21:43.46 | *** join/#asterisk elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 21:55.31 | kharwell | It'll be in Oct. in Orlando FL. |
| 21:57.27 | sibiria | will there be curious hats? |
| 21:58.00 | file | I will have a hat. |
| 21:58.23 | sibiria | :thumbsup: |
| 22:00.12 | giaco | I have very nood noob question |
| 22:00.35 | giaco | please be patient |
| 22:02.24 | giaco | let's say I don't have Internet connection, no mobile data connection, but working GSM+ connection. Can I asterisk on both ends to create encrypted calls over t1 or chan_mobile? |
| 22:02.40 | giaco | *can I use |
| 22:04.12 | sibiria | you'd need to write your own codec module |
| 22:04.15 | giaco | I do know that I could use TLS or SRTP otherwise, but what can I do if I have only data? |
| 22:04.26 | sibiria | only audio, you mean |
| 22:04.34 | giaco | yes, sorry |
| 22:04.42 | sibiria | your own custom codec, is the only way for encryption over audio in a setup like this |
| 22:05.38 | giaco | sibiria: there's no module for this? Nothing at all? |
| 22:06.12 | sibiria | none that i'm familiar with |
| 22:06.24 | sibiria | i'm sure someone's had the idea, but it's nothing i've ever seen around |
| 22:06.48 | *** join/#asterisk jkroon (~jkroon@41.114.52.238) |
| 22:07.15 | sibiria | go for morse and manual transcription, but swap the dits and dahs! |
| 22:07.37 | sibiria | totally super tight audio crypto |
| 22:09.00 | giaco | sibiria: :D |
| 22:13.16 | electronic_eel | giaco: gsm audio means that the audio bandwidth is dynamic and the codec will try to "fill in" lost packets |
| 22:13.35 | electronic_eel | that is grossly incompatible with sending something like modem data over it |
| 22:13.59 | sibiria | there' enough room in it for e.g. data-over-PWM and such |
| 22:14.11 | sibiria | low bitrates and for audio you'd fall well under toll quality |
| 22:14.16 | electronic_eel | so I don't think this whole thing is a viable approach |
| 22:14.19 | sibiria | it would likely only be usable for text messages or so |
| 22:14.32 | sibiria | i think it would be |
| 22:15.32 | sibiria | there are audio codecs that produce decent audio at 16 kbit/s, as an example, and it's not entirely unfeasible that it would be possible to get that much across over PWM through GSM or so |
| 22:15.36 | electronic_eel | the cell providers dropped support for csd (circuit switched data) a few years ago, all data going via mobile internet access now |
| 22:15.58 | electronic_eel | csd would have been what you wanted to support something like this |
| 22:17.32 | giaco | I do know that there are GSM phones that can talk to each other after diff-helman key exchange. All just via GSM |
| 22:17.54 | Samot | file: I just might have to out-hat you. |
| 22:18.00 | giaco | So I was wondering if there's something freely available out there |
| 22:18.00 | Samot | I will have to start looking. |
| 22:19.05 | file | oic |
| 22:19.08 | electronic_eel | giaco: why try to force your way through the wall when you can use the door? |
| 22:19.27 | sibiria | giaco: sure, and generally speaking, if you manage to come up with a digital audio scheme good enough to survive over the GSM codec's quality, you can do a lot |
| 22:19.36 | electronic_eel | giaco: just enable the internet connection on both phones and use sip over that |
| 22:20.02 | sibiria | EDGE offers enough bandwidth to do high quality speex in srtp |
| 22:20.18 | electronic_eel | giaco: in the near future there won't be any gsm audio anymore, everything going VoLTE and Vo5G with SIP |
| 22:21.14 | Samot | Yes. It's on like Donkey Kong. The Great Hat Off of 2020. |
| 22:21.24 | giaco | electronic_eel: I know, but now there is a lot of land where people live with no 3G/4G/5G. Just GSM and wired (crappy) Internet at home |
| 22:21.47 | giaco | not sure how much "near" is near for them |
| 22:22.20 | electronic_eel | giaco: and no GPRS or EDGE or similar internet access over the GSM network? |
| 22:23.03 | giaco | electronic_eel: yes, but I'm not expert enough to draw a line where Voip is still possible or not |
| 22:23.27 | giaco | what is the bare minimum requirement for voip? |
| 22:23.52 | sibiria | 16 kbit/s gets you good quality with speex and opus |
| 22:23.56 | *** join/#asterisk GoldenBear (~gb@104.200.131.8) |
| 22:24.34 | sibiria | acceptable* is the correct word |
| 22:26.14 | giaco | sibiria: wonder if this requirement can compete with gsm voice on rural areas |
| 22:27.57 | sibiria | 16 kbit/s opus sounds about the same as toll quality |
| 22:28.00 | sibiria | speex a bit worse |
| 22:28.08 | sibiria | 24 kbit/s opus sounds better |
| 22:28.30 | sibiria | it's around the same as g.722 |
| 22:29.09 | giaco | sibiria: I think I'm going to setup an asterisk just to test this |
| 22:29.51 | giaco | I want to test how far can I go with a voip client on smartphone + opus + asterisk sip server |
| 22:36.31 | sibiria | there may also be a lot of youtube examples of opus' audio quality at various bitrates |
| 22:36.41 | sibiria | or downloadable examples etc. |
| 22:37.01 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 22:51.19 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 23:01.32 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 23:17.40 | *** join/#asterisk jkroon (~jkroon@165.16.203.109) |