| 00:06.05 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:02.37 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 01:05.06 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 01:05.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:05.40 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 02:25.25 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 04:26.26 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 06:57.40 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 06:57.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:02.33 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 08:32.10 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 11:36.56 | *** join/#asterisk-dev r00ttolo (~Alex1@93-33-128-80.ip44.fastwebnet.it) |
| 11:37.05 | *** part/#asterisk-dev r00ttolo (~Alex1@93-33-128-80.ip44.fastwebnet.it) |
| 12:03.50 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-92-199.hsd1.mi.comcast.net) |
| 12:32.46 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:32.46 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:49.24 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:56.27 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-fgcnuuerptwtetsq) |
| 13:25.29 | *** join/#asterisk-dev serafie1 (~erin@user-24-214-173-250.knology.net) |
| 13:28.13 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:28.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:30.03 | file | definitely a Monday |
| 13:35.43 | [tpn]leifmadsen | +1 |
| 13:49.16 | putnopvut | Can anyone find a fault in this xi:include xml element I've put in my features config documenatation? When I run the CLI command to show the config, nothing prints after "featuredigitstimeout". |
| 13:49.17 | putnopvut | <enum name="featuredigittimeout"><xi:include xpointer="xpointer(/docs/configInfo[@name='features']/configFile[@name='features.conf']/configObject[@name='globals']/configOption[@name='featuredigittimeout']/synopsis)" /></enum> |
| 13:50.07 | putnopvut | From what I can tell, the hierarchy I've used for the inclusion is correct, but there may be something completely obviously wrong that I'm missing. |
| 13:58.35 | opticron | looks |
| 13:59.12 | opticron | is that in current trunk or do I need a branch to poke at it? |
| 13:59.37 | elguero | is it featuredigitstimeout or featuredigittimeout? |
| 13:59.53 | opticron | lol |
| 13:59.55 | elguero | notice one says "digits" vs digit |
| 14:00.04 | opticron | good catch elguero |
| 14:01.42 | putnopvut | Okay, couple of answers: |
| 14:01.56 | putnopvut | It's in team/mmichelson/features_config_docs |
| 14:03.04 | putnopvut | Second, my "featuredigitstimeout" is a typo in this channel, but the documentation is all spelled correctly. Furthermore, featuredigittimeout is not the only place this is occurring. I figured I'd showcase it so we're only looking at one thing instead of 15. |
| 14:04.07 | elguero | ah, man... hoped that was it... silly typo |
| 14:04.29 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-yvbcgzldazeuxuiy) |
| 14:13.38 | opticron | putnopvut, reproduced the issue here, poking at it |
| 14:13.55 | putnopvut | opticron: okay. I'm poking too. Let me know if you come up with anything. |
| 14:14.19 | putnopvut | Biggest issue here is that I have no clue how to debug this. |
| 14:15.48 | opticron | well, it doesn't seem to be a transclusion failure |
| 14:15.53 | opticron | because that would fail the build |
| 14:15.58 | opticron | bah |
| 14:16.02 | opticron | keeps using that workd |
| 14:16.05 | opticron | word |
| 14:16.07 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-vauomrodkkvvivnb) |
| 14:16.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:16.08 | opticron | xi:include failure |
| 14:17.48 | putnopvut | Had a hypothesis the string was too long, so I shortened it to <xi:include xpointer="xpointer(/docs/configInfo[@name='features']/synopsis)" /> but that didn't result in anything being printed. |
| 14:17.56 | opticron | putnopvut, figured it out |
| 14:18.04 | putnopvut | nice |
| 14:18.08 | opticron | it needs a <para/> around it |
| 14:18.33 | opticron | it wasn't failing the xmllint because it has the synopsis tags in there still and that was hiding the error |
| 14:19.04 | putnopvut | That's something I could have sworn I tried earlier. |
| 14:19.35 | putnopvut | Hm, it does include the synopsis tags. |
| 14:19.40 | putnopvut | That's less than desirable. |
| 14:20.17 | putnopvut | <PROTECTED> |
| 14:20.17 | putnopvut | <PROTECTED> |
| 14:20.37 | putnopvut | Any way I can strip those tags off? |
| 14:20.44 | opticron | putnopvut, use /text() at the end of the xpath |
| 14:20.53 | putnopvut | Excellent. Thanks. |
| 14:20.58 | opticron | :D |
| 14:21.41 | putnopvut | Perfect! |
| 14:48.02 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:48.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:51.05 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:51.05 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:11.29 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 15:36.54 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1009) |
| 15:36.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:47.54 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:47.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:57.36 | *** join/#asterisk-dev n8ideas (~joshua@c-67-167-236-85.hsd1.il.comcast.net) |
| 15:58.50 | n8ideas | If I want to link an external library (say json-c) and verify it exists before allowing compile, what's the best strategy inserting that dependency? |
| 16:06.31 | mjordan | n8ideas: add a dependency via configure.ac. There's some basic information about doing so on the Asterisk wiki here: https://wiki.asterisk.org/wiki/display/AST/Build+System+Architecture |
| 16:07.17 | n8ideas | @jordan Can't believe I hadn't found that before... appreciate it. |
| 16:07.45 | mjordan | np |
| 16:08.10 | mjordan | someone asked about it on the -dev list awhile back and I walked through the ALSA example a bit, that might be helpful too |
| 16:08.12 | mjordan | http://lists.digium.com/pipermail/asterisk-dev/2012-July/055925.html |
| 16:22.08 | n8ideas | so getting a checking for json_object_new_string in -ljson-c... yes ./configure: line 28185: AST_JSON-C_FOUND=yes: command not found |
| 16:22.22 | n8ideas | Did I miss a step? |
| 16:24.22 | putnopvut | The '-' in there may be causing problems. |
| 16:25.11 | n8ideas | ah.. ok |
| 16:26.15 | putnopvut | So, this past weekend, I worked on getting features configuration documented using XML. Mostly things went well, but I came across two problems. One appears to be a bug, and the other is likely me not knowing the proper way of handling things. |
| 16:26.52 | putnopvut | First, I noticed that if I place a <syntax> element in a configOption, then when I use the "config show help foo bar baz" to show help for the option name, the syntax doesn't print. |
| 16:27.14 | n8ideas | you were correct on that... now getting: ./configure: line 57982: PBX_JSON-C=C:@PBX_JSON-C@: command not found |
| 16:27.42 | putnopvut | Instead, some generic syntax seems to show up instead. Is that a bug in how the XML is parsed by the config framework? |
| 16:28.10 | n8ideas | Oh.. wait. One more typo. |
| 16:28.39 | putnopvut | Second, I'm unsure of how to document a configuration option such as an applicationmap item. The "name" of the option is custom, so I don't know how to indicate that properly through the XML docs. |
| 16:29.23 | putnopvut | I also am unsure of how to indicate that the applicationmap can accept multiple items. |
| 16:30.47 | mjordan | looks at bug one |
| 16:32.06 | n8ideas | OK. Got the lib added, and that works... but I am not seeing the way to match up MODULEINFO depends name with what I put in the library. What name do I use? |
| 16:32.53 | mjordan | putnopvut: that's odd. cli_show_module_options should show the syntax for a configOption node. It dumps out syntax and description. |
| 16:32.54 | n8ideas | is it the second parameter in configure.ac? |
| 16:33.18 | putnopvut | n8ideas: that's one of those things I've always been fuzzy on. I *think* you're correct though. |
| 16:33.42 | putnopvut | mjordan: yeah, I see that a syntax is printed, but it appears not to be populated with the syntax from the XML. |
| 16:34.00 | n8ideas | That doesn't seem to be working... unless I need to rerun some sort of process after changing that. |
| 16:34.07 | putnopvut | I was just looking at xmldoc_update_config_type |
| 16:34.09 | mjordan | which means it's associating a different configOption syntax element with that one. Scary. |
| 16:34.24 | putnopvut | Trying to see how the syntax was set. |
| 16:35.08 | mjordan | as far as the second one goes, ConfBridge has a similar item - the DTMF menus, which uses a regular expression. The help for that matches on the regular expression, which is unfortunate - but I'm not sure how else to do it. |
| 16:35.42 | putnopvut | All right I'll use confbridge as an example then. |
| 16:36.07 | mjordan | putnopvut: I wonder if you got multiple results from the xpath query. |
| 16:37.32 | putnopvut | No idea at this point. I notice that the xmldoc query that's done at the beginning of xmldoc_update_config_type() searches for configObject syntax but I don't see anything like that being done for configOption syntax. |
| 16:38.11 | putnopvut | Ah that's because I need to look at xmldoc_update_config_option(), probably |
| 16:40.04 | putnopvut | Ah, hm, xmldoc_get_syntax_config_option() in xmldoc.c may hold the answer. |
| 16:40.27 | putnopvut | It's not trying to get a syntax element. It instead just builds a string based on attributes of the configOption. |
| 16:40.44 | mjordan | heh |
| 16:40.53 | mjordan | wonders why he did that |
| 16:41.24 | mjordan | ah |
| 16:41.32 | putnopvut | I'm sure that's fine as a "default" behavior, but if the DTD allows syntax elements, then I'd think you'd want to get that instead. |
| 16:41.33 | mjordan | now I remember. You usually don't want the syntax to be defined. |
| 16:41.38 | mjordan | yes |
| 16:42.42 | putnopvut | For something like an applicationmap item, where you have a name = dtmf,activate_on,app[,app_data[,mohclass]] a syntax element can be nice. |
| 16:44.06 | mjordan | agreed. Probably would be better if the confbridge DTMF map had one as well |
| 16:49.19 | n8ideas | @mjordan - so I got all three files updated and ./configure runs properly, but I'm not picking up the dependency as there in MODULEINFO |
| 16:50.25 | n8ideas | only thing weird is my LD Flags when not building in Asterisk are -ljson-c |
| 16:50.56 | n8ideas | so I wrote the configure.ac this way: AST_EXT_LIB_CHECK([JSONC], [json-c], [json_object_new_string], [json/json.h]) |
| 16:51.30 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 18:04.05 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:04.05 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:19.53 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:19.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:50.16 | putnopvut | mjordan: from ASTERISK-21337 (aka "too elite"), it says that the Transfer stasis message needs to have "The Transferer channel snapshots and the transfer target channel snapshots." I'd like to clarify which parties are meant here and how they should be represented. |
| 18:50.16 | LieutPants | [ASTERISK-21337] [Status: Open] Bridge API Enhancements - add stasis core messages for blind/attended transfers - https://issues.asterisk.org/jira/browse/ASTERISK-21337 |
| 18:50.45 | putnopvut | In a blind transfer, there is a transferer channel, one or more transferee channels, and a dialplan destination. |
| 18:51.06 | file | who is performing the transfer and who is being transferred I would think |
| 18:51.10 | putnopvut | In an attended transfer, there is a transferer, one or more transferee channels, and either one or more transfer targets (in a bridge) or a dialplan destination again. |
| 18:52.04 | putnopvut | What I'm wondering is, if we give the bridge uniqueids (or snapshots) of the bridges involved, and we specify the channel that performed the transfer, then do we need explicit channel snapshots of the other channels? |
| 18:54.24 | putnopvut | I guess also, for blind transfers, I'd have to have two transferer channel snapshots. |
| 18:54.28 | putnopvut | s/blind/attended/ |
| 18:56.47 | mjordan | putnopvut: let's forget the bridge transfer scenarios. For blind, I'd think you'd have the initiator of the transfer and the channel who was transferred. For attended (w/ channel), you'd have initiator, the channel who was transferred, and the destination channel. For attended w/app, you'd have the app of the last CEP tuple that was executed. |
| 18:57.04 | mjordan | putnopvut: if the target of the transfer is a bridge, then I think the bridge ID is sufficient |
| 18:58.34 | mjordan | The primary reason for this is the attended transfer to an application scenario. With all of the others, BridgeEnter/BridgeLeave messages account for what happened |
| 18:59.10 | mjordan | But in the attended transfer to application, there's a loss of information when the transfer is completed. We don't know where the transfer target is, since they were masqueraded out of the bridge. |
| 18:59.24 | putnopvut | Actually there shouldn't be a loss of information. |
| 18:59.27 | mjordan | how so? |
| 18:59.41 | putnopvut | The transfer to application works by having the channel leave the bridge and perform the masquerade as an after bridge callback. |
| 18:59.52 | putnopvut | So you should still get the bridgeleave event for the transferred channel |
| 18:59.56 | mjordan | hm. That's different than when I originally created the issue |
| 19:00.00 | mjordan | and much better |
| 19:00.13 | putnopvut | indeed it is. |
| 19:00.38 | mjordan | do you get any message when the channel is masqueraded into the application? |
| 19:01.09 | mjordan | I almost wonder if the only thing we need is to make sure the channel's CEP is updated with the new location (which should trigger a message). |
| 19:01.13 | mjordan | That tells you where the channel is. |
| 19:01.18 | putnopvut | Well I think the channel that originally was in the application will be hung up, but I don't think you get anything telling you that a channel took its place. |
| 19:01.29 | putnopvut | It would be a pretty easy thing to have ast_channel_move() spit out a stasis event. |
| 19:01.57 | mjordan | opticron: for CEL, is the above sufficient for transfers? ^^^ |
| 19:02.00 | putnopvut | A "this channel is now where this other channel currently was" |
| 19:02.05 | mjordan | right |
| 19:02.10 | mjordan | That's really the whole point for this |
| 19:02.16 | mjordan | I think every other use case is more or less covered. |
| 19:02.58 | mjordan | Something that says a transfer occurred isn't bad, however, since otherwise it's just a bunch of bridgeenters/bridgeleaves, and some consumers may care about the concept at a higher level. The question is whether or not they actually do care |
| 19:03.08 | putnopvut | Yes, there should def be a transfer stasis message. |
| 19:03.17 | putnopvut | It makes it easier for things like app_queue to know a transfer occurred. |
| 19:03.24 | mjordan | ah, that's true |
| 19:03.33 | putnopvut | It's really a matter of what information needs to be present. |
| 19:03.39 | mjordan | queue log will like that. CDRs may not actually end up needing it |
| 19:03.58 | mjordan | Probably the most important part is where the party that was transferred ended up |
| 19:04.27 | putnopvut | Okay. That would either be a bridge or an app. |
| 19:04.28 | mjordan | in the case of transferring a bridge, it will be a Local channel, which won't be fantastic but at least will be consistent |
| 19:04.33 | mjordan | yeah. |
| 19:04.49 | mjordan | that would work. If its a bridge and someone wants to know the channels they can find out |
| 19:05.16 | opticron | reads the backlog |
| 19:05.16 | putnopvut | Right now I'm including bridge snapshots, so all involved channels will be available. |
| 19:05.29 | putnopvut | I could just include uniqueids instead. |
| 19:06.57 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:06.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:26.50 | file | also reads backlog |
| 19:38.08 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-92-199.hsd1.mi.comcast.net) |
| 20:53.05 | pabelanger | Is there any know performance issues with asterisk and misdn? |
| 20:53.26 | WIMPy | which misdn? |
| 20:53.45 | pabelanger | I'm seeing asterisk spike my CPU to 25% every ~1min or so |
| 20:53.48 | pabelanger | for about 10 seconds |
| 20:53.58 | pabelanger | WIMPy: old, this is 1.4 |
| 20:54.00 | pabelanger | let me get version |
| 20:54.31 | WIMPy | I can't remember having had that, but that's a looong time ago. |
| 20:57.05 | pabelanger | static const char * svn_version = "$Id: bfsi_tlg.c,v 1.1.1.1 2008/01/09 15:01:13 pastuszak.p Exp $"; |
| 20:57.07 | pabelanger | it is OLD |
| 20:57.46 | pabelanger | maybe 1.1.6 |
| 20:58.40 | pabelanger | either way, need to get gdb attached to this embedded box and see what is happening |
| 20:58.51 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-180-203-73.hsd1.tn.comcast.net) |
| 20:58.51 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 20:58.58 | WIMPy | I don't really understand why anyone would want to use the old stuff when there are much better alternatives. |
| 20:59.28 | *** join/#asterisk-dev tzanger (tzanger@wallace.mixdown.ca) |
| 20:59.42 | pabelanger | Me neither, but this project is locked down and winding down. I have to play the hand I am dealt |
| 21:00.13 | pabelanger | and, misdn could be dropped since they are only using it for BRI support |
| 21:00.19 | pabelanger | which DAHDI now supports |
| 21:00.56 | WIMPy | Or the new mISDN. |
| 21:01.58 | pabelanger | Either way, I can see the mISDNstackd spike, then asterisk follows soon after |
| 21:03.31 | WIMPy | Only while it has an active connection? |
| 21:04.04 | pabelanger | yup |
| 21:07.00 | WIMPy | Still doesn't sound familiar. Why don't you change it to DAHDI? |
| 21:07.43 | pabelanger | there is no technical reason why I could not change.... it is a procedural reason why I cannot |
| 21:09.07 | WIMPy | And what about at least the latest version of the old version? |
| 21:09.56 | pabelanger | negative, impact to big at this point in time. If I weeks or months maybe, but don't think the project is going to be around that long. |
| 21:10.00 | pabelanger | money is running out |
| 21:10.20 | pabelanger | 9months ago I could have, but I was not around for that discussion |
| 21:11.09 | WIMPy | It probably should have happened 4 years ago :-) |
| 21:12.03 | pabelanger | either way, just trying to see if there are any know issues on performance in the past. That would help me show project manager a reason to upgrade and trigger the regression testing |
| 21:12.17 | pabelanger | I agree with that |
| 21:12.59 | pabelanger | okay, home time |
| 21:13.03 | pabelanger | will continue tomorrow |
| 21:13.06 | pabelanger | WIMPy: thanks |
| 22:16.44 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:16.44 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:49.13 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:49.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:01.22 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:01.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:11.51 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:11.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:24.57 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:24.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:36.42 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:36.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:46.03 | *** join/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 23:46.49 | alecdavis | @mjordan: |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.52 | alecdavis | <PROTECTED> |
| 23:46.53 | alecdavis | <PROTECTED> |
| 23:46.53 | alecdavis | <PROTECTED> |
| 23:46.54 | alecdavis | <PROTECTED> |
| 23:46.54 | alecdavis | <PROTECTED> |
| 23:47.37 | alecdavis | I can see there should be locking of the brdigecallno??? |
| 23:55.12 | mjordan | alecdavis: what function/lineno? |
| 23:56.17 | mjordan | nm, found it |
| 23:56.56 | *** join/#asterisk-dev snuff-work (~snuffy@58.171.61.190) |
| 23:56.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:57.57 | mjordan | this entire piece of code scares me. |
| 23:58.05 | mjordan | but yes, based on a cursory look and similar message handling. |
| 23:58.43 | mjordan | reaching across a bridge to grab another channel and set its state is .. fun. |
| 23:59.17 | mjordan | alecdavis: you'll obviously need to do the usual deadlock avoidance while trying to grab the lock for iaxs[fr->callno]->bridgecallno |