| 00:10.23 | *** join/#asterisk alexandre9099 (~alexandre@unaffiliated/alexandre9099) |
| 00:10.59 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:834a:216:3eff:fefe:444f) |
| 00:26.09 | DannyA | @Samot i looked at the wiki, i couldn't figure it out |
| 00:26.55 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 00:28.14 | Samot | What did you look at? |
| 00:28.36 | DannyA | https://wiki.asterisk.org/wiki/display/AST/Pattern+Matching |
| 00:29.07 | Samot | So what can't you figure out? |
| 00:29.52 | DannyA | how to configure a variable number of digits |
| 00:31.42 | Samot | Do you know the range? |
| 00:32.49 | DannyA | yes. in regex it would be something like this |
| 00:32.50 | DannyA | 4\d{3,4} |
| 00:33.00 | Samot | That's not what I asked. |
| 00:33.22 | DannyA | starts with 4, and goes from 100 - 9999 |
| 00:33.49 | Samot | Then you'll need three matches |
| 00:34.10 | Samot | _4XXX, _4XXXX |
| 00:35.40 | DannyA | right. i have that now. i was wondering if asterisk pattern matching supported a variable number of digits so you could do that in one extension |
| 00:35.42 | DannyA | guess not |
| 00:57.43 | igcewieling | no. |
| 00:58.22 | igcewieling | New Asterisk users need to be ware of premature optimization. |
| 01:16.44 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 02:21.45 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 02:21.45 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 02:50.41 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-rcrlwohbrnwowdie) |
| 02:56.38 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 04:12.39 | *** join/#asterisk nickvsnetworking (~nickvsnet@cha2353074.lnk.telstra.net) |
| 04:27.54 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 05:06.54 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:41.17 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 05:59.31 | *** join/#asterisk pchero (~pchero@ip-213-127-79-161.ip.prioritytelecom.net) |
| 06:21.56 | *** join/#asterisk miralin (~Thunderbi@178.34.150.140) |
| 06:23.45 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 06:35.56 | *** join/#asterisk led_belly (~led_belly@192.40.57.239) |
| 06:38.55 | *** join/#asterisk nickvsnetworking (~nickvsnet@cha2353074.lnk.telstra.net) |
| 07:31.49 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 07:48.47 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:51.17 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
| 09:07.26 | *** join/#asterisk nurpy (~nurps@213.152.162.15) |
| 09:34.11 | *** join/#asterisk eXistenZ (~pectic@bzq-109-65-211-127.red.bezeqint.net) |
| 09:39.34 | *** join/#asterisk rpifan (~rpifan@p200300d2671236930fffe242be2d74e1.dip0.t-ipconnect.de) |
| 09:58.56 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 10:45.41 | *** join/#asterisk Syco (~syco@86.43.69.174) |
| 10:49.43 | Syco | hi.. me again.. with a new question. In pjsip, is there a way to set the number of invite restransmissions, or the tcp connection timeout, or something to reduce when the Dial application return from failing to establish a call due to a network issue?? |
| 11:17.14 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 12:05.39 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 12:06.00 | *** part/#asterisk nurpy (~nurps@213.152.162.15) |
| 12:30.58 | *** join/#asterisk dacod (~dacod@170.247.5.85) |
| 12:44.49 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:04.25 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-eoraqtjofrrvktei) |
| 13:04.26 | *** mode/#asterisk [+o bford] by ChanServ |
| 13:04.52 | *** join/#asterisk rexwin (~rexwin@49.207.136.168) |
| 13:06.49 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 13:10.25 | rexwin | anybody know how to deploy restcomm? |
| 13:11.13 | file | you'd need to clarify what "restcomm" is |
| 13:11.35 | rexwin | Restcomm is a Java based open sourced cummincations platform. It is like the open source version of Twillio. |
| 13:19.50 | Samot | heh |
| 13:24.09 | *** join/#asterisk Deeewayne (~dwayne@2605:a601:a816:5000:f7ce:535c:c78:9ec3) |
| 14:14.34 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 14:16.06 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-pkbfphvquqyltsyk) |
| 14:16.07 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:24.18 | Samot | rexwin: More like it's the OSS version of https://www.telestax.com/restcomm |
| 14:24.37 | Samot | Who would be viewed as a competitor of Twilio. |
| 14:32.55 | *** join/#asterisk retentiveboy (~retentive@c-73-43-121-243.hsd1.ga.comcast.net) |
| 14:59.44 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1090:4e7b:d466:1320:781a:6305) |
| 15:22.36 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1090:4e7b:d466:1320:781a:6305) |
| 15:25.38 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 15:32.49 | *** join/#asterisk rpifan (~rpifan@p200300d2671236930fffe242be2d74e1.dip0.t-ipconnect.de) |
| 15:33.27 | *** join/#asterisk elguero (~miguel323@c-73-238-205-3.hsd1.nh.comcast.net) |
| 16:22.32 | *** join/#asterisk hfb (~hfb@47.139.19.17) |
| 16:32.56 | *** join/#asterisk miralin (~Thunderbi@178.34.151.71) |
| 16:37.37 | *** join/#asterisk rpifan_ (~rpifan@p4fca235b.dip0.t-ipconnect.de) |
| 16:47.07 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:834a:216:3eff:fefe:444f) |
| 16:52.49 | igcewieling | No idea why, but we had a customer leave us, then 2 weeks later, come back. |
| 16:53.03 | igcewieling | I guess our service was not so terrible after all. |
| 17:19.48 | *** join/#asterisk craigify (~craigify@2600:8807:4080:4a5::7d6) |
| 17:28.29 | *** join/#asterisk corretico (~luis@190.171.112.162) |
| 17:28.46 | igcewieling | Does anyone see a reason for this IVR to never hangup when there is no digit received? https://i.imgur.com/3kDyeUv.png |
| 17:31.58 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1090:4e7b:5ef:a21d:79bf:65a5) |
| 17:32.05 | *** join/#asterisk corretico (~luis@190.171.112.162) |
| 17:32.06 | Samot | What are the logs showing? |
| 17:32.26 | Samot | Because that would mean they didn't press anything for 90 seconds |
| 17:32.27 | igcewieling | I'll pull some logs. |
| 17:32.41 | corretico | hello all. I need some assistance. |
| 17:32.57 | corretico | I'm trying to create a PJSIP Trunk to my VoIP Provider |
| 17:33.28 | corretico | pjsip is registered and I'm able to make calls to externals phones using this trunk |
| 17:33.43 | corretico | but... I'm unable to receive calls from any external phone |
| 17:34.42 | corretico | when I receive a call I see the following error: pbx_functions.c:651 ast_func_read2: Function SIP_HEADER not registered |
| 17:34.47 | igcewieling | https://pastebin.com/BKsD4hRY |
| 17:35.12 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 17:35.13 | igcewieling | Try PJSIP_HEADER |
| 17:40.37 | Samot | Well, this is an out of date IVR module. |
| 17:41.45 | igcewieling | I'll run module update and see if that helps. |
| 17:42.40 | Samot | Well... |
| 17:42.42 | Samot | Hang on. |
| 17:43.02 | Samot | I know this is out of date because it's not the *NEW* method. |
| 17:43.34 | Samot | Which changes how this works. When people just updated when it was first introduced without looking, it broke their IVRs. |
| 17:43.36 | igcewieling | Ah, mirror2.freepbx.org is not reachable, that would prevent any updates. |
| 17:44.10 | Samot | So that was a test call by you? |
| 17:44.48 | igcewieling | No, that was a call stuck in the IVR for 90 mins. |
| 17:44.56 | igcewieling | https://downforeveryoneorjustme.com/mirror2.freepbx.org |
| 17:47.55 | igcewieling | BTW, should there be a module Phone Book with a version 2.11.something ? |
| 17:48.05 | Samot | [2020-06-05 13:25:14] VERBOSE[18358][C-0000010e] pbx.c: [2020-06-05 13:25:14] -- Executing [s@ivr-3:19] Goto("DAHDI/i1/9518781278-77", "timeconditions,1,1") in new stack |
| 17:48.10 | Samot | What is that? |
| 17:48.24 | Samot | Because that loops through every time the timeout is hit |
| 17:48.34 | Samot | The IVR isn't even going to the t extension. |
| 17:48.50 | igcewieling | I'll take a look |
| 17:49.00 | *** join/#asterisk eXistenZ (~pectic@bzq-109-65-211-127.red.bezeqint.net) |
| 17:49.15 | Samot | Is there an IVR option that goes to a Time Condition? |
| 17:50.14 | igcewieling | Not on this IVR, but there are ring groups which might have time conditions. |
| 17:50.24 | Samot | [2020-06-05 13:25:14] VERBOSE[18358][C-0000010e] pbx.c: [2020-06-05 13:25:14] -- Executing [1@timeconditions:18] GotoIf("DAHDI/i1/9518781278-77", "1?ivr-3,s,1") in new stack |
| 17:50.27 | Samot | That's your problem. |
| 17:50.44 | Samot | They are going to the TC destination from the IVR that is then sending them back to the same IVR |
| 17:51.25 | igcewieling | The call comes into a time condition before it goes to the IVR. |
| 17:51.27 | Samot | So this call wasn't stuck in the IVR, it was being sent out and sent back in |
| 17:51.38 | Samot | This is what the log shows. |
| 17:52.11 | Samot | s@ivr-3:19 so what ever is priority 19 in that config...is a GoTo to the TC |
| 17:52.22 | Samot | Then the TC sends them right back into the IVR |
| 17:53.04 | igcewieling | I'll dig into the time conditions |
| 17:53.38 | Samot | It could be the direct dial |
| 17:55.23 | Samot | Wait... |
| 17:55.30 | Samot | This is being sent to the Inbound Route |
| 17:55.36 | Samot | Then back to the TC |
| 17:56.09 | Samot | [2020-06-05 13:14:24] VERBOSE[18358][C-0000010e] pbx.c: [2020-06-05 13:14:24] -- Executing [s@ivr-3:18] NoOp("DAHDI/i1/9518781278-77", "CallerID Entry Point") in new stack <-- This is the priority before hitting the TC again.. |
| 17:56.25 | Samot | "CallerID Entry Point" is only a NoOp in the Inbound Routes context |
| 17:56.42 | igcewieling | The inbound route points to the timeconditions |
| 17:56.46 | Samot | Right |
| 17:56.50 | Samot | So there's your loop |
| 17:57.06 | Samot | IVR sends the call back to the inbound route, that sends it to the TC that sends it back tot he IVR |
| 17:57.13 | Samot | Rinse, repeat for 30 minutes |
| 17:57.19 | igcewieling | How would you setup a DID with a day/night mode which gets routed to an IVR when in day mode? |
| 17:57.54 | igcewieling | and timesout to a hangup |
| 17:58.24 | Samot | Well, the Inbound Route needs to be set to the Call Flow Control destination. |
| 17:58.30 | Samot | Then "Day" needs to be set to the TC |
| 17:58.49 | Samot | Or the IB route to the TC and the TC to the CFC destination |
| 17:58.56 | Samot | Then "Day" goes to the IVR |
| 17:59.03 | Samot | "Night" goes somewhere else. |
| 18:01.16 | igcewieling | ah. Apparently I need time conditions too. |
| 18:01.38 | igcewieling | the day/night mode appears to be there to override the time conditions. |
| 18:05.13 | Samot | Yeah, that makes sense |
| 18:05.57 | igcewieling | Tangent: it might be handy for FreePBX to support a "one time scheduled" feature. I have one in our internal GUI which lets us setup a one-time forward off or one time forward on to run at a specific time. That way when some *censored* *censored* *censored* customer asks us to "Change the forwarding on extension 123 at 6am on Monday" or something similar. |
| 18:06.30 | igcewieling | we don't have to make sure someone is awake and working at 6am on Monday. |
| 18:08.19 | *** join/#asterisk pchero_work (~pchero@ip-213-127-79-161.ip.prioritytelecom.net) |
| 18:08.56 | igcewieling | https://i.imgur.com/Naufzho.png |
| 18:10.39 | igcewieling | I'll have to try some things with the time/day/ivr after hours when I won't mess up calls. |
| 18:11.10 | Samot | So what happens when at 5:50AM they call to say, don't change the forward. |
| 18:12.04 | igcewieling | That never happens, but if it did, the call would go to the answering service and eventually around 9:30am someone will look at it. |
| 18:13.55 | igcewieling | We have someone who deals with service outage messages overnight, but I doubt they would consider that an out of service issue. If they did, they would be able to change the forwarding. |
| 18:15.07 | igcewieling | If we started getting lots of outage routers, then the overnight person would call me. Otherwise, a ticket is opened with the carrier on the problem circuit. |
| 18:15.23 | igcewieling | If we start getting lots of outage reports. |
| 18:16.24 | igcewieling | 90% of the forwarding change requests come from customers running FreePBX and could easily forward the number themselves. |
| 18:36.06 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 18:41.12 | *** join/#asterisk miralin1 (~Thunderbi@178.34.151.71) |
| 18:51.08 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
| 19:01.18 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 19:11.12 | ilius | Do any of you use preemptible linux kernels for your Asterisk servers? I wonder if it helps RTP streams as packets interrupt the kernel or if it doesn't matter if Asterisk is scheduled with FIFO or RR anyway. |
| 19:19.01 | *** part/#asterisk rexwin (~rexwin@49.207.136.168) |
| 19:56.24 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 20:08.31 | drmessano | ilius: How many concurrent calls are you pushing? |
| 20:42.36 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 20:46.57 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 20:48.26 | ilius | My quest for preemption comes from packets getting dropped when app_queue has lots of calls queued. If I queue more than, say, 50 calls, audio starts to get choppy, even thought he CPU is bored. |
| 20:49.38 | ilius | I got around this by limiting queue depths and doing direct RTP so the queueing Asterisk server does not relay sound, so audio for real calls never chops. |
| 20:51.46 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 20:51.53 | igcewieling | ilius: try setting transcode_via_sln=no in /etc/asterisk/asterisk.conf |
| 20:52.07 | igcewieling | Asterisk has to be restarted to apply this change. |
| 20:52.26 | igcewieling | see if that helps reduce CPU usage. |
| 20:56.21 | igcewieling | you could also try transmit_silence=no but I'm not sure how much difference it will make. |
| 20:57.46 | ilius | With app_queue, it's not cpu usage (actual number crunching), it's cpu mutex locking. I only use g711 mulaw, so transcoding isn't a thing for me. |
| 20:58.24 | igcewieling | What version of Asterisk |
| 21:00.03 | ilius | I'm currently 13.13 in production, but updating soon to 16.8-cert2 after I have all the pjsip naming change wrinkles ironed out. |
| 21:02.14 | ilius | If you want more in-depth explanation of what I say about app_queue above, this does a good job: https://community.asterisk.org/t/deep-acd-queueing-with-app-queue-c-causes-denial-of-service-on-systems-with-a-high-core-count-by-excessive-thread-mutex-locks/65730 |
| 21:03.14 | ilius | But I'm not really asking about that... I was mostly wondering about other Asterisk people's opinions about or use of preemptible kernels. |
| 21:42.29 | *** join/#asterisk miralin (~Thunderbi@178.34.151.71) |
| 21:46.04 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 22:11.44 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 22:25.56 | *** join/#asterisk Oatmeal (~Suzeanne@ip68-4-181-8.oc.oc.cox.net) |
| 22:35.54 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 22:40.28 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 22:44.36 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 23:29.08 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 23:34.49 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:6ded:81e5:709d:37cb) |
| 23:51.48 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
