| 00:26.47 | *** part/#asterisk-dev w9sh (~Steven@adsl-69-208-131-6.dsl.ipltin.ameritech.net) |
| 01:00.38 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:01.23 | *** join/#asterisk-dev suneye (~atcmmi@119.122.153.109) |
| 01:26.13 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 01:26.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 01:30.19 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 02:09.26 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.154.172) |
| 03:05.18 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 04:56.26 | *** join/#asterisk-dev suneye (~atcmmi@119.122.153.109) |
| 05:38.45 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.154.115) |
| 08:50.07 | *** join/#asterisk-dev eZz (~ez@194.28.91.31) |
| 08:52.51 | *** join/#asterisk-dev suneye (~atcmmi@119.122.154.172) |
| 08:59.18 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 09:20.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.249) |
| 09:55.11 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 09:55.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:56.28 | *** join/#asterisk-dev suneye (~atcmmi@119.122.154.172) |
| 10:18.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.249) |
| 11:43.19 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 12:00.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.71.230) |
| 12:12.16 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:12.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:20.38 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 12:42.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.71.230) |
| 12:52.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-sddxddydbbvxbdls) |
| 12:58.50 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:58.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:27.47 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-kthhuhqhuiaaseed) |
| 13:27.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:29.05 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@83.220.236.239) |
| 13:34.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:34.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:39.42 | *** join/#asterisk-dev w9sh (~Steven@adsl-69-208-131-6.dsl.ipltin.ameritech.net) |
| 13:50.33 | leedm777 | hm. app_queue returns AST_MODULE_LOAD_DECLINE if it encounters failures during load. Shouldn't that be AST_MODULE_LOAD_FAILURE? |
| 13:53.58 | file | mjordan, I have a question about your comment on the outbound proxy review - why did you think to enforce a check for the source to be the outbound proxy? |
| 13:55.05 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:55.05 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:03.38 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-jjgfkxmexlamzloj) |
| 14:03.38 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:07.09 | mjordan | file: so, here's my general train of thought, which may or may not be correct |
| 14:07.27 | mjordan | you may have a configuration that has peers that use the outbound proxy, and peers that don't. You may also have allowguest enabled. |
| 14:08.02 | mjordan | If a request comes from the outbound proxy and was from a peer that was configured to use the outbound proxy, we should map it to that peer |
| 14:08.30 | mjordan | If a request comes from the outbound proxy and was from a peer that either (a) we don't know about, or (b) was not configured to use the outbound proxy, we should treat the request as coming from the proxy |
| 14:08.44 | mjordan | which means it will either match a peer that is the outbound proxy, or get treated as a guest call, or get dropped |
| 14:09.24 | mjordan | as for "from proxy originally from peer => mapping it to that peer w/ outbound proxy support", the only thing I can think of to match on is user |
| 14:12.21 | file | dangerous road... |
| 14:13.10 | file | ponders |
| 14:14.05 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-faxoruhvbeqostsh) |
| 14:16.28 | mjordan | It's a proposal; I expect there to be problems :-D |
| 14:16.50 | file | it's the ripple effect that worries me |
| 14:17.59 | mjordan | I'm hopeful we can limit it by only applying said logic if the inbound request matches the address of what the outbound proxy currently resolves to |
| 14:18.11 | mjordan | that keeps this from spilling out too far |
| 14:18.34 | mjordan | the tricky part now though is multiple outbound proxies configured on peers, not globally |
| 14:18.39 | mjordan | you'd have to cache a list of them |
| 14:20.34 | file | see, I'm not convinced that mucking with matching is the answer... I personally prefer working within the confines of what people already know for how matching works - ie: if you want to direct calls from a proxy then create a peer accordingly, if you want to match based on user then create a user accordingly |
| 14:21.27 | mjordan | I understand why you like that, but I don't think people want a peer for the proxy. |
| 14:21.38 | pabelanger | ! |
| 14:21.47 | mjordan | If I get something from the proxy but that originally came from peer foo, they want it to match to peer foo |
| 14:21.55 | file | but how do you know it's from foo? |
| 14:22.11 | mjordan | therein lies the rub. There has to be something that identifies that |
| 14:22.23 | mjordan | Either the user, or the From URI, or something |
| 14:22.29 | file | that's standard user matching |
| 14:22.36 | file | and would still work |
| 14:22.49 | mjordan | right |
| 14:22.58 | mjordan | but we don't (IIRC) match on the user part for peers |
| 14:23.04 | mjordan | at least, for inbound INVITE requests |
| 14:23.46 | mjordan | *if* you get something from a proxy and it doesn't provide anything that helps you match it to the peer that originally sent the request, then you're SOL |
| 14:24.06 | file | I don't recollect off the top of my head, but using a friend or a separate user would work provided the name matches that of the user portion of the From |
| 14:24.20 | mjordan | right, and I don't think folks want that either :-) |
| 14:24.47 | pabelanger | So, here is a scenario that I am using. I actually don't want sip.conf to know anything about my peers, basically accepting incoming (insecure) SIP calls from my proxy, then dial back out through it. Based on the SIPDOMAIN extracted from the message header, is how I use dialplan to route back to a specific extension and domain |
| 14:24.48 | mjordan | anything that devolves to "define multiple things for the same physical device" or "define things for something that isn't really a device I want to talk to" is kind of getting into "ew" |
| 14:25.06 | pabelanger | Otherwise, I need to duplicate configuration inside asterisk and the proxy |
| 14:25.08 | mjordan | pabelanger: I don't think that's the purpose of the outboundproxy |
| 14:25.16 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-hnvkmkbetdkkccpf) |
| 14:25.40 | file | your proposed changes effectively make the code do that |
| 14:26.03 | mjordan | Yup, but it infers it from the outboundproxy setting and doesn't require the user to define those things |
| 14:26.19 | mjordan | pabelanger: curious, why wouldn't allowguest=yes "work" for you? |
| 14:26.23 | mjordan | as well as just dialing by URI? |
| 14:26.48 | file | erm, but you'd have to define the peer as having the name of the user portion of the From so it can't infer completely |
| 14:27.10 | pabelanger | mjordan, because this box is on the public web, and I only want domains I have authenticated with my proxy to be allowed. So, I setup a peer with my proxies to be the only traffic I accept from |
| 14:27.12 | mjordan | hm. That's not ideal necessarily, but not terrible either |
| 14:27.22 | file | you have nothing else to match on it otherwise |
| 14:27.35 | file | you have no other way to associate the incoming INVITE with *something* |
| 14:27.40 | mjordan | file: yup |
| 14:27.44 | file | (at least by using what chan_sip has) |
| 14:27.47 | pabelanger | But, since testing the patch on review board, I've actually been able to get my setup working without any patch, simply by reworking configuration |
| 14:27.48 | mjordan | file: I think I was assuming that peer name was something matchable |
| 14:28.04 | mjordan | which I don't think is a terrible assumption |
| 14:28.06 | mjordan | :-D |
| 14:28.38 | mjordan | Hm. I don't think JIRA is picking up issue closures that affect the testsuite. |
| 14:29.25 | file | I'd personally just use type=friend OR push my auth to the proxy, add a header with the username, and then access that in the dialplan to route accordingly |
| 14:29.43 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:29.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:36.17 | mjordan | hm. |
| 14:36.49 | mjordan | yay! And JIRA now "knows" of the testsuite. |
| 14:40.51 | leifmadsen | w00t |
| 14:40.54 | leifmadsen | that's nice |
| 14:41.11 | mjordan | I just noticed that it didn't seem to link any of it under the Subversion tab. |
| 14:41.12 | mjordan | :-\ |
| 14:41.17 | file | JIRA knows what we TELL IT |
| 14:53.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:53.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:08.34 | anonymouz666 | if you distribute device state, wouldn't make sense to distribute also wrapuptime time somehow? |
| 15:08.36 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 15:08.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:10.47 | anonymouz666 | if agent A answers queue A in box A the wrapuptime must go to box B because the same agent is in queue B |
| 15:18.24 | pabelanger | anonymouz666, Ideally yes, both asterisk boxes should know the state of the other queue. However, IIRC device states work just for devices, you are looking at a setting for a queue |
| 15:18.58 | pabelanger | same would apply to paused state |
| 15:19.07 | pabelanger | is it not distributed |
| 15:19.58 | pabelanger | FWIW: You're likely better to move your queues outside asterisk if you want to load balance, that's what we ended up doing |
| 15:27.44 | *** part/#asterisk-dev w9sh (~Steven@adsl-69-208-131-6.dsl.ipltin.ameritech.net) |
| 15:28.40 | jgowdy | Just submitted my AstriDevCon form. Hope there's a tiny chance still. :) |
| 15:32.48 | pabelanger | jgowdy, bride rnewton when he pops online |
| 15:34.01 | jgowdy | thanks |
| 15:34.47 | *** join/#asterisk-dev vlad_starkov (~vlad_star@nat.canmos.ru) |
| 15:36.15 | jgowdy | We're working on adding extensibility to features to enable multi-site multitenancy, so I'm starting to write Asterisk code rather than just debug it. Fun stuff. |
| 15:36.31 | jgowdy | If there's no room left, I'll take a folding chair in the hallway |
| 16:20.29 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 16:20.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:13.39 | pgrace | Is anyone here particularly familiar with features.c? I'm wondering if there was a "Good Reason" why variable substitution doesn't work when you trigger a feature before considering whether I want to spend time trying to create a patch to make it work. |
| 17:13.59 | mjordan | pgrace: yes, there are plenty of people here familiar with it |
| 17:14.28 | mjordan | when you say variable substitution doesn't work when you trigger a feature, how are you triggering said feature? |
| 17:14.35 | pgrace | mjordan: awesome, I'm curious why variable substitution was never added to features.c -- is it because the arguments are pre-considered at the point of loading the config file? |
| 17:14.37 | mjordan | feature map? |
| 17:15.08 | pgrace | yes, I am trying to stop and resume MixMonitor in a feature. The problem is that if I pass ${UNIQUEID} into the argument for filename, the filename is literally ./${UNIQUEID}.wav |
| 17:15.25 | pgrace | leading me to believe that variable substitution does not work on arguments in features. |
| 17:16.27 | pgrace | I was lightly skimming features.c and did not see a mention, at least that I was aware of, of the variable substitution code in there. Admittedly though, it's been years since I've went mucking about in the source code. |
| 17:16.27 | mjordan | k. What channel should UNIQUEID be resolved on? The issuer of the feature, or its target? |
| 17:16.53 | mjordan | so, first, I'd say it's that way because no one cared :-) |
| 17:16.54 | pgrace | Both channels would share the same uniqueid, would they not? |
| 17:16.58 | mjordan | no |
| 17:17.01 | mjordan | same linkedid |
| 17:17.05 | mjordan | different unique ids |
| 17:17.21 | mjordan | but say it's an arbitrary channel variable |
| 17:17.22 | pgrace | hmm, when a cdr is written then, that field, is it the linkedid or the uniqueid of one of the two legs? |
| 17:18.10 | mjordan | The unique ID is of the source channel. Linkedid is the same for both. |
| 17:18.30 | pgrace | That's an interesting question then. In my use case specifically I'm not sure what channel variable I'd want. I'd probably define the filename of my recording prior to starting mixmonitor and store it in a variable for later reference. |
| 17:18.58 | mjordan | right. In which case, just use GoSub and extract it from the channel sent to the subroutine |
| 17:19.52 | pgrace | GoSub from the feature call itself, you mean? |
| 17:20.40 | mjordan | Instead of calling Monitor/MixMonitor directly from the application map, call a subroutine that the channel can access. |
| 17:20.54 | mjordan | From the subroutine, set up the name of the recording, start/stop the recording, then return |
| 17:21.23 | pgrace | Ah, ok, I'll give that a try now |
| 17:22.27 | mjordan | the answer is: no one bothered to put in variable substitution, but it could be done on a general basis |
| 17:23.48 | pgrace | It seems like not a bad idea -- I was e-mailing with a gentleman in the UK who had my exact same problem. He mentioned he gave up on figuring out how to pause/unpause mixmonitor via features but I told him I'd let him know if I arrived at an answer. |
| 17:24.22 | mjordan | the nice thing about sending it to a subroutine is you have all the "time" - or lines in diaplan - to figure out whether or not you actually want to start the feature, etc. |
| 17:24.49 | pgrace | I use ael configs, so I'd just specify a macro I assume to handle this then Gosub(macro)? |
| 17:25.24 | elguero | mjordan: Do you think it would be beneficial? I have a simple patch that we use internally for that.. specifically using MixMonitor ourselves to start and stop recordings using application map |
| 17:25.31 | pgrace | actually, I could just settle with making a context and an 's' extension. |
| 17:25.43 | pgrace | elguero: ooh, really? That'd solve my problem here without getting fancy. |
| 17:26.04 | pgrace | elguero: if you are able to share it, I'd love a copy :) pete@stackoverflow.com please |
| 17:26.15 | elguero | pgrace: Are you on 11? |
| 17:26.20 | mjordan | elguero: I doubt the patch would hurt :-) |
| 17:26.36 | pgrace | elguero: certified 1.8 unfortunately. If the mixmonitor code hasn't changed much, I could backport it I assume. |
| 17:26.39 | mjordan | but yeah, a macro *should* work |
| 17:26.47 | pgrace | Sometimes half the battle is knowing how it was done, then it's just doing it. |
| 17:26.51 | elguero | never saw anyone ask for it... so thought we might be unique |
| 17:26.57 | mjordan | neither features nor mixmonitor changed a lot between 1.8/11 |
| 17:27.11 | elguero | or just didn't think of a better way at the time |
| 17:27.38 | elguero | well, the patch is against features.c |
| 17:28.41 | elguero | I will probably create an issue then and attach a patch for you... but it would only be included in trunk |
| 17:29.05 | pgrace | that's fine, I can backport it once I see the patch. I was still in the "is this worth trying to do?" phase of decisionmaking |
| 17:29.37 | pgrace | mjordan: I think I will try the gosub method anyway just to have the joy of figuring out an alternative solution. |
| 17:30.12 | mjordan | have fun :-) |
| 17:30.35 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-iurvnzhywivvcjjv) |
| 17:38.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.182) |
| 17:40.35 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ntckvxvpjxshbpmi) |
| 17:40.35 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:46.00 | pgrace | mjordan: wow, that is surprisingly elegant. Thank you so much for cluing me into using gosub. I actually used Macro(), but it seems to work just as well. |
| 17:46.44 | mjordan | good! :-) |
| 17:46.51 | mjordan | always nice when advice actually works |
| 17:49.22 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cguzraigukexnrka) |
| 17:50.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 17:50.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:53.40 | elguero | pgrace: https://issues.asterisk.org/jira/browse/ASTERISK-22608 |
| 17:53.57 | elguero | pgrace: just in case that interests you at all |
| 18:30.24 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-jxujwxbvobupbtiq) |
| 19:03.00 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 19:30.14 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:30.14 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:31.33 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-98-224-144-181.hsd1.mi.comcast.net) |
| 19:48.02 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-ncoaynwvuzvsybdv) |
| 21:11.43 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-tknujosfxdaeysnw) |
| 21:11.43 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:58.28 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-kthhuhqhuiaaseed) |
| 22:02.26 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:02.26 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:10.44 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 22:17.36 | pabelanger | seanbright, nice work |
| 22:32.09 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 22:47.49 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-hnvkmkbetdkkccpf) |
| 22:54.26 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |