| 00:22.41 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 00:26.42 | *** join/#asterisk-dev suneye (~atcmmi@116.7.102.68) |
| 01:26.35 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.155.199) |
| 02:06.28 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 02:37.06 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:37.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:38.22 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 05:38.23 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:18.49 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 07:04.45 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 07:16.21 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:16.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:56.57 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:56.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:18.06 | *** join/#asterisk-dev luckman212_ (~luckman21@unaffiliated/luckman212) |
| 10:50.59 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 11:11.25 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 11:11.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:19.02 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-hckwgngqizngzdgr) |
| 11:19.07 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:45.40 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 11:45.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:55.53 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-eedmtweikbcpncjp) |
| 13:04.01 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 13:04.01 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:25.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uyfiwfnmoepzxlfy) |
| 13:25.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:36.27 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 13:36.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:41.50 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:41.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:52.41 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 13:53.40 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:53.40 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:57.01 | snuff-home | finally posted my update for res_sip xml :) |
| 13:57.12 | snuff-home | welcome all comments |
| 13:57.24 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 13:57.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:02.35 | mjordan | snuff-home: excellent |
| 14:02.40 | mjordan | just saw that - thanks! |
| 14:04.02 | snuff-home | np.. i think i just needed to put it up now.. otherwise i kept making minor changes |
| 14:04.38 | snuff-home | still could probably use better 'descriptions' for the main part of modules |
| 14:06.20 | mjordan | I fully expect that documentation will be getting tweaked for awhile |
| 14:06.27 | mjordan | It's good to have something in place however :-) |
| 14:07.31 | snuff-home | i probably should put the 'app_confbridge' change as just a standalone JIRA.. |
| 14:07.57 | snuff-home | it bugged me while i was removing xml errors in res_sip spotted that 1 |
| 14:09.45 | snuff-home | next on my list is probably some attempt at cli commands for res_sip.. |
| 14:10.38 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gkpuuqvkctonncjl) |
| 14:11.12 | mjordan | snuff-home: excellent. Which ones are you thinking about? |
| 14:11.36 | mjordan | for one thing, the 'sip show endpoints' - which, based on the asterisk-dev discussion, should be 'pjsip show endpoints' - could probably get some TLC |
| 14:11.53 | snuff-home | yes i really dont like that 1 atm :) |
| 14:12.00 | mjordan | blame me :-) |
| 14:12.11 | mjordan | I put it in because I wanted to see when an endpoint got made. It definitely wasn't an 'end product' |
| 14:12.28 | file | is trying to cook up an iterator implementation for sorcery |
| 14:12.58 | snuff-home | that would make things nicer file.. i was wondering how i was going to do that nicely |
| 14:13.06 | file | (so that retrieve operations for large collections aren't crazy) |
| 14:13.31 | opticron | snuff-home, make sure to click fixed or dropped on issues flagged in the review (it's a newish feature of the updated reviewboard) |
| 14:13.48 | snuff-home | yer i know :( |
| 14:13.56 | opticron | :) |
| 14:13.58 | mjordan | something that showed subscriptions would probably also be handy |
| 14:14.08 | mjordan | plus, the outbound unsolicited NOTIFY request |
| 14:14.09 | mjordan | :-) |
| 14:14.18 | snuff-home | i've done so many changes opticron can't be sure if i've addressed em all |
| 14:14.22 | mjordan | that one is a bit more involved - you have to read in sip_notify.conf |
| 14:14.35 | snuff-home | aka wasn't even looking at comments u added when re-writing most |
| 14:14.45 | opticron | fair enough |
| 14:15.27 | mjordan | snuff-home: "you can add findings on my review, I'll just ignore them" :-D |
| 14:16.22 | snuff-home | heh.. i did take the 'overall' stuff onboard.. but now i think i'm happier at my new starting point |
| 14:20.32 | snuff-home | argh.. noo clicked off my review now have to re-tick fixed on 2/3rds |
| 14:25.07 | snuff-home | ok.. done most |
| 14:27.19 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:27.19 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:33.35 | opticron | snuff-home, new review up |
| 14:36.07 | snuff-home | mm.. 12:30am here.. maybe tomorrow i look :) |
| 14:36.20 | opticron | get ye to bed |
| 14:54.56 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-vywcponwbigelvbx) |
| 15:33.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:33.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:36.09 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 16:15.24 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:34.17 | mjordan | leedm777: I actually like the macros |
| 17:00.44 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1007) |
| 17:00.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:06.05 | mjordan | file: is the expected creation time of a native bridge when two channels have joined and been verified to be compatible? Is there any reason to not let a single RTP-capable channel sit in a native bridge and, if another channel joins that isn't RTP compatible, then switch to a 2-party? |
| 17:06.39 | file | I suppose you could |
| 17:07.49 | mjordan | I'm not really concerned per se, but it looks like right now you'd have bridge creation, which will be a 2-party bridge (can't make a native bridge, no channels). Channel 1 joins (RTP), and we wait. Channel 2 joins, and we do a tech swap. |
| 17:08.18 | mjordan | this could be just pre-mature optimization however |
| 17:08.32 | mjordan | it all assumes that you *really* want an RTP native bridge the vast majority of the time |
| 17:09.03 | file | not that you really want, but that an RTP native bridge WILL occur the vast majority of the time |
| 17:09.29 | mjordan | hm. I don't think we should go chasing this unless we find that the tech swap is a bottleneck |
| 17:09.49 | mjordan | just something I thought of while I was reading ze code review |
| 17:09.53 | file | aye |
| 17:13.49 | mjordan | do we expect a different section of the code to check whether or not a channel has a monitor, audiohooks, and all the rest? |
| 17:14.02 | mjordan | ah |
| 17:14.03 | mjordan | nm |
| 17:14.04 | mjordan | found it! |
| 17:24.56 | file | la la la |
| 17:26.06 | mjordan | file: alas, I have no findings. But putnopvut or rmudgett should probably give it a final pass |
| 17:26.17 | mjordan | elguero: https://reviewboard.asterisk.org/r/2499/ |
| 17:26.27 | file | aye |
| 17:26.37 | mjordan | elguero: do you think you could commit that before tomorrow? I'm going to cut a new RC of 1.8.22.0/11.4 tomorrow, and I think that should be in there |
| 17:26.49 | mjordan | elguero: if not, no problem - I can do the commit monkey work if you'd like |
| 17:27.00 | elguero | mjordan: Sure... I can get that in |
| 17:27.25 | mjordan | thanks! |
| 18:03.43 | opticron | does asterisk's config processing support multiline values? |
| 18:03.58 | opticron | I can't seem to find a reference to it anywhere |
| 18:05.47 | file | that is a question. |
| 18:05.52 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 18:06.40 | opticron | I do, however, see multiline comments |
| 18:10.41 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cxnwzeeymjwfryht) |
| 18:16.43 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:16.43 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:24.42 | mjordan | opticron: why would you want multiline values? |
| 18:25.41 | opticron | it would be necessary if I wanted to read the sound description files with the config parser... |
| 18:26.08 | opticron | some of those descriptions are kind of unweildly |
| 18:26.49 | opticron | there's the lyrics to louie louie and a poem at minimum |
| 18:34.02 | mjordan | leedm777: I still say Ship It! |
| 18:34.10 | mjordan | opticron: why is that needed for the description? |
| 18:34.39 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:34.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:34.39 | leedm777 | shipping |
| 18:36.23 | Qwell | mjordan: svn cat https://origsvn.digium.com/svn/sounds/trunk/extra/en/extra-sounds-en.txt | grep -A16 lyrics-louie-louie |
| 18:36.36 | Qwell | It's ridiculous. |
| 18:36.51 | mjordan | funny, but ridiculous |
| 18:37.16 | mjordan | I particularly like being informed that there is a guitar solo in there |
| 18:37.45 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-khfuurinydmovqvp) |
| 18:38.27 | Qwell | mjordan: She actually says "chorus, guitar solo". |
| 18:45.33 | *** join/#asterisk-dev saghul (~saghul@ip3e830637.speed.planet.nl) |
| 18:48.12 | opticron | haha |
| 18:48.17 | opticron | I forgot about that |
| 19:18.35 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 19:18.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:20.48 | mjordan | leedm777: I am shocked that it didn't merge |
| 19:21.30 | leedm777 | mjordan: ? |
| 19:23.03 | mjordan | your commit into the ami-refactoring branch I had set up. There were... conflicts |
| 19:23.42 | mjordan | sarcasm doesn't always carry well over IRC |
| 19:23.56 | leedm777 | ah |
| 20:00.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 20:00.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:30.22 | mjordan | leedm777: opticron: qwell: what do you think about refactoring the userevent message type into the generic AMI message type |
| 20:31.43 | leedm777 | mjordan: That would be the 3rd time opticron has refactored it this week :-D |
| 20:31.50 | mjordan | yay! |
| 20:32.09 | mjordan | I think on number five we should get a plexiglass object to put on a desk |
| 20:32.39 | leedm777 | Seriously, I feel a strong meh about it. |
| 20:33.42 | leedm777 | We could get rid of some code, but it's probably, what, a dozen lines at most? |
| 20:34.03 | mjordan | er. Hrm. I'm unsure. |
| 20:34.25 | mjordan | I have a lot of random events. And making a 'minivm' message type is sitting unwell with me |
| 20:34.52 | leedm777 | re-reads what mjordan said |
| 20:35.00 | leedm777 | okay. |
| 20:35.01 | *** join/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 20:35.25 | leedm777 | I'm 100% on board with introducing the generic AMI message type. |
| 20:35.28 | mjordan | on the other hand, this also feels like something that you create when you've gotten tired of repeating yourself |
| 20:35.33 | mjordan | so maybe I'll just see how bad it gets |
| 20:35.35 | leedm777 | If that comes from refactoring the userevent stuff, then great. |
| 20:35.35 | mjordan | k |
| 20:35.42 | mjordan | moving on! |
| 20:36.12 | leedm777 | But if it's a new thing and userevent is refactored to use it later (or never), then no big. |
| 20:36.46 | alecdavis | I see my last commit to the 1.8 branch now has bamboo failing " Running ['tests/masquerade/run-test'] ..." |
| 20:37.10 | alecdavis | not sure how a state notify change, affects masquerade test |
| 20:46.15 | alecdavis | but only the 1.8 CentOS 32-bit |
| 20:46.37 | alecdavis | 1.8 CentOS 64 passes, 11 passes, as does trunk. |
| 20:49.28 | opticron | mjordan, leedm777: I was actually thinking about that while I was listening to you two talk about it earlier |
| 20:49.49 | opticron | one issue, the userevent messages have a channel snapshot attached to them currently |
| 20:50.27 | leedm777 | opticron: that might be true for many events we'd want to publish this way. |
| 20:51.07 | opticron | ok, if you let them have a channel snapshot, why not a bridge snapshot and an endpoint snapshot (if they exist) etc. |
| 20:51.53 | opticron | or do we force the producer to render the snapshot to JSON first? |
| 20:52.08 | leedm777 | was about to suggest the rendering to JSON |
| 20:53.05 | leedm777 | ast_manager_build_channel_state_json |
| 20:53.30 | leedm777 | Then add extra fields to the JSON object and send it on. |
| 20:54.47 | opticron | or you build your json blob with ast_json_pack, then build your flat message blob, then use ast_json_object_update to merge them |
| 20:54.55 | opticron | err |
| 20:55.09 | opticron | s/flat message blob/channel snapshot blob/ |
| 20:55.35 | leedm777 | that works, too |
| 20:56.18 | opticron | of course, ast_channel_snapshot_to_json will need to take a prefix parameter >:D |
| 20:56.39 | leedm777 | Or maybe a suffix. |
| 20:56.44 | leedm777 | where did we land on that? |
| 20:56.48 | opticron | infix! |
| 20:56.51 | opticron | leedm777, prefix |
| 20:56.54 | leedm777 | Both! |
| 20:57.02 | opticron | muh muh muh muh multifix |
| 20:57.52 | leedm777 | opticron: yes. prefix param, or have the JSON->AMI thingie be really clever. |
| 20:58.33 | leedm777 | { Foo: { Bar: x, Bam: y } } -> FooBar: x FooBam: y |
| 20:58.46 | opticron | _flat_ |
| 20:58.52 | leedm777 | yeah |
| 20:58.54 | leedm777 | keep it simple |
| 21:08.17 | mjordan | I'm still debating this in my head |
| 21:08.39 | mjordan | I feel like there's a happy medium somewhere |
| 21:10.40 | leedm777 | mjordan: one alternative is to have different generic AMI message types for the different blob types we have. |
| 21:12.00 | leedm777 | so there's like half a dozen new message types, and the code in manager_*.c to render them into events. |
| 21:12.18 | leedm777 | and when it's time to post an event, you've got to select the type of event that's right for you. |
| 21:12.39 | leedm777 | opticron's alternative is that there's one type, with different tools for building it. |
| 21:12.44 | leedm777 | seems much simpler to me |
| 21:29.01 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-wwysvfatnngehvbx) |
| 22:05.51 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-puxeehaxbmnjiwvc) |
| 22:52.52 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:52.52 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:12.33 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uyfiwfnmoepzxlfy) |
| 23:38.35 | *** part/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 23:39.15 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:39.15 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |