| 00:36.41 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 00:36.41 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:30.56 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 06:32.57 | *** join/#asterisk-dev michael_work_ (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 06:33.21 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 07:00.51 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:00.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:32.23 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:57.54 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:57.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:00.45 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 09:05.05 | skrusty | morning |
| 09:09.50 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:09.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:20.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:00.10 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 10:00.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:04.51 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 10:04.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:53.36 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 11:53.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:10.47 | *** join/#asterisk-dev mwilly (~mwilly@mailout.cttw2.org) |
| 12:11.05 | *** part/#asterisk-dev mwilly (~mwilly@mailout.cttw2.org) |
| 12:42.24 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 12:46.09 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 12:58.55 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:58.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:13.57 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:41.09 | file | yolo |
| 13:47.05 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 13:47.34 | skrusty | any idea why i might (sometimes) not get a ringing event on ARI although i get progress on the channel? |
| 13:52.11 | file | define progress |
| 13:52.34 | skrusty | as soon as my mobile rings, i see SIP/e8LkqRe2Jz-00000008 is making progress at the console |
| 13:52.41 | skrusty | but no StateChange event |
| 13:54.12 | file | hum, I don't think we have a state for that |
| 13:54.26 | skrusty | Ringing? |
| 13:55.31 | file | progress isn't ringing |
| 13:55.43 | file | progress is an audio stream which conveys progress, it may be ringing - it may not be |
| 13:55.50 | file | (generally) |
| 13:55.54 | skrusty | ah, ok |
| 13:57.43 | skrusty | right. when a call a sip uri for the phone on my desk, i get ringing statechange, but not for my mobile going out via a sip provider. |
| 13:57.53 | skrusty | is confused |
| 13:58.12 | skrusty | when i even |
| 14:03.15 | *** join/#asterisk-dev nix8n82 (~AndChat28@2600:100e:b02a:5a39:cc8d:d1f4:1448:a3e3) |
| 14:03.27 | file | when mjordan returns let's discuss it |
| 14:07.54 | skrusty | ok :) |
| 14:08.16 | skrusty | i've confirmed with wireshark too, that the event isn't raised (not some framework issues) |
| 14:08.54 | skrusty | going to check for SIP 180 too |
| 14:09.19 | file | it'll be a 183 |
| 14:09.28 | skrusty | ah, cheers |
| 14:12.20 | skrusty | so i get 183 |
| 14:12.42 | skrusty | but no indication that the channel is ringing |
| 14:12.54 | file | right, cause that doesn't generate a ringing state change (and it shouldn't) |
| 14:13.04 | file | the problem being that you get nothing |
| 14:13.30 | skrusty | so i get 100, 183, 200 (OK) and ACK |
| 14:13.54 | file | yup |
| 14:14.16 | skrusty | so... how do i know the other end is ringing, sorry. Is this an issue external to * or something else? |
| 14:14.35 | skrusty | (thank you by the way :) |
| 14:14.37 | file | the 183 may or MAY NOT contain ringing |
| 14:14.39 | Marquis42 | skrusty: It isn't, necessarily, ringing. |
| 14:14.59 | Marquis42 | It may or MAY NOT even contain early media of any kind. There's no guarantee of it. |
| 14:17.34 | file | the real world is a harsh place |
| 14:17.39 | skrusty | hehe :) |
| 14:18.14 | Marquis42 | I do think that it'd be good to have some state change to indicate progress, though. |
| 14:18.57 | file | yes |
| 14:23.19 | skrusty | yes, just knowing that would be useful. sip still confuses me :) |
| 14:23.34 | file | it's the old world and the new world |
| 14:27.00 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-twazyfcjrgzurtsd) |
| 14:33.03 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 14:35.00 | skrusty | call out via a different sip provider and... i get 180 Ringing. |
| 14:35.22 | skrusty | and 183 progress |
| 14:35.36 | file | the 180 is likely fake |
| 14:35.58 | skrusty | you think they insert it before sending 183? |
| 14:36.07 | file | yes |
| 14:36.13 | skrusty | now, if only i could do that! ;) |
| 14:44.47 | jsmith | skrusty: It's easy to simulate that in the dialplan :-p |
| 14:46.03 | skrusty | could i just do progressinband=no |
| 14:46.29 | skrusty | reads |
| 14:56.47 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-dvgixalmbfgdkczb) |
| 14:56.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:00.53 | file | mjordan, as skrusty brought up we don't currently convey, via stasis, when a channel gets progress... |
| 15:06.49 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-bbxsxildfwtxurcy) |
| 15:06.49 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:10.33 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-qyprvvlmagzpojcf) |
| 15:12.06 | mjordan | file: hm. |
| 15:12.12 | mjordan | What's the use case? |
| 15:12.45 | skrusty | sip provider sending 183 not 180, my ari app is silent until the remote end answers |
| 15:13.12 | mjordan | well, 183 doesn't cause a change in channel state |
| 15:13.39 | mjordan | what action do you want to take when you see a 183? |
| 15:14.28 | skrusty | well, from speaking to file, most sip 180's are faked anyway, based on progress (i think it what i got out of the conversaion) so it would be nice to get notification of the progress and decide what to do |
| 15:14.54 | skrusty | but there's no way of being notified of the progress in ari |
| 15:16.00 | skrusty | does that make sense? |
| 15:16.28 | mjordan | well, that still isn't a use case :-) |
| 15:16.50 | skrusty | ok, my use case is i want to sound ringing on the first channel in my dial app :) |
| 15:17.21 | skrusty | as one of my providers doesn't send me a 180, just 183 |
| 15:17.23 | mjordan | Generally, I dislike the notion of exposing "Progress" in ARI. It's technology dependent, and isn't a channel state. But I can see why you would want to do that. |
| 15:17.53 | mjordan | And them not sending a 180 is problematic, since you won't know if the outbound attempt is doing anything at all |
| 15:18.43 | mjordan | file: in the above case, it feels like this would be a channel state |
| 15:19.20 | mjordan | which ... is unfortunate. |
| 15:19.27 | skrusty | :) |
| 15:19.57 | *** join/#asterisk-dev Dovid (~Dovid@ool-4a58488b.dyn.optonline.net) |
| 15:21.56 | file | quite |
| 15:22.00 | mjordan | Although, if you know that an outbound request is being made, you can always indicate ringing regardless. The worst that happens is you get a second of ringing followed by a busy signal, or something else. |
| 15:22.19 | oej | mjordan: Doesn't progress come from the ISDN world? |
| 15:22.26 | oej | we have progress() app for the dialplan |
| 15:23.01 | skrusty | mjordan: not a tidy option though is it, not saying my option is any better mind you. |
| 15:23.02 | oej | skrusty: If a provider sends you ring tone in 183 without 180 first then you should propably put them against the wall. |
| 15:23.10 | skrusty | ringing followed by busy sounds like it would confuse :) |
| 15:23.18 | mjordan | oej: yeah, which is why I dislike exposing it in a higher level API. Right now, in ARI, if you take a media operation and the channel isn't up, we just silently indicate progress for the user |
| 15:23.28 | oej | There are cases where 183 preceedes an error message like 183 "You are not allowed to skrunk my plunk" and then 403 |
| 15:23.31 | skrusty | oej: no, they don't. there's just nothing. 183, then 200 |
| 15:23.46 | oej | I had that issue with originate |
| 15:23.47 | mjordan | oej: much less exposing it in the channel core :-P |
| 15:23.49 | skrusty | so you could have 5 seconds of silence |
| 15:23.58 | oej | I had to expose early media to originated calls - but we made it an option. |
| 15:24.09 | oej | Don't know if that code ever made it into trunk, but we use it in call centers |
| 15:24.20 | oej | So AMI clients will want to know about early media. |
| 15:24.21 | mjordan | oej: it's in there |
| 15:24.24 | oej | Sorry ARI |
| 15:24.35 | skrusty | oej: yeah |
| 15:24.40 | skrusty | my point in case |
| 15:24.54 | mjordan | oej: and the handling of early media works just fine. The problem is that there's no indication to the higher level application that early media is occurring |
| 15:25.06 | oej | I would want to know that. |
| 15:25.18 | oej | We're bridging a call that's not up, but we are still changing the state. |
| 15:25.20 | mjordan | which is fair, but the devil is in the details. |
| 15:25.40 | mjordan | right now, you'd be notified that your channel is 'ringing', or 'up', or some other aspect of channel state |
| 15:25.52 | oej | The BIG problem is the f***ing guys that send ring tones with 183 |
| 15:25.55 | file | the ARI origination does not currently allow you to bridge before answer |
| 15:25.59 | mjordan | if you wanted to be notified that 'your channel is getting early media', that would be a channel state |
| 15:26.05 | oej | They should have 180 with SDP. |
| 15:26.10 | mjordan | file: true |
| 15:26.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:26.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:26.21 | oej | (Honestly, I never looked into asterisk in that case. We should propably clean up our own act) |
| 15:27.09 | oej | The use case in call centers is taht we call out and get an operator message "Number is not active. User has moved to 12345868686868" |
| 15:27.35 | oej | Before my originate patch, those messages was lost in another universe, propably a parallell one where early media goes on retirement |
| 15:28.01 | oej | You want to catch that case and decide what you want to do with this media |
| 15:28.47 | skrusty | hehe :) |
| 15:29.26 | oej | What you do not want to do is have your agents listening to ring tones, but that is the side effect⦠Sadly. |
| 15:29.36 | oej | Yes, we have a war about that with many carriers. |
| 15:30.45 | mjordan | so, let's say we wanted to inform a third party application that an outbound channel has had progress initiated on it, and there is no 180 provided by the far end to change the channel state to Ringing |
| 15:31.14 | mjordan | Would that be a new channel state? Or something else? |
| 15:31.27 | skrusty | would seem tidy to have a channel state, but not sure what |
| 15:31.29 | mjordan | I can't think of an agnostic way to do that that doesn't involve AST_STATE_PROGRESS or something along those lines |
| 15:31.35 | mjordan | skrusty: tidy is one word for it |
| 15:31.40 | skrusty | :) |
| 15:31.43 | mjordan | There's a large ripple effect to that change |
| 15:31.44 | file | I think a state makes sense but the repercussions of that make me slightly concerned |
| 15:31.50 | mjordan | yeah. |
| 15:31.54 | skrusty | yeah, i would imagine so |
| 15:31.54 | mjordan | easy to add, not easy to predict |
| 15:32.20 | skrusty | thing is, can app_dial get notification of progress? |
| 15:32.27 | file | it already does |
| 15:32.29 | mjordan | it already handles that magically |
| 15:32.35 | skrusty | then it's a given that ari should |
| 15:32.36 | file | all origination stuff already does |
| 15:33.28 | oej | Hmmm |
| 15:33.44 | oej | I remember having this discussion before. |
| 15:34.02 | oej | Like "how do we map early media and hold to channels states"? |
| 15:34.06 | oej | They're media states really. |
| 15:34.22 | oej | If we have media and the channel is not in UP state, the media is early |
| 15:34.43 | mjordan | yup. |
| 15:34.51 | oej | We can have media in Ring and Ringing state |
| 15:35.08 | oej | I hope we can't have media in DOWN state. |
| 15:35.13 | mjordan | I understand the difference between the two, but I never liked that distinction |
| 15:35.15 | oej | We'll have to ask NSA about that. |
| 15:35.23 | skrusty | :] |
| 15:35.42 | oej | we can have RING, RING+EARLY, RINGING, RINGING+EARLY, UP, UP+HOLD |
| 15:35.52 | mjordan | oej: well, or you could have two media states per channel. |
| 15:36.01 | mjordan | one for each direction. |
| 15:36.11 | oej | HOLD is like that |
| 15:36.23 | oej | UP+HOLD+REMOTEHOLD, UP+REMOTEHOLD, UP+HOLD, UP |
| 15:36.33 | oej | and UP+INACTIVE |
| 15:36.46 | mjordan | oej: sort of feels like just exposing the SDP attribute is easier :-P |
| 15:37.02 | Qwell | Let's just take out non-SIP channel drivers. |
| 15:37.12 | oej | I have told Matt taht we should use SDP in the next version of OpenPRILib but he has refused so far |
| 15:37.19 | mjordan | the problem this gets into is Asterisk's cludgy media representation in the channel core. |
| 15:37.25 | mjordan | heh |
| 15:37.40 | oej | Why do we keep having an ISDN core? |
| 15:37.46 | oej | We keep fighting it |
| 15:38.13 | oej | SIP2ISDN and ISDN2SIP and⦠|
| 15:38.36 | mjordan | I'm still trying to get people to use the new stuff we just made, I'm not sure what the reaction would be if we told everyone "all of your channel states have totally changed". |
| 15:38.42 | mjordan | (Not that I'm against that effort) |
| 15:39.26 | oej | You're the man to tell the crowds that. |
| 15:39.31 | oej | Then duck and run very, very fast. |
| 15:39.34 | skrusty | :) |
| 15:39.36 | file | it would be nice long term |
| 15:39.39 | oej | Or you can simply delegate to file. |
| 15:39.44 | oej | It's a long term project. |
| 15:39.52 | file | but this doesn't help skrusty now |
| 15:39.54 | oej | File: Remember the discussion about pluggable PBXs? It's time for that. |
| 15:40.01 | skrusty | dont put my name down as the suggester, i'll be a figure of hate! :) |
| 15:40.26 | oej | By default we blame file. SO don't you worry. |
| 15:40.35 | skrusty | yeah, make sense! |
| 15:41.39 | oej | Any way, I do agree that we short term need to expose an early media state |
| 15:41.48 | mjordan | skrusty: if you're interested in writing a patch for this, adding a single channel state for AST_STATE_PROGRESS wouldn't be terribly hard. You could then look to see in chan_sip/chan_pjsip (whichever you're using) we receive a 183 - and, if the state is not currently RINGING - change it to PROGRESS |
| 15:45.27 | oej | But that's hard. To get the difference between RINGING and RINGING+PROGRESS I have to remember that last state was ringing. |
| 15:45.52 | oej | The same goes for RING - RING+PROGRESS that may either result in Error or UP or traverse to RINGING |
| 15:45.59 | oej | Sorry to confuse matters. |
| 15:46.01 | mjordan | oej: theoretically, the channel core could handle it. It has the state of the channel |
| 15:46.45 | mjordan | interesting. We no longer use AST_STATE_MUTE anywhere. |
| 15:47.21 | oej | Maybe we can reuse that state for something else. Like AST_STATE_CONFUSED |
| 15:47.24 | oej | :-) |
| 15:48.22 | oej | A group name that is compatible with AST_STATE_DOWN+AST_STATE_PROGRESS with a touch of AST_STATE_HAPPY |
| 15:48.40 | oej | Sorry, we deprecated AST_STATE_HAPPY in 1.2. Me old. |
| 15:48.55 | skrusty | heh :) |
| 15:49.22 | skrusty | my skills are in c#, i fear hl3 might be out before i got that patch right ;) |
| 15:51.31 | mjordan | oej: lol |
| 16:17.55 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-azaabywavcgqizye) |
| 16:23.01 | skrusty | mjordan: i'll take a look at the code :) |
| 17:08.12 | stefan27 | Progress() is a wonderful dialplan app |
| 17:17.05 | stefan27 | For some reason I have to do Progress() (or Answer()) before Dialing a sip peer with encryption=no, from a sip peer with transport wss and encryption=yes, or dtls-handshake fails |
| 17:17.14 | *** join/#asterisk-dev Dovid (~Dovid@173.63.105.210) |
| 17:22.09 | *** join/#asterisk-dev oej (~Adium@2.68.247.239.mobile.tre.se) |
| 17:22.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:24.40 | oej | Have you made any PROGRESS on the early media? |
| 17:25.45 | Marquis42 | Well played, oej |
| 17:25.54 | skrusty | heh :) |
| 17:26.10 | oej | Took along time to figure out that line |
| 17:26.20 | jsmith | stefan27: Yeah, I like Progress(), although Proceeding() is nice too :-) |
| 17:26.21 | WIMPy | While early media seems to 'work most of the time', a state for disconnected channels would be extremely helpfull. |
| 17:26.33 | mjordan | oej: m=audio 0 RTP/AVP 98 97 99 3 0 8 9 96 |
| 17:26.41 | WIMPy | And a state or a flag for answered channels that are available for pickup. |
| 17:27.33 | oej | mjordan: You lack the RTPMAP for that offer. Even if you have port 0 |
| 17:28.27 | stefan27 | refering to https://tools.ietf.org/html/rfc5763#page-14 section 7.1 my SIPml5 WSS sip peer is basically Alice and Asterisk is basically Bob. It seems like Bob(asterisk) is sending (unencrypted) early media long before it has started the dtls-handshaking (sent a clientHello) is that supposed to happen? |
| 17:28.56 | stefan27 | when a sip peer with DTLS calls another SIP peer with encryption=no |
| 17:35.37 | mjordan | stefan27: without looking at your configs, a pcap, and a bunch of other stuff - I don't know. I would expect that an offer that mandated DTLS/SRTP in the media transport would not allow unencrypted early media. However, some browsers are crappy at actually specifying the media transport properly. |
| 17:36.04 | mjordan | stefan27: if a browser offered UDP/RTP with DTLS crypto keys, then theoretically, yes, it is saying that it would be okay with plain old unencrypted RTP, even if it really isn't. |
| 17:41.21 | stefan27 | I'm aware i would need to supply a LOT more info to explain the full setup. I really dont know if chrome40's or asterisk's dtls-implemtnation is doing anything wrong, it might just be me misconfiguring... chrome sends m=audio 59481 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126 and 80% of the time it CAN handle early media, but not if it's too much and (it multiplexes RTCP and RTP to |
| 17:41.22 | stefan27 | same port) -- i have no idea which layer this problem resides at, i just noticed empirically that setting Progress() in dialplan solved the issue |
| 17:42.36 | stefan27 | with or without Progress() it would receive unencrypted RTP before dtls handshake, just less with the latter |
| 17:46.59 | stefan27 | i'll try put some configs/logs together |
| 17:49.22 | stefan27 | problem is probably on the client-side(webrtc) anyways |
| 19:45.10 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 20:25.41 | file | gtjoseph, your config wizard gets a revie tomorrow fyi |
| 20:25.52 | gtjoseph | cool, thanks. |
| 20:26.05 | gtjoseph | i know it's a lot to go through. |
| 20:36.48 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:1:862b:2bff:fead:2cce) |
| 21:11.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 21:11.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:27.22 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:27.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:03.54 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 22:34.52 | *** join/#asterisk-dev Jacoby6000 (~jbarber@static-71-252-134-63.dllstx.fios.verizon.net) |
| 22:34.57 | Jacoby6000 | How does asterisk query the database on Switch=>Realtime for patterns? For example, searching for exten 707, how does asterisk know to look at _XXX? |
| 22:36.24 | snuff-work | if i recall.. it just keeps going though possibilties |
| 22:36.42 | snuff-work | so first 707,then 70x,7xx,xxx |
| 22:37.13 | snuff-work | but it has been many a year since i have used that feature |
| 22:38.21 | WIMPy | It would ahve to check N and Z first then. So I guess there might be soemthign else going on. But I have FNI. |
| 22:38.31 | Jacoby6000 | snuff-work, that would work, except for when it could be _70[1-5] |
| 22:38.44 | Jacoby6000 | that's where my mind gets blown |
| 22:39.28 | WIMPy | Yes, even worse. It must do it the other way round. But the answer is in te source somewhere. |
| 22:40.00 | Jacoby6000 | problem is, I don't know where... I made a venture in app_voicemail once.... I never want to look at asterisk source again |
| 22:40.02 | Jacoby6000 | lol |
| 22:40.02 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:40.28 | WIMPy | pbx_realtime.c would sound reasonable. |
| 22:40.48 | snuff-work | Jacoby6000: best way to find out.. is just to monitor your sql statements |
| 22:40.54 | Jacoby6000 | WIMPy I would think so, too... except that the same matching logic is used outside of pbx_realtime |
| 22:40.54 | snuff-work | =) |
| 22:41.16 | WIMPy | Where? |
| 22:41.45 | Jacoby6000 | snuff-work: our stuff is in production, and the database I'm using in testing is acting wonky... It can access ps_endpoints and all that, but not extensions... and asterisk is connecting as root there. |
| 22:42.18 | Jacoby6000 | WIMPy, anywhere you do exten=>_X[0-9]Nabc,1,DoSomething |
| 22:43.19 | Jacoby6000 | WIMPy: think i found it. |
| 22:43.28 | WIMPy | You mean unrelated to realtime queries? yes. |
| 22:43.29 | Jacoby6000 | and it's pretty bad lol |
| 22:44.12 | Jacoby6000 | It loads in all of the rows for the given context that are a pattern, and then runs the regular matching logic on them |
| 22:44.38 | WIMPy | Seems like the only sensible option. |
| 22:44.48 | Jacoby6000 | Yeah, I guess., |
| 22:45.00 | Jacoby6000 | welp, thanks for the help |
| 22:48.13 | Jacoby6000 | exit |
| 23:26.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-dvgixalmbfgdkczb) |