| 00:13.49 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 00:13.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:38.46 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 01:19.38 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 01:47.28 | Agro | In the ast_dsp_process function in dsp.c, can anyone explain how the ast_dsp gets the features in its features field? |
| 01:51.07 | sruffell | Agro: are you just talking about the calls to ast_dsp_set_features()? Try # find ./ -name *.c | xargs grep -Hn ast_dsp_set_features |
| 01:51.34 | Agro | sruffell, things like this: if ((dsp->features & DSP_FEATURE_SILENCE_SUPPRESS) || (dsp->features & DSP_FEATURE_BUSY_DETECT)) { |
| 01:51.42 | Agro | if ((dsp->features & DSP_FEATURE_FAX_DETECT)) { |
| 01:52.00 | sruffell | yeah…they are set when the channels attach the dsp to the different channels. |
| 01:52.08 | sruffell | with the ast_set_features() call. |
| 01:52.13 | Agro | ok thanks! |
| 01:52.16 | sruffell | ast_dsp_set_features() I mean |
| 01:52.58 | sruffell | i.e. https://gist.github.com/2572996 |
| 01:53.38 | Agro | oh thanks! ill follow you >:) |
| 03:48.31 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:55.58 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 05:56.01 | schmidts | good morning |
| 05:56.10 | schmidts | good morning |
| 06:29.11 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:39.29 | *** join/#asterisk-dev youjelly (~bwahahaha@39.47.120.208) |
| 07:39.47 | youjelly | Hey, I needed to report an (issue) regarding chanspy and local channels |
| 07:40.17 | schmidts | youjelly http://issues.asterisk.org |
| 07:40.44 | youjelly | I'm not really sure if its a channel driver issue or a bug with chanspy |
| 07:40.55 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b52d:b288:200c:da01) |
| 07:41.00 | youjelly | can you help identify? |
| 07:45.08 | schmidts | youjelly tell me whats your problem exactly then we maybe can help you to find out which side causing this problem |
| 08:03.28 | *** join/#asterisk-dev youjelly (~bwahahaha@39.47.154.253) |
| 08:05.03 | youjelly | schmidts: ok wait, lemme paste my dial plan and logs |
| 08:07.13 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:07.14 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:18.55 | youjelly | schmidts: |
| 08:18.57 | youjelly | http://pastebin.com/XAJ4qdtB |
| 08:33.42 | schmidts | i dont understand what you are trying to do but give me a minute to read it |
| 08:34.41 | shamelessn00b | trying to execute a dialplan as two users converse |
| 08:34.51 | shamelessn00b | will handle DTMF using AMI |
| 08:35.18 | shamelessn00b | I've accomplished it using confbridge, but this seems to be a more optimal way and its not working |
| 08:37.29 | shamelessn00b | tell me if you need a call log |
| 08:38.08 | shamelessn00b | you'll need 2 SIP phones to test if you replace wait() in extension 1111 with dial |
| 08:38.25 | shamelessn00b | playback on the local channel will be audible then |
| 08:38.30 | shamelessn00b | to both parties on the call |
| 08:38.48 | shamelessn00b | which is absurd |
| 09:16.14 | youjelly | schmidts: any idea on what might be the cause? |
| 09:18.54 | *** join/#asterisk-dev youjelly (~bwahahaha@39.47.154.253) |
| 09:30.07 | *** join/#asterisk-dev skirmisha (~vk@46.237.90.31) |
| 09:30.14 | skirmisha | hi guys |
| 09:30.38 | skirmisha | can someone tell me what is need for asterisk ver 1.4 to detect t.38 fax msg |
| 09:30.59 | skirmisha | i got this error - chan_sip.c: Strange... The other side of the bridge don't have udptl struct |
| 09:31.22 | skirmisha | t=0 0 |
| 09:31.22 | skirmisha | m=image 5038 udptl t38 |
| 09:31.22 | skirmisha | a=T38FaxRateManagement:transferredTCF |
| 09:31.22 | skirmisha | a=T38FaxUdpEC:t38UDPRedundancy |
| 09:31.22 | skirmisha | a=sendrecv |
| 09:32.28 | skirmisha | fax is working, but i got 5 invites because of this and hence 5 separate faxes which are the same |
| 09:38.59 | skirmisha | any ideas |
| 09:39.45 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 10:21.34 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 10:31.18 | youjelly | why do people still use fax |
| 11:50.09 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.247.236.dsl.dyn.forthnet.gr) |
| 11:52.24 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:52.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:11.52 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 13:11.52 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 13:57.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:57.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:13.58 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-150-21.user.veloxzone.com.br) |
| 14:16.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:16.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:21.25 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 14:24.11 | *** join/#asterisk-dev Tim_Toady (~fuzzy@130.43.10.183.dsl.dyn.forthnet.gr) |
| 14:39.58 | Kobaz | anyone know offhand what ticket the sip replaces fd leak is |
| 14:40.22 | opticron | tries to find it |
| 14:40.41 | Kobaz | i've been poking around for like 20 minutes |
| 14:40.55 | Kobaz | now i'm just paging through all components/chan_sip tickets |
| 14:41.06 | Kobaz | all 979 of them |
| 14:41.10 | opticron | https://issues.asterisk.org/jira/browse/ASTERISK-19579 |
| 14:41.27 | Kobaz | oh yay |
| 14:41.31 | opticron | :) |
| 14:41.50 | Kobaz | how much memory is leaked per transfer? |
| 14:42.08 | opticron | whole sip PVT plus RTP structures |
| 14:42.08 | Kobaz | i have a customer where asterisk uses a gig of ram at the end of the day with no calls |
| 14:42.15 | Kobaz | oh okay, that might do it |
| 14:42.29 | opticron | it's really a reference leak |
| 14:42.35 | opticron | *was |
| 14:42.53 | opticron | and the patch on that issue isn't the final fix for it, but will do the job |
| 14:43.00 | Kobaz | k |
| 14:43.29 | opticron | I did a little optimization so that the freeing of the reference occurs much earlier |
| 14:43.32 | Kobaz | ah |
| 14:43.33 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:43.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:43.48 | Kobaz | i don't have any transfer unit tests working right now. i should fix it |
| 14:45.39 | Kobaz | i wish pjsua had perl bindings |
| 14:45.54 | russellb | just learn Python, it's <3 |
| 14:46.08 | Kobaz | heh |
| 14:54.26 | kpfleming | perl is not the bomb |
| 14:55.09 | opticron | except when it's a forkbomb |
| 14:55.18 | kpfleming | sporkbomb? |
| 14:55.26 | kpfleming | debates whether libc should have a spork() system call |
| 14:55.27 | opticron | or that |
| 14:55.45 | Marquis42 | kpfleming: unquestionably it should |
| 14:55.56 | mvanbaak | of course it should |
| 14:57.01 | *** join/#asterisk-dev Tim_Toady (~fuzzy@130.43.10.183.dsl.dyn.forthnet.gr) |
| 14:57.51 | russellb | what would it do? would it be like fork, but the process spoons the parent process somehow? |
| 14:58.03 | leifmadsen | big spoon or little spoon? |
| 14:58.26 | russellb | good question ... the new process would be the little spoon, i think. |
| 14:59.29 | mvanbaak | there is no spoon |
| 14:59.31 | russellb | perhaps the parent process would retain read-only access to its memory space or something |
| 15:00.00 | kpfleming | russellb: with copy-on-write! |
| 15:00.05 | Kobaz | moo |
| 15:00.15 | file | copy-on-read! |
| 15:00.39 | russellb | delete-on-read! |
| 15:00.51 | file | russellb, brilliant |
| 15:00.54 | mvanbaak | delete-on-write |
| 15:01.05 | russellb | write-on-read |
| 15:01.11 | russellb | to make sure what you read is still there |
| 15:01.15 | mvanbaak | whehehehe |
| 15:01.17 | kpfleming | we could use Write-Once-Read-None memory to implement that |
| 15:01.17 | leifmadsen | delete-on-awesome |
| 15:02.03 | mvanbaak | that is like using /dev/null as filestorage for a vps ;-) |
| 15:02.06 | Kobaz | read none? |
| 15:02.10 | Kobaz | heh |
| 15:03.12 | mvanbaak | <disk type='file' device='disk'> |
| 15:03.25 | mvanbaak | <source file='/dev/null'/> |
| 15:04.18 | kpfleming | Kobaz: http://www2.vmi.edu/Faculty/squirejc/Research/IC_Datasheets/digital_cmos/Write%20Only%20Memory.pdf |
| 15:07.39 | Kobaz | hah |
| 15:10.17 | kpfleming | it's pretty secure |
| 15:12.55 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:16.23 | Kobaz | yeah i would imagine |
| 15:20.00 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 15:20.00 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 16:22.33 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-150-21.user.veloxzone.com.br) |
| 16:28.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:28.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:49.13 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 19:15.21 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:15.21 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:09.17 | Kobaz | so i'm having a deadlock problem |
| 20:09.33 | Kobaz | i'm doing an ast_channel_iterator_all_new and then walking the iterator |
| 20:09.40 | Kobaz | i've locked a list before that |
| 20:09.58 | Kobaz | and in a fixup callback, i'm trying to lock the same list |
| 20:10.17 | Kobaz | so... is there a way to do deadlock avoidance while using an iterator |
| 20:10.37 | Kobaz | the iterator is waiting for a lock in ast_channel_get_full |
| 20:11.01 | russellb | convert your list to not be a list so you don't have to hold a lock on it the whole time like that? |
| 20:11.14 | Kobaz | hmm |
| 20:12.03 | Kobaz | so how would i make a list not a list |
| 20:12.19 | Kobaz | ao2's and stuff have their own locks as well |
| 20:13.06 | Kobaz | the real solution is getting rid of the iterator |
| 20:13.11 | Kobaz | because i put that in to avoid a crash |
| 20:13.18 | Kobaz | but my core problem isn't fixed |
| 20:14.48 | mjordan | Kobaz: what are you storing in the list? |
| 20:15.02 | Kobaz | pointers to channels |
| 20:15.44 | mjordan | Kobaz: why not use an ao2_container with a single bucket? |
| 20:15.51 | Kobaz | could |
| 20:15.54 | mjordan | or just an ao2_container for that matter |
| 20:15.57 | Kobaz | i never really dove into ao2 |
| 20:16.05 | Kobaz | that would solve the lock problems? |
| 20:16.19 | mjordan | not necessarily |
| 20:16.27 | Kobaz | that's what i thought |
| 20:16.40 | mjordan | why do you have it locked initially, and why do you need to relock it? |
| 20:16.50 | Kobaz | i only lock it once when i need it |
| 20:16.55 | Kobaz | and then unlock it as soon as possible |
| 20:17.07 | Kobaz | the issue is that i have a dialplan function that's doing a read |
| 20:17.22 | Kobaz | so it locks the list RD and then traverses |
| 20:17.28 | Kobaz | finds what it needs and then unlocks |
| 20:17.44 | Kobaz | the problem is.. there's a datastore fixup that locks the list WR |
| 20:17.57 | mjordan | this is a list you've populated? |
| 20:17.59 | Kobaz | now that's all fine and dancy |
| 20:18.01 | Kobaz | yeah |
| 20:18.17 | Kobaz | until i threw in a channel iterator to prevent a crash, into the dialplan function read |
| 20:18.33 | Kobaz | so the channel iterator is going, waiting for a lock on a channel |
| 20:18.38 | Kobaz | which happens to be inside the fixup |
| 20:18.40 | mjordan | hm. I'm thinking that a pastebin of some code would help, but with an ao2_container you could just use an ao2_find to get the channel you cared about |
| 20:19.03 | Kobaz | well, i'm doing a channel iterator to make sure i still have a good channel pointer |
| 20:19.04 | mjordan | I'm not sure why the fixup happens inside the context of the list being locked |
| 20:19.12 | mjordan | Kobaz: bump the ref count on the channel |
| 20:19.16 | Kobaz | yeah |
| 20:19.23 | Kobaz | then the channel will never hang up |
| 20:19.34 | Kobaz | since i have a ref to it |
| 20:19.37 | mjordan | and when you link the channels into an ao2_container, they will be ref'd up automatically to prevent that from happening |
| 20:19.41 | mjordan | so, dispose of the ref when you're done |
| 20:19.50 | Kobaz | i'm not done with it until the channel hangs up |
| 20:19.54 | opticron | is slightly confused by the parsing of outboundproxy in chan_sip.c |
| 20:20.14 | Kobaz | and the channel wont hang up unless i'm done with it if i keep a ref |
| 20:21.37 | Kobaz | www.kobaz.net/misc/func_tie.c |
| 20:22.27 | Kobaz | okay so |
| 20:22.36 | Kobaz | i have tie_function_read |
| 20:22.54 | Kobaz | there's a commented out AST_RWDLLIST_RDLOCK |
| 20:23.04 | Kobaz | that lock causes deadlocks, along with the newly added iterator |
| 20:23.05 | opticron | putnopvut, do you remember why there are two instances of the initial strtok in the outboundproxy parsing? both before and after sip_parse_host |
| 20:23.25 | mjordan | Kobaz: yeah. I'm thinking this won't be the right way of doing this. |
| 20:23.41 | Kobaz | yeah |
| 20:23.42 | opticron | (only asking because the change went in with the IPv6 stuff you did) |
| 20:23.49 | Kobaz | it's not |
| 20:23.56 | Kobaz | but it avoids the crash i was having |
| 20:23.59 | mjordan | what does the function do, once it ties to a channel? |
| 20:24.04 | Kobaz | from accessing a channel->name that was gone |
| 20:24.16 | Kobaz | basically it's a channel pointer |
| 20:24.19 | Kobaz | for use in dialplan |
| 20:24.23 | Kobaz | i can TIE(SIP/foo) |
| 20:24.37 | Kobaz | and SIP/foo can get masq'd to SIP/bar |
| 20:24.48 | Kobaz | and my tie will have the new channel name |
| 20:24.55 | Kobaz | like TIE(mychannel,SIP/foo-1234) |
| 20:24.57 | mjordan | Instead of holding references to channels, why not just hold the names, and only look them up when you need them? |
| 20:25.00 | Kobaz | and then ${TIE(mychannel)} |
| 20:25.08 | Kobaz | because the channel name can change |
| 20:25.16 | Kobaz | i need to point to exactly what it is |
| 20:25.50 | putnopvut | opticron: I don't recall. Let me have a look. |
| 20:25.55 | Kobaz | but anyway |
| 20:26.14 | Kobaz | the real fix to all this, is i need to find out why my fixup/duplicate stuff isn't tracking certain channels |
| 20:26.23 | Kobaz | then i wouldn't be left with a dangling channel pointer in the first place |
| 20:26.43 | putnopvut | has to look up how strtok works again. |
| 20:27.05 | opticron | yeah, it's a weird one |
| 20:27.20 | opticron | first invocation has the pointer, rest take null |
| 20:27.36 | opticron | has internal static weirdness |
| 20:27.40 | Qwell | eww |
| 20:27.45 | Qwell | that means it's not thread-safe |
| 20:27.50 | opticron | correct |
| 20:27.52 | russellb | strtok_r |
| 20:27.54 | putnopvut | Yep, you're supposed to use strtok_r |
| 20:28.06 | Qwell | are we using _r? |
| 20:28.06 | russellb | or strsep! |
| 20:28.13 | opticron | Qwell, we aren't |
| 20:28.14 | putnopvut | Qwell: not in this case. |
| 20:28.17 | Qwell | suck |
| 20:28.30 | seanbright | strtok <3 |
| 20:28.37 | russellb | strsep 4 life |
| 20:28.38 | opticron | I may end up rewriting that section of code as part of this coverity clean up stuff |
| 20:28.50 | putnopvut | Okay, so I think I know what's up there. |
| 20:28.57 | putnopvut | So we call strtok once to get what's before the comma. |
| 20:29.18 | putnopvut | Then my guess is that sip_parse_host() does further breaking up of that. |
| 20:29.39 | opticron | with strtok? more grossness |
| 20:29.42 | opticron | looks |
| 20:29.44 | Kobaz | mjordan: is there a nice way to traverse the main channel list without locking |
| 20:30.09 | russellb | without locking at all? no. |
| 20:30.51 | putnopvut | opticron: then I'm guessing hte second strtok is to once again grab the value before the comma, but have it whole again. |
| 20:31.01 | putnopvut | It could stand to be done better. |
| 20:33.07 | opticron | I'm going to have to do some testing with it |
| 20:34.37 | mjordan | Kobaz: not that I'm aware of |
| 20:35.39 | Kobaz | mm |
| 20:35.40 | Kobaz | k |
| 20:36.02 | mjordan | Kobaz: you probably should look into how ao2 iterators work |
| 20:36.37 | Kobaz | yeah |
| 20:36.43 | Kobaz | i would like to convert my stuff to ao2 at some point |
| 20:36.51 | mjordan | the channel_iterator_search is going to give you back all of the channels that matched in a thread safe manner |
| 20:37.13 | mjordan | so there shouldn't be any need to lock something else during that period of time. The channels have all been ref bumped, so they shouldn't go away |
| 20:37.53 | Kobaz | but how do i handle the problem where channels stick around forever |
| 20:38.21 | mjordan | if they're sticking around forever, its because something up'd the ref count and didn't deref it when it was done with the channel |
| 20:38.29 | Kobaz | yeah |
| 20:38.32 | Kobaz | that's the thing |
| 20:38.35 | mjordan | if you're never done with the channel, then you've run into something that I'm not sure how to handle. |
| 20:38.43 | Kobaz | i'm not going to be done with the channel until the channel hangs up |
| 20:38.49 | mjordan | one thing you could do is find a way to have a function register for notification that a hangup has been requested on a channel |
| 20:38.53 | mjordan | and deref when that happens |
| 20:38.53 | Kobaz | which is why i don't ref it, because it causes problems |
| 20:38.54 | Kobaz | yeah |
| 20:38.56 | Kobaz | i was thinking about that |
| 20:39.14 | Kobaz | i was going to do that anyway, have a hangup callback |
| 20:39.35 | mjordan | Kobaz: the event framework would help there as well, potentially |
| 20:39.55 | mjordan | then you could have multiple recipients of the hangup notification. |
| 20:40.07 | mjordan | each deref when they receive it, and the channel should be destructed appropriately |
| 20:41.33 | Kobaz | yeah |
| 20:55.45 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 20:58.49 | tzafrir_laptop | I'm packaging ilbc for Debian. Is there any place where it is actually stated that the RFC3951 code is under the BSD license? |
| 20:59.02 | tzafrir_laptop | (or whatever license stated by Google) |
| 21:00.03 | kpfleming | tzafrir_laptop: that is documented in the IETF's TLP |
| 21:12.20 | tzafrir_laptop | kpfleming, sorry, but I don't follow. Does recent policy apply to RFC 3951 of Dec. 2004? |
| 21:12.39 | kpfleming | that's an IETF question, not an Asterisk question |
| 21:12.40 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 21:22.29 | tzafrir_laptop | Asterisk includes that code as well |
| 21:26.28 | tzafrir_laptop | oh well |
| 21:44.14 | kpfleming | tzafrir_laptop: it's in Asterisk because at the time that Google made their licensing statements i was satisfied that it was safe to include it in Asterisk, as was our in-house counsel. none of those opinions apply to Debian, though, and I can't remember off the top of my head exactly which documents i looked at to reach my conclusions. |
| 21:53.09 | kpfleming | putnopvut: that voicemail message id thing means that users using ODBC voicemail will have to change their db schema before upgrading... that will be fun :-) |
| 21:53.32 | kpfleming | unless you want to try to do some 'adaptive' stuff like cdr_adaptive_odbc does |
| 21:55.49 | russellb | would be cool to version database schemas and have a migration utility that does it for you. |
| 21:55.56 | russellb | i'm surprised nobody has done that to asterisk yet ... |
| 21:56.43 | russellb | i'd like that more than adding columns willy-nilly on the fly like the adaptive stuff does |
| 21:56.49 | kpfleming | mutters something about patches |
| 21:57.03 | russellb | sorry, didn't mean to discuss an idea |
| 21:57.06 | kpfleming | lol |
| 22:00.34 | seanbright | russellb: let that be a lesson to you |
| 22:00.45 | russellb | iknowright |
| 22:11.58 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 22:11.58 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 22:18.58 | russellb | otherwiseguy: psst |
| 22:24.04 | otherwiseguy | russellb: OMGHI |
| 22:24.15 | kpfleming | breaks the world |
| 22:30.00 | pabelanger | russellb, could be added to debian packaging pretty easy |
| 22:33.50 | russellb | insert rpm vs deb trolling here |
| 22:34.44 | tzafrir_laptop | Debian actually has a complex framework for packaging database packages, |
| 22:35.12 | tzafrir_laptop | should allow you to plug in such things. But quite complex, and I never really properly used it |
| 22:35.15 | pabelanger | russellb, openstack already does a good job with database upgrades. Not included in RPMs? |
| 22:35.56 | pabelanger | tzafrir_laptop, ya, learning dbconfig-common has helped |
| 22:36.49 | pabelanger | however, I don't do much asterisk and realtime |
| 22:37.52 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mrnyxvqeokyskswf) |
| 23:08.17 | Kobaz | https://issues.asterisk.org/jira/browse/ASTERISK-19815 |
| 23:08.23 | Kobaz | should there be a target release set? |
| 23:21.49 | pabelanger | Kobaz, Ideally yes, however it is a manual process. It would be cool to have a bot update it when we do releases |
| 23:24.49 | Kobaz | k |