| 00:44.56 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 00:44.58 | grummund | is migrating from sip.conf to pjsip.conf |
| 00:46.59 | grummund | it seems that the endpoint section name must be the same as the aor section name, as well as having a aors=... line referencing the same name. |
| 00:48.34 | grummund | by following the examples i have it working, but is there somewhere that explains the semantics and rationale? |
| 00:48.57 | aoeui | Anyone here using Mobile Bria, and on the beta, and using TLS? |
| 00:49.03 | aoeui | SRTP? |
| 00:49.37 | aoeui | I've been emailing counterpath support and their new release has issues with the GCM AES ciphersuites |
| 00:49.59 | aoeui | Wondering if anyone has seen this, or some sorts of issues with GCM AES |
| 00:50.09 | aoeui | (Running Asterisk 18.1.0 and its broken with the beta) |
| 00:50.22 | aoeui | I can file a Jira ticket, just seeing if anyone has seen it here |
| 00:50.47 | aoeui | Counterpath just added some additional ciphersuites in the beta and it caused a regression |
| 00:54.59 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:00.00 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:05.38 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:10.37 | *** join/#asterisk hfb (~hfb@47.139.22.184) |
| 01:11.21 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:16.47 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:17.35 | dongs | its terrible that zoiper (waht an ugly ass name) is the only non-subscription mobile solution for sip + iax |
| 01:17.42 | dongs | all the alternatives are awful |
| 01:19.26 | Samot | And the majority don't do IAX |
| 01:20.53 | dongs | i didnt look hard but I didnt find any that did iax other than zoiper |
| 01:21.13 | aoeui | IAX is a thing? |
| 01:21.17 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:21.50 | dongs | yeah im using that on my sellfone to talk to asterisk. did it before for NAT reasons, didnt bother changing after removing nat |
| 01:22.02 | dongs | it just works |
| 01:24.59 | Samot | Well IAX is a thing for like 2, maybe three, platforms. |
| 01:25.04 | Samot | Sooo. |
| 01:30.52 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
| 01:40.11 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
| 01:46.48 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 01:52.18 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:00.44 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:03.49 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:07.52 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:15.17 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-102-131-177.ks.ok.cox.net) |
| 02:16.42 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 02:24.05 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:31.32 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 02:36.01 | *** join/#asterisk tsal_ (~tsal@i59F5F225.versanet.de) |
| 02:39.23 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:39.37 | drmessano | IAX is extinct |
| 02:43.39 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 02:43.42 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:52.52 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 02:59.12 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 03:42.22 | *** join/#asterisk electronic_eel_ (~quassel@213.240.182.63) |
| 04:36.10 | *** join/#asterisk hfb (~hfb@cpe-75-82-92-216.socal.res.rr.com) |
| 05:00.34 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 05:02.17 | *** join/#asterisk ih8wndz (jwpierce3@mail.zero.svr.trnkmstr.com) |
| 05:13.36 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 05:15.09 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 05:25.59 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 05:36.14 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 05:40.25 | *** join/#asterisk avb (~avb@45.55.203.176) |
| 05:41.06 | avb | hey guys, im a bit lost. why abc123 cant be matched by _abcX. pattern? :) |
| 05:41.43 | avb | nor _abc[0-9]. |
| 05:52.30 | avb | now even more funny. _ivr. matches ivr1234 , but _agent., doesnt match agent1234 |
| 07:01.13 | *** join/#asterisk electronic_eel (~quassel@213.240.182.63) |
| 07:03.13 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 07:17.36 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 07:21.02 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 07:24.12 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 07:30.40 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:91e9:4e6d:1f2c:193c) |
| 07:30.41 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 07:31.04 | *** join/#asterisk nix8n82 (~AndChat19@205-170-75-78.dia.static.qwest.net) |
| 07:34.39 | *** join/#asterisk x86 (~x86@69-174-155-19.bltnilaa.metronetinc.net) |
| 08:25.38 | *** join/#asterisk yoavz (~yoavz@82.166.176.37) |
| 08:46.10 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 09:09.25 | *** join/#asterisk sinaowolabi (~Sina@169.159.69.42) |
| 09:10.34 | *** join/#asterisk sinaowolabi (~Sina@169.159.69.42) |
| 09:20.25 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 09:53.47 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 12:47.39 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 13:28.01 | avb | no ideas guys? :) |
| 13:29.52 | sibiria | avb: are you sure it's just not that another extension picks up the pattern match first? |
| 13:29.59 | sibiria | since they have a certain sorting order |
| 13:30.58 | avb | sibiria: no sir |
| 13:31.16 | avb | as a workaround ive made '_age.' |
| 13:31.27 | avb | that matches agent1234 :) |
| 13:31.34 | sibiria | and it starts with prio 1? |
| 13:31.39 | avb | yep |
| 13:31.58 | avb | > dialplan show agent124@in |
| 13:32.12 | avb | '_age.' => 1. Set(agentExt= |
| 13:32.30 | avb | and this one doesnt work |
| 13:32.33 | avb | <PROTECTED> |
| 13:32.47 | sibiria | out of curiosity, what if you turn the nomenclature around? |
| 13:32.48 | sibiria | 1234agent |
| 13:33.02 | avb | haha, good idea |
| 13:33.09 | avb | let me see |
| 13:33.30 | sibiria | but it does sound a bit iffy that it only matches the first 3 non-numerical characters |
| 13:34.18 | file | some letters have meaning besides the letter |
| 13:34.25 | avb | > dialplan show 1234agent@in |
| 13:34.33 | file | I forget how to tell it to treat it as a letter |
| 13:34.33 | avb | '_X.agent' => 1. Set(a |
| 13:34.36 | avb | that works :) |
| 13:34.53 | avb | file: thats what ive thought |
| 13:35.23 | avb | seems n treats as a control chanr |
| 13:35.26 | avb | char |
| 13:35.40 | file | The letter N or n represents a single digit from 2 to 9. |
| 13:36.20 | avb | let me try something |
| 13:36.53 | file | _age[n]t. |
| 13:37.26 | avb | bingo! |
| 13:38.09 | avb | thank you guys, i been feeling bad leaving _age. in the config :) |
| 13:38.11 | sibiria | i thought 2-9 was Z |
| 13:38.21 | sibiria | or Y |
| 13:39.05 | file | https://wiki.asterisk.org/wiki/display/AST/Pattern+Matching |
| 13:39.06 | avb | there are couple of them I think with a small differennce |
| 13:47.48 | Samot | Z is 1-9 |
| 13:47.54 | Samot | N 2-9 |
| 13:47.57 | Samot | X 0-9 |
| 14:00.02 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 14:14.21 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:30.44 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 14:34.43 | *** join/#asterisk overyander (~overyande@216.163.21.11) |
| 14:38.31 | *** join/#asterisk Kernkraft4Ever (~quassel@2001:16b8:c108:a800:fec5:6e09:50aa:1058) |
| 14:44.56 | *** join/#asterisk Andee (~Andee@docker.cassidyweb.co.uk) |
| 14:45.04 | *** join/#asterisk AndChat|19361 (~AndChat19@2600:100e:b013:84ba:253c:1ef9:a936:4f14) |
| 14:57.53 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 14:59.23 | *** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk) |
| 15:00.46 | *** join/#asterisk nix8n82 (~AndChat19@205-170-75-78.dia.static.qwest.net) |
| 15:23.48 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-rjkbpneszmxlbvua) |
| 15:23.48 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:31.00 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:35.45 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-plwamoyxjxkyuzgb) |
| 15:35.45 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:55.29 | *** join/#asterisk wdoekes (~walter@wjd.osso.nl) |
| 15:55.29 | *** mode/#asterisk [+o wdoekes] by ChanServ |
| 16:20.51 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 16:39.30 | *** join/#asterisk hfb (~hfb@47.139.22.184) |
| 17:01.20 | *** join/#asterisk hfb (~hfb@47.139.22.184) |
| 17:04.16 | *** join/#asterisk cloud9 (cloud9@c-24-21-228-102.hsd1.or.comcast.net) |
| 17:06.24 | cloud9 | hello everyone, question about best practices for storing recordings. To date I've had MixMonitor run a bash script that immediately copies the recording to a web server at the end of the recording, specific to which account number it relates to. Is there a better solution for storing recordings in large scale? |
| 17:15.58 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 17:19.05 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 17:20.36 | *** join/#asterisk hfb (~hfb@47.139.16.87) |
| 17:22.23 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 17:23.41 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 17:24.31 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 17:24.53 | post-factum | cloud9: back in the days i was dealing with storing asterisk recordings, we used tmpfs to write them, then we used special fanotify-based daemon that would move them out of tmpfs into the gluster storage once the file gets closed |
| 17:25.47 | post-factum | cloud9: it scaled really well⦠although it may look like another sh!tty kludge |
| 17:41.07 | cloud9 | post-factum: got it. sounds like I'm doing about the same. Thanks for the response |
| 17:44.18 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 17:44.39 | jkroon | cloud9, it really depends on your use case and how you want to present/retrieve/store the data, there are different approaches. |
| 17:45.30 | jkroon | we've got at least three different strategies, but for performance reasons we tend to use Monitor rather than MixMonitor. For some reason MixMonitor causes insanely highly loads on our systems compared to Monitor. |
| 17:46.27 | post-factum | cloud9: fwiw, http://ix.io/2LVg we never published it, but there's nothing special, so you may check that |
| 17:57.50 | cloud9 | jkroon: I'll check that out. Thank you |
| 17:58.22 | cloud9 | My second concern is securing the recordings being served via apache. but that's outside the scope of this channel so I won't ask |
| 17:59.22 | cloud9 | I guess I was wondering if anyone is storing them in a database instead of filesystem |
| 17:59.32 | cloud9 | seems like filesystem is best practive |
| 17:59.35 | cloud9 | practice |
| 18:00.30 | jkroon | cloud9, we also always first record to ramdisk, and then after the fact copy to persistent storage. |
| 18:00.45 | post-factum | cloud9: iirc we tried database as well, but that didn't work because it was somewhat overloaded and didn't handle binary data properly |
| 18:00.57 | jkroon | cloud9, yes, that's one of our strategies, but to be honest, we're contemplating axing that. |
| 18:00.58 | post-factum | cloud9: i'd use normal storage, not database |
| 18:01.22 | cloud9 | thanks for the validation. appreciate it |
| 18:01.29 | jkroon | works reasonably well actually @ database. |
| 18:01.51 | jkroon | the issue we eventually picked up is that purging old data became an issue. we ended up modifying the purge strategy and all's well again. |
| 18:02.05 | jkroon | makes backups nice and concise overall (simply backup the database) |
| 18:03.45 | cloud9 | jkroon: good point |
| 18:06.07 | jkroon | so as per everything in live, and i realize this more and more, there generally isn't a single-answer-fits-all solution, and in many cases, multiple solutions will work well, however, it depends a lot on what you're trying to achieve. |
| 18:06.59 | jkroon | for example, we originally chose to use DB way back in 2008 ... to persist the data over multiple hosts in near real time. nowadays, glusterfs and cephfs are both options which didn't exist back then. |
| 18:08.10 | jkroon | so our newer systems for recordings specifically, record to ramdisk, then mix and do all the post processing there, then more it onto glusterfs, including shuffling it into account/date/time based folder structure such that no single folder have so many files that the extremely poor readdir performance over FUSE becomes too big of an issue. |
| 18:09.53 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:09.55 | jkroon | we've also long since migrated astdb onto ramdisk, because the fsync() in sqlite actually became an issue with processing times of real-time processing. We've had to make significant modifications at that point to get persistent data out of astdb ... so there you have another example of one shoe does not fit all. |
| 18:28.51 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:31.40 | *** join/#asterisk _mwoodj_ (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 18:39.49 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 18:44.34 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 18:51.00 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:54.05 | *** join/#asterisk koltrast (7b2b7026@h77-53-57-114.cust.a3fiber.se) |
| 19:25.18 | *** join/#asterisk AndChat|19361 (~AndChat19@2600:100e:b030:a3bb:3953:eb85:b8df:c9d5) |
| 19:27.15 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 20:21.34 | Kobaz | jkroon: yup, ramdisk is the way to go |
| 20:21.49 | Kobaz | jkroon: oh, are you running into sqlite blocking issues? |
| 20:21.54 | Kobaz | jkroon: i have a patch for that |
| 20:22.14 | Kobaz | sqlite's single lock causes problems with high concurrency... well... even not-so-high concurrency |
| 20:22.43 | Kobaz | jkroon: what do you use gluster for? |
| 20:35.11 | *** join/#asterisk nix8n82 (~AndChat19@205-170-75-78.dia.static.qwest.net) |
| 20:59.35 | seanbright | Kobaz: have you posted that patch anywhere? |
| 21:12.27 | *** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea3:509f:3ecd:4bbe:e783) |
| 21:14.19 | Kobaz | nope |
| 21:14.23 | Kobaz | I can do that now |
| 21:14.25 | Kobaz | Sorry for holding out |
| 21:15.00 | Kobaz | I had hoped that it would have been adressed in newer releases, but I finally am working with 16 and such, and it's not there |
| 21:15.12 | Kobaz | So I only recently noticed it's still an issue |
| 21:15.56 | Kobaz | so, astdb/sqlite issues are resolved in two ways. One, put astdb on a ramdisk, and every minute, rsync it over to a backup in case of crash |
| 21:16.12 | Kobaz | and the other, is avoid a hard lock on waiting to write to astdb |
| 21:16.18 | Kobaz | since it's in a queue, it can always try again later |
| 21:20.34 | Kobaz | ...trying to find the code |
| 21:20.41 | grummund | Hi |
| 21:20.45 | seanbright | so to be clear - you have an asterisk patch for astdb? |
| 21:20.49 | Kobaz | yes |
| 21:20.51 | seanbright | ok |
| 21:21.13 | grummund | migrating from SIP to PJSIP and so far everything working except outbound calls ... |
| 21:22.02 | grummund | calls to the sip provider's test number are succesful, but other calls are torn down after connecting |
| 21:22.20 | Kobaz | ast_log(LOG_ERROR, "ast_db_put() COULD NOT LOCK. Abandon.\n"); |
| 21:22.28 | Kobaz | there you go, that's my fix |
| 21:22.34 | Kobaz | lemme generate the patch |
| 21:23.09 | Kobaz | basically what happens is... asterisk tries to update something in astdb, like say a sip peer/contact |
| 21:23.32 | Kobaz | it hits some latency waiting for the lock.. and then things go unreachable (especially chan_sip) because the lock is holding up a ton |
| 21:25.12 | Kobaz | https://dpaste.com/BDL8JLGD2 |
| 21:25.21 | Kobaz | been using it in production a reaaaly long time and it's worked wonderfully |
| 21:25.59 | seanbright | o |
| 21:26.01 | seanbright | oh* rather |
| 21:26.04 | seanbright | gotcha |
| 21:26.25 | Kobaz | on a system with moderate activity, something like 20-30 calls an hour, peak simul calls like 50, i see about... 100 of these COULD NOT LOCK errors |
| 21:26.46 | Kobaz | all those would be instances of... things grinding to a halt without the trylock/abort in there |
| 21:26.56 | seanbright | i see |
| 21:26.57 | seanbright | interesting |
| 21:28.24 | Kobaz | so i'll throw that up on the reviewboard |
| 21:28.27 | Kobaz | well gerrit now |
| 21:29.22 | Kobaz | if astdb is not on a ramdisk, i see a lot more of those |
| 21:29.29 | seanbright | no |
| 21:29.31 | seanbright | i mean |
| 21:29.33 | seanbright | don't do that |
| 21:29.44 | Kobaz | don't not put it on a ramdisk? |
| 21:29.52 | seanbright | don't put it on gerrit. |
| 21:29.53 | seanbright | heh |
| 21:29.56 | Kobaz | oh, why not |
| 21:29.58 | Kobaz | it's a good fix |
| 21:30.07 | seanbright | i do not agree with that assessment |
| 21:30.23 | seanbright | it may solve a problem for you, and that's great |
| 21:30.29 | seanbright | i do not think it is a good general purpose solution |
| 21:31.07 | Kobaz | general purpose solution is to... have a proper full write queue |
| 21:31.27 | seanbright | ure |
| 21:31.29 | seanbright | sure* |
| 21:31.45 | Kobaz | but this (in my case, and i'm sure in many others) is a good general fix to improve performance across the board with ast_db contention |
| 21:32.01 | seanbright | are you using astdb? |
| 21:32.07 | seanbright | or is this just asterisk using it? |
| 21:32.13 | Kobaz | mostly just asterisk using it |
| 21:32.25 | Kobaz | i store stupid stuff in astdb |
| 21:32.29 | Kobaz | that gets used once in a while |
| 21:32.47 | Kobaz | this is literally, an asterisk with 1000 sip peers updating its astdb registrations |
| 21:33.11 | seanbright | gotcha |
| 21:33.26 | Kobaz | and then chan_sip dropping out suddenly when it can't get a lock |
| 21:34.29 | Kobaz | and this actually seems to happen *more* on pjsip than on chan_sip |
| 21:34.37 | Kobaz | I get 10 times as many errors locking with pjsip |
| 21:34.44 | seanbright | k |
| 21:35.01 | Kobaz | and this is with astdb on a ramdisk |
| 21:35.05 | seanbright | k |
| 21:35.15 | seanbright | if you want to put it up for review, go for it |
| 21:35.19 | Kobaz | yeah |
| 21:35.36 | Kobaz | I think it's worth it, and, if it gets wildly rejected, it will start the conversation on the proper fix |
| 21:36.08 | file | the "proper fix" would likely be a queue as mentioned, and I wouldn't give a +1 to the patch myself, it's a work around |
| 21:36.36 | file | I can also say across large scale systems I've dealt with, and the FreePBX systems, and other things, astdb hasn't posed a problem for their usage patterns |
| 21:37.18 | file | not saying it's not a problem, just that it's seemingly not impacting a large quantity of people |
| 21:37.43 | Kobaz | I don't think it's something to easily pinpoint |
| 21:37.50 | Kobaz | It took me a few years to actually find this |
| 21:38.08 | Kobaz | I bet a lot of people would chalk it up to lag, or whatever |
| 21:38.13 | file | it's easy to pinpoint that stuff in PJSIP due to the way it is architected and the way the distributor works |
| 21:38.27 | file | if operations block you generally end up with incoming retransmissions |
| 21:38.33 | Kobaz | ah |
| 21:38.46 | file | which means, your thread handling that specific dialog or transaction is blocked |
| 21:39.00 | Kobaz | ah |
| 21:39.17 | file | the dispatch of SIP traffic is predictable, so retransmissions or messages within a dialog/transaction all go to the same thing |
| 21:39.43 | Kobaz | gottcha |
| 21:47.14 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 21:50.19 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 21:53.29 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 21:55.19 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 21:57.50 | seanbright | the astdb API was written when the underlying db was a key/value store |
| 21:58.05 | seanbright | now that it's sqlite3 there should probably be a newer API |
| 21:58.54 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 21:59.02 | seanbright | really depends on how much of an abstraction you want |
| 22:00.28 | *** join/#asterisk AndChat|19361 (~AndChat19@2600:100e:b030:a3bb:6975:8c11:edf9:177e) |
| 22:02.09 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:03.39 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:06.34 | *** join/#asterisk lwlvl (~lwlvl@62.54.177.118) |
| 22:07.03 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:10.13 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:13.18 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:16.13 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:19.18 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:22.44 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:26.06 | Samot | seanbright: Stop arguing. |
| 22:26.29 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:28.04 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:31.51 | seanbright | Samot: ugh, you're right |
| 22:31.54 | seanbright | my bad |
| 22:32.10 | Samot | Of course. I'm me. |
| 22:33.24 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:37.31 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:39.09 | *** join/#asterisk nix8n82 (~AndChat19@205-170-75-78.dia.static.qwest.net) |
| 22:40.41 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:43.45 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:46.54 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:48.14 | seanbright | aness: i'm going to need you to figure out your network connection problems |
| 22:48.19 | seanbright | lol |
| 22:49.46 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:54.26 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:56.41 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 22:59.51 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 23:03.06 | *** join/#asterisk aness (~aness@cm-84.209.131.103.getinternet.no) |
| 23:09.43 | *** join/#asterisk Posterdati (~posterdat@host-79-45-214-86.retail.telecomitalia.it) |
| 23:52.00 | grummund | debugging outbound calls with pjsip history |
| 23:57.42 | grummund | the account username isn't apparent in the INVITE, is that right? |
| 23:57.43 | *** join/#asterisk AndChat|19361 (~AndChat19@2600:100e:b030:a3bb:9557:b7d:2d0e:49eb) |
| 23:57.52 | Kobaz | huh? |
| 23:59.04 | grummund | according to pjsip history asterisk sends an INVITE to the sip trunk provider |
| 23:59.51 | Kobaz | okay, that's good |