| 00:22.50 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 00:40.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:03.12 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 01:12.51 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 02:00.41 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 02:16.10 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 02:53.06 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:43.26 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 04:32.59 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 04:32.59 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:34.31 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:26.51 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 07:46.01 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 07:46.01 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 08:23.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 08:56.33 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:49.41 | *** join/#asterisk-dev tzafrir (~tzafrir@81.218.177.19) |
| 09:49.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:09.56 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:09.56 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:11.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 10:54.29 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 10:54.29 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 10:55.39 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 11:06.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 11:23.43 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 11:24.11 | michael_work | i wonder when do i need to call ast_config_destroy function on cfg? |
| 11:24.53 | michael_work | do i always need to call it even if i did not use it or not |
| 11:25.13 | michael_work | as i see in reload queue rules in app_queue it's called at the end of that function |
| 11:26.39 | michael_work | but at some point it loads cfg when it's unchanged it does not and just return result |
| 11:27.01 | file | if you receive a valid cfg, then it should be destroyed |
| 11:28.01 | michael_work | what do you mean by valid? |
| 11:28.22 | michael_work | i see "cfg = ast_config_load("queuerules.conf", config_flags" |
| 11:28.33 | file | the return values of CONFIG_STATUS_FILEUNCHANGED and CONFIG_STATUS_FILEINVALID are not actual configuration structures |
| 11:28.39 | michael_work | and after "if (cfg == CONFIG_STATUS_FILEUNCHANGED)" it returns result |
| 11:28.56 | michael_work | thanks |
| 11:28.56 | file | they are special to indicate either that the file is unchanged or invalid, and can not be freed |
| 11:29.18 | michael_work | other question |
| 11:30.14 | michael_work | as i understand it was asked |
| 11:30.27 | michael_work | (according to google and log of chan) |
| 11:30.47 | michael_work | there is no way to use custom orderby setting right? |
| 11:30.59 | michael_work | for mysql query |
| 11:31.25 | file | that question isn't detailed enough - for what? if you mean realtime in channel drivers and such, then no |
| 11:31.34 | michael_work | for realtime |
| 11:31.45 | michael_work | as i thought |
| 11:32.01 | michael_work | but it does adds first parameter as order by |
| 11:32.32 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 11:33.38 | michael_work | so basiucally if i'll add ast_load_realtime_multientry("my_value_i_order_by >", "0", "real_where_value" real_where_value,SINTEL) |
| 11:34.07 | michael_work | as i understand it would actually order by first parameter |
| 11:34.23 | michael_work | the question is how ugly is that way? |
| 11:34.46 | file | I do not know. |
| 11:36.45 | michael_work | i'm trying to move queuerules to realtime |
| 11:36.54 | michael_work | and order is important there |
| 11:37.15 | michael_work | i would prefer not to sort after i get data but to order data in query |
| 11:58.55 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:22.43 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:43.23 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 12:43.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:22.02 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:25.10 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:29.53 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:37.01 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 14:08.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:08.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:09.36 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pqozvtkccohhltlc) |
| 14:13.14 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-dkchlhajegenjrwx) |
| 14:13.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:14.22 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:14.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:31.22 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ugphnjojstaysctb) |
| 14:31.22 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:32.42 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-zincuythndtmitim) |
| 14:36.37 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:38.33 | *** join/#asterisk-dev otherwis_ (~otherwise@172.56.10.97) |
| 14:57.07 | *** join/#asterisk-dev roderickm (~roderickm@cashmere.thecomplex.com) |
| 15:03.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:20.59 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:52.35 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-tpplprupdgxeoefe) |
| 16:27.12 | *** join/#asterisk-dev Tarv (nin@50.71.208.129) |
| 16:38.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 16:39.46 | Tarv | hey all |
| 16:40.27 | file | hi |
| 16:40.42 | jsmith | Greetings, Tarv |
| 16:41.19 | Tarv | anyone open to a question regarding res_fax.c? :D |
| 16:41.52 | jsmith | file loves fax.... and answering questions |
| 16:41.55 | jsmith | ducks and hides |
| 16:42.05 | file | I know not much of res_fax |
| 16:42.21 | leifmadsen | except all the important parts |
| 16:43.31 | Tarv | i do expect this to be considered not important |
| 16:43.33 | Tarv | that's for sure |
| 16:44.02 | Tarv | fax detection routine looks limited to codec ulaw/alaw, curious if including g726 as an option would work |
| 16:44.10 | Tarv | ducks and hides |
| 16:45.47 | file | while the fax detection operates in those that doesn't mean you can't translate from g726 to signed linear and feed it in, that's what a lot of stuff does |
| 16:45.54 | file | whether it would detect the tone... dunno! |
| 16:50.23 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:57.21 | Tarv | one day i should try it out, currenlty using g726 and forcing the fax to pickup |
| 16:58.11 | Tarv | i will fax myself a reminder |
| 17:09.06 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 17:15.41 | leifmadsen | heh |
| 17:18.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 17:29.53 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187.76.181.102) |
| 17:52.40 | jameswf | sruffell: can I pick your brain for a second in pm... |
| 17:52.56 | sruffell | sure. |
| 18:33.40 | *** part/#asterisk-dev rustlebee (~russellb@redhat/russellb) |
| 19:10.34 | *** join/#asterisk-dev fahmad (~fahmad@unaffiliated/fahmad) |
| 19:25.53 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:48.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 20:07.18 | file | putnopvut, I have a question |
| 20:07.47 | file | putnopvut, my get_pvt_uniqueid implementation for chan_pjsip is causing problems because the channel lock and potentially bridge lock are being held when the synchronous task is being queued up... |
| 20:08.17 | file | putnopvut, do you think it would be safe to access the dialog for the call id value outside of the serializer? |
| 20:08.22 | file | (with those locks held) |
| 20:15.20 | file | putnopvut, I'm thinking yes. |
| 20:19.25 | putnopvut | looks |
| 20:21.58 | putnopvut | I'm thinking about the risks. There's no risk of the Call-ID on the dialog changing, so you don't have to worry about that. |
| 20:22.34 | putnopvut | And if you have the channel reffed, there should be no worry about the ast_sip_session going away, and thereby no worry about the dialog going away either. |
| 20:22.46 | putnopvut | So by my estimation, it should be safe to do outside the serializer. |
| 20:22.53 | file | I came up with the same |
| 20:26.26 | file | great minds think of cheese! |
| 20:43.43 | mjordan | file: for the format stuff, I noticed that the implementation of the proposed format API is currently in format_ng.c |
| 20:44.06 | mjordan | file: are we just pointing things at format_ng.h for now? |
| 20:44.08 | file | not in reviewed |
| 20:44.12 | mjordan | and then eventually renaming them? |
| 20:44.34 | mjordan | ah. There is no format_ng.h |
| 20:44.48 | mjordan | So format.c hasn't yet been pulled over to the _ng way |
| 20:45.02 | file | it has |
| 20:45.31 | mjordan | but not all of the functions defined in format.h have been implemented... |
| 20:45.33 | mjordan | i.e., ast_format_interface_register |
| 20:46.04 | file | ...yes it has |
| 20:46.11 | mjordan | must be going crazy |
| 20:46.13 | file | it's __ast_format_interface_register |
| 20:46.16 | mjordan | what line number in format.c? |
| 20:46.21 | mjordan | yeah, that's what I searched for |
| 20:48.15 | file | errr what the heck my dear X environment |
| 20:48.46 | file | line 131? |
| 20:51.00 | mjordan | hm |
| 20:51.04 | mjordan | not on my check out |
| 20:51.09 | mjordan | that's ast_format_sdp_parse |
| 20:51.43 | file | are you looking at the group media_formats-reviewed? |
| 20:51.52 | mjordan | sighs |
| 20:51.54 | seanbright | my guess is no... |
| 20:52.01 | seanbright | what do i win? |
| 20:52.07 | mjordan | sadness |
| 20:52.19 | mjordan | what's the team/group/media_formats branch for then? |
| 20:54.05 | file | that was where began and continued until stuff was reviewed and the -reviewed branch was created, it still has some stuff that needs to be put through code review but anything new should be branched off -reviewed into a topic branch and then merged back in it |
| 20:54.15 | mjordan | heh |
| 20:54.41 | mjordan | I think I checked this out when there was no -reviewed branch |
| 20:54.50 | mjordan | so... nuts. That explains why things were a bit wonky. |
| 20:55.12 | file | yeah, due to the madness that is SVN getting the two in sync would be ... hellish |
| 20:56.49 | mjordan | huh. I thought we did chan_iax2. |
| 21:00.15 | file | laughs evilly |
| 21:34.02 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:34.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:49.57 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:958d:3fd8:746e:58c8) |
| 22:31.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:47.50 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-pqozvtkccohhltlc) |