| 01:01.59 | *** join/#asterisk-dev roderickm (~roderickm@user-24-96-125-184.knology.net) |
| 01:21.59 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:42.48 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 02:29.42 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 03:47.26 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-wliaonepmydahniw) |
| 04:35.31 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip24-251-34-116.ph.ph.cox.net) |
| 06:25.47 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 06:25.47 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:50.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.242) |
| 07:11.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.242) |
| 07:14.56 | *** join/#asterisk-dev reconwireless (uid10170@gateway/web/irccloud.com/x-ozbwvbklgvfqfqgt) |
| 07:25.25 | coreyf1513 | wdoekes: ping |
| 07:25.53 | wdoekes | pong |
| 07:26.35 | coreyf1513 | hello! I just posted https://issues.asterisk.org/jira/browse/ASTERISK-23382 issue with 1.8 Makefile :) |
| 07:26.48 | wdoekes | lame! |
| 07:26.53 | wdoekes | let me check that |
| 07:27.48 | wdoekes | why is it an issue with 1.8 only? |
| 07:28.38 | coreyf1513 | include menuselect.makeopts |
| 07:28.55 | wdoekes | ah |
| 07:29.53 | coreyf1513 | causes all the stuff to be generated by submake's, and those submakes are given "-qp" as part of the MAKEFLAGS hidden variable |
| 07:30.37 | coreyf1513 | I found it because I'm working on a chan_sip bug, half the time when I made a change I would do make, then make ins<tab>. when I hit tab to complete "install" bash completion would run make -qp :) |
| 07:32.04 | coreyf1513 | anyways I'm not sure if my patch is good or if you'd rather just revert the Makefile change from 1.8 |
| 07:33.13 | wdoekes | at first glance, the patch looks okay. but like you say, I'm not sure we want to go down this road. (possibly with unexpected new behaviour from this patch.) |
| 07:33.31 | wdoekes | reverting or backporting the fix from 11 sounds like a better plan |
| 07:33.37 | wdoekes | with reverting as the safest best |
| 07:34.36 | coreyf1513 | cool if I assign that ticket to you? |
| 07:34.44 | wdoekes | sure |
| 07:34.52 | wdoekes | I'll poke matt for a final verdict |
| 07:39.29 | coreyf1513 | so I wanted to ask, what are your feelings on a slow refactor/cleanup of chan_sip? |
| 07:46.15 | coreyf1513 | wdoekes: ^ |
| 07:47.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.242) |
| 07:48.01 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:02.47 | wdoekes | coreyf1513: cleanup is good, but only if it serves a purpose: i.e. you're working toward some feature/bug-fix which we really want into chan_sip. if it's just cleanup, I'd go with paul and suggest to put the energy into making pjsip feature-full |
| 08:19.54 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 08:22.15 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:cb9:f154:22d4:c0ff) |
| 08:29.06 | coreyf1513 | wdoekes: honestly my first goal is to just the module workable. my hope is to find/fix bugs as I go, back-port the fixes to 1.8/11. in any case I've put it on hold for now, I want to make sure I don't create conflicts when file merges meda_formats from 12 to trunk. |
| 08:37.07 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.172) |
| 08:39.11 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:20.27 | *** join/#asterisk-dev snuff-work (~snuffy@120.154.197.125) |
| 09:20.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:44.56 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:44.56 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:04.37 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:04.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:15.49 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:34.29 | *** join/#asterisk-dev otherwiseguy (~otherwise@c-76-19-134-77.hsd1.ma.comcast.net) |
| 11:17.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.67.31.130) |
| 11:59.04 | *** join/#asterisk-dev oej (~Adium@h-79-136-100-43.na.cust.bahnhof.se) |
| 11:59.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:06.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.67.31.130) |
| 13:00.15 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:02.59 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:06.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.67.31.130) |
| 13:12.53 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 13:38.09 | *** join/#asterisk-dev reconwireless (uid10170@gateway/web/irccloud.com/x-fmymgmuwptoaawdu) |
| 13:46.34 | *** join/#asterisk-dev oej (~Adium@2001:9b0:107:400:21cb:3e62:e63c:df17) |
| 13:46.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:52.25 | *** join/#asterisk-dev oej (~Adium@2001:9b0:107:400:21cb:3e62:e63c:df17) |
| 13:52.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:53.52 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:53.52 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:08.37 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:21.18 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 14:23.39 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 14:29.01 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mulwqzbmwudxsgda) |
| 14:49.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-bybfxrndfrgwzwmo) |
| 14:51.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:51.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:14.50 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:15.04 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 15:17.57 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-puccqpdukhrsfftu) |
| 15:23.03 | gtjoseph | got a pjsip-contact / sorcery question, probably for file: |
| 15:23.13 | file | ask and you shall maybe have an answer |
| 15:24.09 | gtjoseph | :) why are dynamic contacts pushed to the sorcery instance with an aor/uri id but permanent contacts are stored in an aor specific container with a uuid for the id? |
| 15:25.01 | file | because permanent contacts are pulled from the aor configuration |
| 15:25.24 | file | and dynamic contacts are manipulated outside of aors, but associated with them |
| 15:26.51 | gtjoseph | any reason permanent contacts need a UUID for their ids? |
| 15:27.20 | file | no, but they are sorcery objects and ids for sorcery objects are supposed to be unique |
| 15:27.42 | gtjoseph | there can't really be a collision if the name is constructed as the dynamic ones are. |
| 15:28.08 | file | sure, but using a uuid there didn't require any extra effort |
| 15:28.12 | file | thus why it was done that way |
| 15:28.49 | gtjoseph | given that permanent ones are only created at load time, any objection if I change it to match dynamic ones? |
| 15:29.16 | file | no... but I have to ask why |
| 15:29.45 | gtjoseph | makes it easier for the cli to handle contacts all the same way |
| 15:29.58 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:30.01 | file | what do you mean? |
| 15:30.10 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.240) |
| 15:31.05 | gtjoseph | except for contact, all the sorcery object have reasonable and recognizable ids so they list, show, and especially tab-complete all using the same code. |
| 15:31.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.240) |
| 15:31.30 | file | ah |
| 15:31.33 | gtjoseph | for contact I have to use custom code to make the id recognizable |
| 15:33.20 | gtjoseph | for channel, i had to create a small wrapper sorcery object but it wasn't a sorcery object to begin with so i didn't feel too bad. |
| 15:33.53 | gtjoseph | for contact it's be a shame to have to write something custom when they're already sorcery objects |
| 15:34.44 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@77.41.82.191) |
| 15:36.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 15:37.36 | file | I'm not even sure I'd expose the ids really - but just expose the AOR and contact URI itself |
| 15:37.47 | file | use that to get the respective contact |
| 15:39.08 | gtjoseph | and that's what I do now but it's special code for contact |
| 15:39.17 | gtjoseph | maybe I can genericize it |
| 15:39.43 | file | you can only genericize so much without compromising the experience or overcomplicating the implementation |
| 15:39.54 | gtjoseph | exactly |
| 15:40.12 | gtjoseph | there's always a balance |
| 15:40.42 | gtjoseph | would you object to adding the parent aor's id as a specific field in the contact structure? |
| 15:41.00 | file | depends on why |
| 15:41.18 | file | we can only add so much to that because we kill astdb |
| 15:41.22 | file | erm before |
| 15:42.10 | gtjoseph | right now dynamic contacts are have their id set as "aor;@uri" so that they can be looked up via a regex later. |
| 15:42.19 | gtjoseph | by aor id. |
| 15:42.28 | file | yup |
| 15:42.40 | gtjoseph | if aor_id were a field we could eliminate the regex match |
| 15:42.58 | file | no |
| 15:43.03 | file | I mean, we could |
| 15:43.06 | file | but that would be bad |
| 15:43.18 | file | using a regex means we only pull in the respective contacts |
| 15:43.36 | file | doing a field match means we have to pull in ALL contacts and do the comparison (at least for astdb, depends on wizard) |
| 15:43.48 | gtjoseph | ah, gotcha |
| 15:44.02 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 15:44.34 | file | further down the road we may be able to optimize that but sadly it's limited by the underlying implementations |
| 15:45.26 | file | that's why I mentioned doing it based off of aor and contact |
| 15:45.29 | file | that gives you all you need |
| 15:46.06 | Kobaz | mm |
| 15:46.11 | gtjoseph | true but aor_id isn't stored on the contact properly |
| 15:46.30 | gtjoseph | right now i put it in an extended field |
| 15:46.35 | file | gtjoseph, do you need that though? |
| 15:46.58 | file | you can use what the registrar does to find the AOR, and contact(s) |
| 15:47.41 | gtjoseph | yeah because when you use a callback on a container of contacts the callback doesn't know what aor is in context |
| 15:48.52 | file | if you grab all contacts sure, but if you grab AORs and then contacts on each you would |
| 15:50.46 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 15:51.24 | file | throws a bomb into things |
| 15:52.04 | gtjoseph | how? if you do an ao2_callback on the contact container the callback can only get 1 argument and it's usually needed for something else |
| 15:52.25 | file | you can pass in a struct with multiple fields, that's what tons of stuff does if you need to pass more than one thing |
| 15:52.41 | gtjoseph | yeah, i was trying to avoid that |
| 15:53.28 | gtjoseph | in fact, i put that in the code a few months ago and backed it out |
| 15:53.33 | coreyf1513 | hello, I have a question about a commit I'm about to do for r3261. changes to res_fax.conf are for all branches+trunk, changes to res_fax.c are being blocked from trunk. is it preferred to commit the changes to each file separate and block12trunk for res_fax.c, or commit together and revert res_fax.c changes from trunk before commit? or should I do a single commit/merge for 1.8/11/12, block from trunk and do a new commi |
| 15:53.33 | coreyf1513 | t for trunk only? |
| 15:54.27 | file | coreyf1513, I'd commit to all and revert res_fax.c changes from trunk |
| 15:56.54 | coreyf1513 | file: ok.. so for the commit msg to trunk, should I modify the commit.msg? half the changes mentioned in the commit.msg are being omitted from trunk.. |
| 15:57.13 | file | coreyf1513, that's what I would do |
| 15:58.01 | coreyf1513 | file: thanks for the advice. |
| 16:08.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.190) |
| 16:09.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 16:11.41 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:33.36 | file | leedm777, there's *3* different ways? |
| 16:33.59 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-bijzqbopvhgvadqo) |
| 16:34.00 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:54.08 | mjordan | jrose_atDigium: for r3256, what you have up there right now fixes the issue with the reflexive candidates |
| 16:54.21 | mjordan | jrose_atDigium: does it fix the initial one-way audio issue on ASTERISK-23213? |
| 16:54.26 | jrose_atDigium | Yes |
| 16:55.20 | jrose_atDigium | The reason the issue was occurring was because the check list creation function would return an error while pruning the check list (because the base SRFLX address wouldn't match anything) and we would blow out the remote candidate list in response. |
| 16:55.48 | jrose_atDigium | With the patch in place, the check list function completes successfully and ICE gets started. |
| 16:56.04 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-mfeiedxthdhaopoh) |
| 16:56.37 | mjordan | so, when a re-INVITE happens that includes an SDP that has the same candidates, we'll currently just ignore it as the session is already started |
| 16:56.43 | jrose_atDigium | Yes |
| 16:56.50 | mjordan | the only issue now that would occur is if the candidates change |
| 16:56.51 | wdoekes | mjordan: ASTERISK-23382 - the embed_modules dependency stuff breaks 'make -qp' (which is run on tab completion apparently) on the 1.8 makefile. revert the whole -include menuselect.makeopts ("we want the MENUSELECT_EMBED var") in 1.8? or implement the asterisk-11-and-up approach (grep ^MENUSELECT_EMBED=$$)? |
| 16:57.05 | jrose_atDigium | I have a patch in progress that does the following: |
| 16:57.20 | jrose_atDigium | when a new candidate is added after an ICE session is already started, it throws that candidate into a new list |
| 16:57.30 | wdoekes | (+0 on simply reverting) |
| 16:57.47 | jrose_atDigium | We keep throwing new candidates into that list until a new call to start the ICE session is started. |
| 16:57.57 | jrose_atDigium | Then instead of backing out if ICE is already started... |
| 16:58.12 | mjordan | wdoekes: what was the reason for not using the asterisk 11 approach initially? |
| 16:58.16 | jrose_atDigium | we check to see if the new remote candidate list matches the existing remote candidate list. If it is, we toss the new candidate list and back out. |
| 16:58.28 | mjordan | hm. |
| 16:58.42 | jrose_atDigium | If it isn't, we toss the old candidate list, replace it with the new candidate list, then break down the ICE session and try to start a new one. |
| 16:58.58 | jrose_atDigium | Unfortunately that's where we get to the whole one way audio issue. |
| 16:59.01 | mjordan | jrose_atDigium: k, that sounds about right. You would only want to stop/restart if the candidates were different. |
| 16:59.10 | mjordan | jrose_atDigium: for now, make a new issue with that problem |
| 16:59.14 | mjordan | link it to the existing one |
| 16:59.20 | jrose_atDigium | There is already an issue for that actually. |
| 16:59.26 | mjordan | jrose_atDigium: which one is that? |
| 16:59.40 | jrose_atDigium | It's the one kharwell's patch was intended to resolve in the ifrst place. ASTERISK-22911 |
| 17:00.19 | jrose_atDigium | I re-opened it a little while back. |
| 17:00.32 | jrose_atDigium | Since the reporter said that his issue was never actually fixed in the first place. |
| 17:00.50 | file | so we're back to where we were instead of where we weren't |
| 17:01.02 | jrose_atDigium | No, that's not true. |
| 17:01.08 | file | which is better than where we went |
| 17:01.20 | jrose_atDigium | We are better off now than we were by quite a bit. |
| 17:01.32 | jrose_atDigium | Because previously, Asterisk would just crash when holding. |
| 17:01.41 | jrose_atDigium | One way audio beats a crash IMO. |
| 17:01.50 | file | aye |
| 17:02.23 | jrose_atDigium | Also now we are actually appropriately starting the ICE sessions when starting the call and who knows what kind of effects that might have. |
| 17:02.41 | jrose_atDigium | Before we were operating in some kind of half-started mode. |
| 17:13.23 | wdoekes | mjordan: using grep seemed less elegant than loading up the variable through the include-directive. |
| 17:16.06 | pabelanger | dear app_queue, why is your logging functions is logger.c. Thank you |
| 17:18.35 | jsmith | pabelanger: Because it's a logger! |
| 17:18.37 | jsmith | ducks and hides |
| 17:20.03 | mjordan | wdoekes: I can live with clunky |
| 17:21.34 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 17:21.35 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 17:22.07 | pabelanger | jsmith, indeed |
| 17:23.20 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-juufhkfemesgvrrh) |
| 17:33.13 | *** join/#asterisk-dev oej (~Adium@213.132.102.114) |
| 17:33.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:42.14 | jrose_atDigium | file: http://pastebin.com/raw.php?i=hAFs6g25 -- here's a dump of the PJ log set to level 4 to supress the larger STUN message descriptions. I'm noticing a couple things that go against my expectations. Notably that we are seeing invalid argument errors when sending STUN messages from the worker thread once per session. |
| 17:42.46 | jrose_atDigium | Also the initial has two checks that seem to pass while the renegotiated check list that occurs on unhold only has one successful check. |
| 17:44.42 | jrose_atDigium | For some reason it's indicating check 0 and check 6 for the first part even though the check list only has entries 0-5 when it's built as well. It's calling Check 6 a 'triggered check'. |
| 17:49.05 | file | interestin' |
| 17:49.25 | file | it's sending to port 0 which is ungood |
| 17:50.51 | file | that's what is causing the invalid argument |
| 17:52.49 | file | jrose_atDigium, candidate list is different because you aren't adding RTCP as well as RTP |
| 17:52.52 | file | when restarting |
| 17:53.20 | jrose_atDigium | Ah |
| 17:54.23 | file | that may be why the ICE negotiation is stalling |
| 17:54.46 | file | the port 0 is... odd... though |
| 17:55.01 | jrose_atDigium | Apparently it's happening in the initial invite to though (the port 0 thing) |
| 17:55.16 | file | yeah |
| 17:55.39 | file | it ultimately finds a usable candidate, it's just strange that one is port 0 but that's for another day |
| 17:57.56 | mjordan | there's a bug for the RTCP part as well |
| 18:04.31 | jrose_atDigium | file: It works! |
| 18:04.43 | file | two-way audio? |
| 18:04.44 | mjordan | yay |
| 18:04.45 | jrose_atDigium | Yep |
| 18:04.59 | file | cool |
| 18:05.20 | jrose_atDigium | Now I'll clean up this patch and post it to ASTERISK-22911 |
| 18:05.50 | jrose_atDigium | I'm not 100% sure I'm putting the RTCP stuff back in appropriately, but I'll leave that for the review. |
| 18:06.11 | jmls | wdoekes: pig |
| 18:06.14 | jmls | heh |
| 18:06.18 | jmls | so sorry |
| 18:06.19 | jmls | ;) |
| 18:06.28 | jmls | wdoekes: ping |
| 18:14.49 | file | erm |
| 18:21.54 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-yvpgzblpxrtzowhq) |
| 18:22.57 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-yppzsaprtkrhgyzm) |
| 18:39.50 | *** join/#asterisk-dev maruen (~maruen@179.99.252.27) |
| 18:41.47 | maruen | Hi All, Does anyone here already had installed asterisk and compiled it from source and get it working on Mac OS X Mavericks? |
| 18:42.12 | maruen | I get an error while I try to install it |
| 18:42.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 18:42.44 | maruen | error: invalid value '6' in '-06' related to astacanary.o |
| 18:42.53 | maruen | anybody knows about this issue? |
| 18:45.45 | jsmith | Which compiler are you using, out of curiosity? |
| 18:45.56 | jsmith | hasn't compiled Asterisk on a Mac in about six or seven years |
| 18:47.55 | maruen | how can I see that, jut executing ./configure it shows this information? |
| 18:48.10 | opticron | jsmith, the ML post says clang |
| 18:48.24 | jsmith | LLVM |
| 18:48.27 | jsmith | *le sigh* |
| 18:49.02 | jsmith | maruen: Output of "which gcc" and "gcc -v"? |
| 18:49.11 | maruen | ok, just a second |
| 18:50.21 | maruen | Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) |
| 18:50.38 | mjordan | yeah... |
| 18:50.39 | maruen | target: x86_64-apple-darwin13.0.0 |
| 18:50.49 | mjordan | clang won't be able to compile Asterisk |
| 18:51.08 | maruen | I need to install other gcc compiler then? |
| 18:51.25 | jsmith | Likely, yes |
| 18:51.28 | mjordan | https://github.com/leedm777/homebrew-asterisk |
| 18:51.40 | mjordan | I'd highly recommend taking a look at what leedm777 set up :-) |
| 18:52.03 | maruen | ok, it seems more easier, as it uses brew |
| 18:52.17 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 18:53.30 | mjordan | jrose_atDigium: I'd go ahead and commit the fix for r3256, but leave the issue open so others can test |
| 18:53.37 | mjordan | r = review board :-) |
| 18:53.54 | jrose_atDigium | Go for it. |
| 18:54.14 | jrose_atDigium | I'm going to keep poking around with the hold/unhold business for now. |
| 18:54.31 | file | is it still happy? |
| 18:54.44 | jrose_atDigium | Well, yes. |
| 18:54.54 | jrose_atDigium | The scenario I've been testing has been behaving splendidly. |
| 18:55.16 | jrose_atDigium | There is still the matter of the one that I've never really been able to get to work as well... which is when I call the SIPML client instead of being called by the SIPML client. |
| 18:55.24 | jrose_atDigium | I have a feeling this is pinned on our CONTROLLED/CONTROLLING business. |
| 18:55.29 | file | probably |
| 18:56.00 | jrose_atDigium | It's not a part of any of the issues I've been targeting though, so I'm not sure if I should be pursuing it... |
| 18:56.15 | file | I wouldn't, there's already another issue tracking that |
| 18:56.19 | jrose_atDigium | Right |
| 18:56.40 | jrose_atDigium | Ok then, I'll strip that part out of my patch, retest, and if it's still working I'll go ahead and post that for review as well. |
| 19:02.51 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@77.41.82.191) |
| 19:04.44 | maruen | maruen@Mehanas-Mac/usr/local/Cellar/asterisk/12.0.0/sbin$ sudo ./asterisk -r |
| 19:04.44 | maruen | Password: |
| 19:04.44 | maruen | Unable to connect to remote asterisk (does /usr/local/Cellar/asterisk/12.0.0/var/run/asterisk/asterisk.ctl exist?) |
| 19:05.01 | maruen | After instaling I get this message |
| 19:05.24 | mjordan | does /var/run/asterisk/asterisk.ctl exist? :-D |
| 19:05.27 | maruen | I see that this folder exists, but the file dont |
| 19:05.32 | file | is Asterisk running? |
| 19:05.43 | mjordan | well, not /var/run |
| 19:05.44 | mjordan | :-P |
| 19:06.00 | mjordan | maruen: if you're using Asterisk for the first time, you might get some additional help in #asterisk |
| 19:06.19 | maruen | I tried, but anybody replied me |
| 19:06.23 | maruen | so I tried this list |
| 19:06.28 | maruen | sorry :) |
| 19:07.03 | mjordan | no worries. Most of us are in both channels, but #asterisk-dev usually ends up being mostly about the actual development of Asterisk. You'll probably get more replies in #asterisk for the vast majority of usage related questions |
| 19:07.26 | mjordan | if you're working with it for the first time - now that you've got it installed - you should probably check out the definitive guide |
| 19:07.27 | maruen | understood! |
| 19:07.35 | maruen | right! |
| 19:07.42 | mjordan | (01:07:33 PM) infobot: Asterisk: The Definitive Guide, 4th Edition (ISBN 1-4493-3242-0) available at http://oreilly.com/catalog/0636920025894 - Asterisk: The Definitive Guide is released under a Creative Commons License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/) and a version is available for reading online at http://www.asteriskdocs.org/ or see ~buybook |
| 19:08.17 | maruen | will take a look |
| 19:08.35 | mjordan | jrose_atDigium: so, what are the patches that need to be committed? If you can get them in, I can cut an rc2 today |
| 19:08.39 | maruen | I already installed it on ubuntu linux and Im using it there |
| 19:08.48 | jrose_atDigium | mjordan: Well, that depends... |
| 19:08.55 | jrose_atDigium | Do we want the hold behavior fixed in rc2? |
| 19:09.20 | jrose_atDigium | If so, I need to post that patch, but it's currently building off of the other patch. |
| 19:09.27 | mjordan | jrose_atDigium: let's fix the regression first, and get that committed |
| 19:09.37 | jrose_atDigium | ok, in that case the one on the review we've been working on is it. |
| 19:09.49 | mjordan | yeah, that one first |
| 19:09.52 | file | I gave it a ship it, but I sorta wrote it :P |
| 19:09.57 | jrose_atDigium | Yep |
| 19:10.21 | jrose_atDigium | If you'd prefer to commit that patch, that's cool. If not, I can go ahead and do that. |
| 19:10.44 | *** join/#asterisk-dev oej (~Adium@213.132.102.114) |
| 19:10.53 | file | go for it, this is your shindig |
| 19:10.57 | jrose_atDigium | righto |
| 19:12.36 | *** join/#asterisk-dev oej (~Adium@213.132.102.114) |
| 19:12.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:20.30 | jrose_atDigium | mjordan: Committed the patch to 11 |
| 19:28.21 | file | erm |
| 19:28.57 | file | jrose_atDigium, move the pj_str_t mapped up |
| 19:29.33 | file | (you broke the build) |
| 19:32.08 | jmls | hmm |
| 19:32.09 | jmls | <PROTECTED> |
| 19:32.15 | jmls | works fine |
| 19:32.24 | jmls | module unload extconfig |
| 19:32.31 | jmls | [Feb 27 19:31:32] WARNING[10781]: loader.c:631 ast_unload_resource: Unload failed, 'extconfig' could not be found |
| 19:32.57 | file | you can't unload it, it's a core component |
| 19:33.22 | file | the mapping for module reload is provided so there is a common mechanism for reloading things |
| 19:34.08 | jmls | should it not say "Unload failed, 'extconfig' is a core module and cannot be unloaded" |
| 19:34.10 | jmls | :) |
| 19:34.23 | file | it could |
| 19:35.20 | jmls | ok, thanks. just checking. |
| 19:35.38 | jmls | hates seeing " WARNING[10781]" ... |
| 19:35.51 | jmls | big red nasty letters |
| 19:36.48 | file | jrose_atDigium, bananas |
| 19:36.57 | jrose_atDigium | what bananas? |
| 19:37.00 | jrose_atDigium | I'm fixing it. |
| 19:37.05 | file | just checking |
| 19:38.29 | jrose_atDigium | committed |
| 19:38.32 | jrose_atDigium | mjordan: bump |
| 19:38.40 | mjordan | gratse |
| 19:39.05 | mjordan | jmls: it'd be a pretty easy patch... :-) |
| 19:39.08 | file | differing compiler versions - always a hoot! |
| 19:39.47 | jrose_atDigium | yep |
| 19:42.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 19:48.47 | jrose_atDigium | file/jmls: Can it really? I don't think extconfig is actually a module. |
| 19:48.59 | jrose_atDigium | Which is why it can't be found. |
| 19:48.59 | file | can what really? |
| 19:49.18 | jrose_atDigium | say 'Unload failed, 'extconfig' is a core module and cannot be unloaded" |
| 19:49.37 | file | it could say something about it being part of the core and thus not unloadable |
| 19:51.18 | jrose_atDigium | Yeah, but it's not a module. It wouldn't show up if you do core show modules. It follows that module unload extconfig is just not going to ever be found. We shouldn't be making special hooks for everything that people might mistake to be a module. |
| 19:51.55 | file | technically there's already special logic for reload to do exactly that, and execute the internal reload functions |
| 19:52.09 | jrose_atDigium | Oh, in that case I guess it's fine. |
| 20:03.27 | mjordan | jrose_atDigium: make sure you close out the other review |
| 20:03.32 | jrose_atDigium | mjordan: Review posted |
| 20:11.12 | *** join/#asterisk-dev oej (~Adium@213.132.102.114) |
| 20:11.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:14.35 | mjordan | jrose_atDigium: Review posted |
| 20:15.14 | mjordan | file: what do you think: -rc2 without r3275; or rc2 with r3275 |
| 20:16.47 | file | hum |
| 20:18.15 | file | it would be nice - but I'd like to get feedback on it |
| 20:18.33 | mjordan | agreed. |
| 20:18.37 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:18.47 | mjordan | And I'm not sure I want to hold up the train any longer. Feedback would push us into March |
| 20:18.53 | mjordan | and that's now 3 months without a release |
| 20:18.56 | file | let's not |
| 20:18.56 | mjordan | which is just bad. |
| 20:19.03 | mjordan | k, I'll put together the releases. |
| 20:19.18 | *** join/#asterisk-dev skrusty (~support@168.63.14.171) |
| 20:20.39 | maruen | mjordan, can you answer me please in pvm ? |
| 20:21.20 | mjordan | maruen: you really should ask those questions in #asterisk |
| 20:21.58 | mjordan | and unfortunately, I'm working on building releases and popping in and out of meetings, so I really can't help you debug that currently. Sorry :-( |
| 20:23.10 | maruen | no problem, thanks anyway :) |
| 20:44.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:24.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:31.13 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 21:34.31 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 21:34.31 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:55.37 | jrose_atDigium | mjordan/file: New diff posted to the review |
| 21:55.58 | file | I'm making "THE POWER OF CODE COMPELS YOU" signs at RAII_VAR :p |
| 21:59.13 | leifmadsen | lolz |
| 21:59.20 | leifmadsen | The power of greyskull compels you! |
| 22:03.48 | mjordan | obligatory: http://www.youtube.com/watch?v=lMGfENjTFjw |
| 22:05.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 22:05.39 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:07.48 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:07.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:40.48 | mjordan | jrose_atDigium: so... now we get to play what all bugs did you fix |
| 22:50.03 | newtonr | mjordan, can we just post a "try this patch" on every issue that has the word ICE in it? :D |
| 22:50.19 | mjordan | no, but probably close |
| 22:51.14 | newtonr | okay okay, ever issue with the words "ICE" and "crash" |
| 22:54.54 | newtonr | oh thats right his resolves some one way audio stuff too |
| 22:54.57 | newtonr | neat |
| 22:55.02 | newtonr | jrose_atDigium, yay |
| 23:08.56 | mjordan | jrose_atDigium: did you hit or fix a bug that looked similar to this backtrace - https://issues.asterisk.org/jira/secure/attachment/49229/backtrace_dont_optimize.txt |
| 23:13.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 23:37.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:45.48 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |