| 00:58.31 | Kobaz | Samot: older systems |
| 00:59.55 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 01:01.42 | Samot | Then you should make them not older systems. |
| 01:03.01 | Kobaz | yeap |
| 01:03.04 | Kobaz | working on that |
| 01:03.35 | Kobaz | less old |
| 01:03.47 | Kobaz | more unlegacy |
| 02:17.23 | *** join/#asterisk Duhhhhhhh (~Brad@184-090-188-182.res.spectrum.com) |
| 02:29.43 | *** join/#asterisk jeff__ (~overyande@209.141.208.197) |
| 03:47.10 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 03:51.13 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 04:37.17 | *** join/#asterisk jeff__ (~overyande@209.141.208.197) |
| 05:02.14 | *** join/#asterisk moe__sysgrammer (~sysgramme@d205-234-51-236.yt.northwestel.net) |
| 05:23.12 | Slade | wow this is some crazy pricing. https://signalwire.com/disruptive-pricing |
| 05:43.57 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 06:30.40 | *** join/#asterisk oej (~olle@h-205-16.A165.corp.bahnhof.se) |
| 06:39.11 | *** join/#asterisk hfb (~hfb@cpe-172-117-13-65.socal.res.rr.com) |
| 06:40.25 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 07:10.02 | *** join/#asterisk gavlee (~gav@unaffiliated/gavlee) |
| 07:21.16 | *** join/#asterisk tsal_ (~tsal@i59F4A40D.versanet.de) |
| 07:32.05 | *** join/#asterisk oej (~olle@h-205-16.A165.corp.bahnhof.se) |
| 07:44.45 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 08:04.19 | *** join/#asterisk BakaKuna (~user@2a04:9a00:1002:701:9864:7827:fcfb:db14) |
| 08:09.35 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 08:22.18 | *** join/#asterisk Guest2204 (~martin@185.32.9.250) |
| 08:23.43 | Guest2204 | Hello, I am having troubles with DTMF and need assistance how to troubleshoot this. I can see in my signaling logs that the DTMF is sent to the asterisk, but it is never received in the asterisk logs when dtmf debugging is enabled. I can also hear the dtmf tone on the recording. I am using rfc2833. How can I investigate this further? |
| 08:27.46 | Guest2204 | Worth to mention it works for most calls, but for some it doesn't. |
| 08:32.07 | pchero_work | Hi Guest2204: Have you tried grepping the pcaps on the machine? |
| 08:32.32 | pchero_work | May the Asterisk couldn't get the DTMF if the log doesn't say anything. |
| 08:33.35 | pchero_work | You need to check the DTMF was actually arrived to the machine using the wireshark or sngrep first. |
| 08:39.51 | *** join/#asterisk MICROburst (~Thunderbi@x4db7c0b8.dyn.telefonica.de) |
| 08:40.56 | Guest2204 | pchero_work: I will work on the pcap. It is just I cannot replicate it but have to rely on these random occuraances. |
| 08:41.00 | Guest2204 | The pcap will grow rather large I think |
| 08:41.59 | Guest2204 | How would I see a DTMF in a pcap when using rfc2833? |
| 08:46.03 | pchero_work | Simple. Just capture the RTP stream too. I would recommend use the wireshark. |
| 08:47.43 | pchero_work | If it happen randomly, I'm doubting it might be the endpoint device uses 5G or VoLTE. |
| 08:48.43 | pchero_work | I have an experience the similar problem with DTMF. The problem was the Provider. If the device connected to the 5G or VoLTE network, the DTMF didn't work well somehow. |
| 08:49.10 | pchero_work | I couldn't figured out why, because the DTMF signal didn't get to the Asterisk at all. But after change the network, it worked. |
| 08:50.13 | Guest2204 | well I do sort of a pcap in our telco environment. We use Voipmonitor. |
| 08:50.28 | Guest2204 | All calls passes through there on their way to our asterisks, and I can see the DTMF there |
| 08:51.05 | Guest2204 | But when it reaches the asterisk it seems to be lost. But I guess I have to verify that with the pcap |
| 08:51.49 | pchero_work | Yes, you have to verify it's the Asterisk fault or DTMF signalling problem first. |
| 09:15.54 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 09:16.33 | *** join/#asterisk hfb (~hfb@cpe-172-117-13-65.socal.res.rr.com) |
| 09:19.22 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:25.09 | *** join/#asterisk mahlon (~mahlon@martini.nu) |
| 09:26.24 | *** join/#asterisk spatel (~spatel@171.61.9.63) |
| 09:36.09 | *** join/#asterisk Andee (~Andee@ip222.ip-145-239-221.eu) |
| 09:47.30 | Guest2204 | pchero_work: I managed to get a pcap now of one of these, lets see |
| 09:50.32 | pchero_work | :thumup: |
| 09:59.24 | *** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:59.58 | *** join/#asterisk war9407 (war@2600:4040:4001:1e00::f7aa) |
| 10:01.11 | Guest2204 | ok I have the sip & rtp filter for the call now. Now how do I tell a RTP package is DTMF or not? |
| 10:01.19 | Guest2204 | As you might understand there is a lot of udp rtp packages |
| 10:04.27 | *** join/#asterisk jkroon (~jkroon@41.114.164.53) |
| 10:16.52 | oej | You could look at the size, dtmf is much smaller than audio. You could also check the payload number. Very often, DTMF has payload 101, but not always. |
| 10:18.31 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 10:29.18 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 10:38.09 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 10:49.07 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 11:02.07 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 12:09.37 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 12:16.05 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 12:52.05 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 13:02.33 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:834a:216:3eff:fefe:444f) |
| 13:25.02 | *** join/#asterisk mbecroft (mb@ak2.becroft.co.nz) |
| 13:35.30 | *** join/#asterisk dacod (~dacod@201.47.74.146) |
| 13:40.36 | *** join/#asterisk jkroon (~jkroon@41.113.121.107) |
| 13:41.36 | *** join/#asterisk miralin (~Thunderbi@178.34.163.234) |
| 13:54.37 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@41.249.114.105) |
| 14:00.49 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 14:03.48 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 14:10.29 | *** join/#asterisk spatel (~spatel@171.61.9.63) |
| 14:36.14 | *** join/#asterisk BakaKuna (~user@ip56509c03.direct-adsl.nl) |
| 14:38.34 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 14:40.27 | *** join/#asterisk miralin (~Thunderbi@178.34.163.234) |
| 14:56.54 | *** join/#asterisk miralin1 (~Thunderbi@178.34.163.234) |
| 15:00.34 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 15:08.48 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-qtccyxvqpfjqqhmi) |
| 15:08.48 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:26.06 | *** join/#asterisk zapata (~zapata@2a02:1748:f71:380:b9ff:d644:4efa:5c6a) |
| 15:28.52 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-fqudetitefybjfqy) |
| 15:28.52 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:32.36 | *** join/#asterisk spatel (~spatel@171.61.9.63) |
| 15:42.02 | *** join/#asterisk NWATechSupport (~NWARSciGu@wsip-72-204-193-12.ks.ks.cox.net) |
| 15:42.02 | sibiria | is there a way to have res_curl accept non-matching certificates when doing https? |
| 15:42.18 | sibiria | for e.g. media-cache functionality |
| 15:42.19 | NWATechSupport | You guys have an inexpensive soft phone you like and recommend? |
| 15:42.49 | Samot | Bria. |
| 15:43.01 | NWATechSupport | Danke |
| 16:06.42 | sibiria | ah, CURLOPT() |
| 16:13.57 | sibiria | uff, does not work for actual media-cache use |
| 16:14.23 | sibiria | just for func_curl |
| 16:14.54 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 16:15.04 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 16:39.42 | *** join/#asterisk alexandre9099 (~alexandre@unaffiliated/alexandre9099) |
| 16:59.29 | *** join/#asterisk jkroon (~jkroon@165.16.203.105) |
| 17:01.14 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 17:28.43 | sibiria | does anyone happen to know if 8khz wav (signed 16-bit pcm) is costlier to convert in real time than asterisk's "slin" format in same sample rate? |
| 17:29.20 | sibiria | they *should* be the same, but....who knows |
| 17:29.38 | file | it doesn't convert |
| 17:29.44 | file | well, to be more specific |
| 17:29.52 | file | format_wav provides slin or slin16 natively |
| 17:31.00 | igcewieling | sibiria: converting between alaw, ulaw, and any of the sln formats should be a very low CPU task. |
| 17:31.25 | sibiria | ok so using 8khz 16-bit signed wav - the normal stuff, in other words - when converting to alaw/ulaw in real time should be just as fast as if i source them as slin/16 |
| 17:32.13 | igcewieling | sibiria: it should be. I personally use sln16 for everything I can and let Asterisk transcode it to a lower quality codec if required. That way the source audio is high quality. |
| 17:32.18 | file | yes |
| 17:32.56 | igcewieling | I use mainly g722 and ulaw, with transcoding to g729 with a hardware card when needed. |
| 17:33.23 | igcewieling | file: Sangoma includes g729 codec in the Discro. Any plans on adding it to the main Asterisk codebase? |
| 17:33.42 | file | that's above my paygrade, but afaik no |
| 17:33.59 | sibiria | at first i was considering to keep storing both ulaw and alaw as i've always done when using local sound files, and just suffix the "audiowriteformat" onto the URL to fetch the proper file over http/https, to avoid converting at all |
| 17:34.06 | sibiria | but the solution feels a bit clumsy |
| 17:34.14 | sibiria | would be simpler to just keep a single wav file around |
| 17:34.24 | igcewieling | thanks. So many of our customers are on higher bandwidth circuits now that most of them use ulaw or g722, but there are still some left using g729 |
| 17:35.53 | sibiria | i find g.729 terrible in so many ways |
| 17:36.02 | sibiria | sure, it's pretty compact, but..... |
| 17:37.05 | igcewieling | It us useful when the customer uplink to the internet is a 1.5Mbps T-1 |
| 17:37.24 | sibiria | gotta move out of the 1990s at some point |
| 17:37.49 | igcewieling | sibiria: the telco needs to make more modern service available. |
| 17:37.51 | *** join/#asterisk i9zO5AP (~BQcdf9eiZ@105.157.5.156) |
| 17:38.09 | sibiria | i'm very fond of g.722, but it's a shame that PSTN support isn't all over yet |
| 17:38.26 | igcewieling | Any customer who can be converted to fiber has been converted to fiber. |
| 17:38.39 | sibiria | g.722 works well to most mobile recipients here in europe |
| 17:39.22 | igcewieling | *nod* The USA is a telecom backwater in many ways. |
| 17:44.23 | igcewieling | I recall an ambulance company who was in an area with terrible lines. We finally got VZ to replace some of the copper, and a few days later someone stole the new copper and their service was down again. |
| 17:49.03 | sibiria | happens regularly with power installations, too |
| 17:50.27 | sibiria | file: do you happen to know how long an item is cached? can other channels benefit from the cached item as well? |
| 17:50.44 | file | cached what? |
| 17:50.58 | sibiria | in my case a sound file referenced by a URI for playback/background |
| 17:51.14 | file | cached indefinitely until cleared out manually, applies to anywhere a playback is done |
| 17:51.24 | sibiria | ok, thanks |
| 17:55.46 | sibiria | and it's auto-refreshed each time referenced, it looks like |
| 17:56.04 | sibiria | asterisk appears to issue HEAD to the endpoint to check if something happened |
| 17:56.10 | file | yes |
| 17:56.14 | sibiria | awesome |
| 18:28.31 | igcewieling | *sigh* I have a customer with internet/phone service which they claim becomes unstable when there is underground activity at a construction site across the street. |
| 19:15.15 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 19:56.26 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:35d6:b778:eddb:c1ac) |
| 20:09.00 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 20:20.26 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-mbpwwwkqudwtpyrs) |
| 20:20.26 | *** mode/#asterisk [+o bford] by ChanServ |
| 20:36.00 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 21:17.21 | *** join/#asterisk aness (~aness@2a02:fe1:3103:2100:8cb1:8c48:aeb9:ea77) |
| 21:19.14 | *** join/#asterisk BakaKuna (~user@ip56509c03.direct-adsl.nl) |
| 21:23.22 | *** join/#asterisk BakaKuna (~user@ip56509c03.direct-adsl.nl) |
| 21:26.57 | *** join/#asterisk BakaKuna (~user@ip56509c03.direct-adsl.nl) |
| 21:29.18 | *** join/#asterisk war9407 (war@2600:4040:4001:1e00::f7aa) |
| 22:24.49 | *** join/#asterisk tsal (~tsal@i59F4A061.versanet.de) |
| 22:56.29 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 23:04.48 | *** join/#asterisk hfb (~hfb@47.139.16.144) |
| 23:07.31 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 23:07.44 | *** join/#asterisk moe__sysgrammer (~sysgramme@d205-234-51-236.yt.northwestel.net) |
| 23:08.05 | *** join/#asterisk sysgrammer (~sysgramme@d205-234-48-217.yt.northwestel.net) |
| 23:09.22 | *** join/#asterisk Milos_ (~Milos@pdpc/supporter/student/milos) |
| 23:10.39 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
| 23:20.01 | *** join/#asterisk rShadowhand (~Shadowhan@secretalgorithm.com) |