| 00:29.06 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 00:32.11 | *** join/#asterisk-dev italorossi (~Adium@187.61.182.39) |
| 00:38.34 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 00:38.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:04.53 | *** join/#asterisk-dev italorossi (~Adium@187.61.182.39) |
| 05:14.37 | *** join/#asterisk-dev RiceCracker (~RiceCrack@59.152.236.158) |
| 05:31.47 | jmls | i don't understand the point of AUDIOHOOK_INHERIT |
| 05:31.53 | jmls | given this issue: https://issues.asterisk.org/jira/browse/ASTERISK-16483 |
| 05:32.29 | jmls | a starts recording with audiohook_inherit set, dials B |
| 05:32.43 | jmls | a transfers call to c, recording stops |
| 05:33.15 | jmls | what does audiohook_inherit have to do with this ? without it , the recording will still stop |
| 05:33.24 | jmls | because a has hungup |
| 05:33.57 | jmls | if b transfers to c, then the recording will continue because it's on a, again making audiohook_inherit pointless |
| 05:35.15 | jmls | surely when a xfers to c, audiohook_inherit should tell c (or b) to take over the ownership of the recording ? |
| 05:39.22 | jmls | interesting: according to the reviewboard for this feature https://reviewboard.asterisk.org/r/102/diff/1-3/ |
| 05:39.38 | jmls | "I have tested by using MixMonitor on a channel which gets masqueraded into a new channel as a result of transferring. I have tried both attended and blind transfers, both with the channel as the caller and callee. The result was that the recording continued across the transfer." |
| 05:58.43 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 05:58.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:27.16 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 06:35.43 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:08.48 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 07:08.50 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Many thanks to kpfleming for 7 years of awesome. |
| 07:12.51 | *** join/#asterisk-dev jmls1 (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 08:28.22 | *** join/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 08:31.27 | *** part/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 08:43.44 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:43.44 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:43.56 | *** join/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 08:58.14 | *** join/#asterisk-dev irroot (~gregory@41.79.221.226) |
| 08:59.19 | *** part/#asterisk-dev irroot (~gregory@41.79.221.226) |
| 09:26.16 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5d7b:fdf7:79fe:7ffb) |
| 10:25.31 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 11:20.44 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 11:34.28 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:16.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xixjghemosqmskjb) |
| 12:16.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:27.38 | mjordan | leifmadsen: 200 OK |
| 12:28.00 | leifmadsen | mjordan: howdy! was looking at this page this morning, and was thinking 1) is there a page that deprecates this? if not, then 2) I think we can probably just remove the modules and support levels (as of Asterisk 1.8) section: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States |
| 12:28.07 | leifmadsen | mjordan: ACK. |
| 12:28.25 | mjordan | nope, that page is still the standard |
| 12:28.30 | mjordan | so we don't have anything to replace it |
| 12:28.42 | mjordan | but yeah, the "as of Asterisk 1.8" text could be removed |
| 12:28.46 | leifmadsen | gotcha, ok, I think it could be cleaned up -- might do that if I can find some free time :S |
| 12:28.52 | leifmadsen | I'll start with that much anyways |
| 12:28.59 | mjordan | or I'll throw it at Rusty's ever expanding pile of stuff |
| 12:29.58 | leifmadsen | I've removed that section at least |
| 12:30.37 | leifmadsen | it coudl probably use a review, as that page was originally created in order to document what we wanted in menuselect, but since it's in there now, it probably needs to be refreshed to match up with reality, rather than what the future should look like, since the future is now! |
| 12:31.41 | leifmadsen | Menuselect display should either be removed, or updated to reflect what it actually looks like (my opinion, just remove it). The adding new metadata makes sense, but should probably be updated as well. |
| 12:31.54 | leifmadsen | to actually show a real example of how to configure/add/change it in the module |
| 12:32.03 | leifmadsen | yada yada yada |
| 12:32.14 | leifmadsen | and with that, I'm going back to writing up a keymap of voicemail |
| 12:34.04 | mjordan | ew |
| 12:34.08 | mjordan | voicemail. |
| 12:34.41 | leifmadsen | ya :) |
| 12:35.39 | mjordan | btw: did you see voicemails now have unique IDs? |
| 12:36.22 | leifmadsen | I did not! |
| 12:36.28 | leifmadsen | (they didn't before? :)) |
| 12:36.44 | leifmadsen | what does a uniqueID get me? |
| 12:39.40 | mjordan | well, not a lot |
| 12:39.41 | mjordan | :-P |
| 12:40.04 | mjordan | depends. There's now a new application that lets you play any voicemail message in a mailbox if you know the ID |
| 12:40.10 | mjordan | and the IDs are stored in the message envelope file |
| 12:40.26 | mjordan | and if the voicemails get reordered (in case someone deletes the third one, for example), the IDs stay the same |
| 12:40.52 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 12:46.54 | leifmadsen | nice |
| 12:47.43 | leifmadsen | sounds like 1) programmatic interfaces into voicemail (AMI?) could potentially retrieve/manage voicemail outside of voicemail (maybe?) 2) at least it seems like it might fix all those bugs around reordering and all the hacks required to make it work |
| 12:52.56 | mjordan | leifmadsen: its a step in that direction |
| 12:52.57 | mjordan | hm. |
| 12:53.00 | leifmadsen | heh |
| 12:53.01 | mjordan | I'm not sure about removing the modules. |
| 12:53.05 | leifmadsen | oh? |
| 12:53.08 | mjordan | I agree that it will never stay up to date |
| 12:53.19 | mjordan | but that page is where we push people to when we have to explain their module is extended versus core |
| 12:53.21 | mjordan | or deprecated |
| 12:53.21 | leifmadsen | all the data is in menuselect so.... |
| 12:53.34 | leifmadsen | ya, but you're already 2 major versions behind :) |
| 12:53.45 | mjordan | mostly because it didn't change a lot |
| 12:53.48 | mjordan | yes, there are a few new modules |
| 12:54.04 | leifmadsen | giving outdated info seems worse than no data at all.... |
| 12:54.06 | leifmadsen | imho |
| 12:54.22 | mjordan | yeah, I can understand that. We can try for this approach and see what happens |
| 12:54.44 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 13:00.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-gbnzebxqnevsgajp) |
| 13:01.40 | leifmadsen | mjordan: going back to voicemail -- if messages can be added/deleted/moved from externally, that'd be awesome, because then someone could just write an AGI or something for a better voicemail application :) |
| 13:02.37 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:02.38 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:08.17 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:08.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:18.31 | kpfleming | leifmadsen: they could write a python script using ExternalIVR and pretty much replace app_voicemail now |
| 13:18.51 | leifmadsen | kpfleming: ah that's a true story |
| 13:19.00 | leifmadsen | I'd use ruby |
| 13:19.04 | leifmadsen | :) |
| 13:19.26 | leifmadsen | maybe someone should do that, and then we could just deprecate app_voicemail |
| 13:19.33 | leifmadsen | places tongue in cheek |
| 13:19.41 | kpfleming | there's a long weekend coming up in the US, someone should do it |
| 13:19.46 | kpfleming | but not me, i'm moving |
| 13:19.48 | leifmadsen | kpfleming: Canada too |
| 13:19.54 | leifmadsen | and not me, I'm going to the cottage |
| 13:19.55 | kpfleming | what's the holiday up there? |
| 13:19.57 | leifmadsen | and riding the seadoo |
| 13:20.02 | leifmadsen | kpfleming: Labour Day |
| 13:20.05 | kpfleming | oh |
| 13:20.10 | leifmadsen | same holiday |
| 13:20.19 | leifmadsen | but with more U's |
| 13:20.20 | kpfleming | hey, Gogo has announced they are going to start doing in-flight internet in Canada soon |
| 13:20.36 | leifmadsen | ya heard a few providers are going to be doing that in Canada now |
| 13:20.42 | leifmadsen | I think the CRTC is going to allow it now |
| 13:20.51 | leifmadsen | (or whoever was regulating that) |
| 13:20.57 | leifmadsen | read something like that |
| 13:21.16 | kpfleming | it works really well, i've been quiet impressed |
| 13:21.21 | leifmadsen | nice |
| 13:21.25 | leifmadsen | never had a chance to try |
| 13:21.35 | kpfleming | or... quite |
| 13:21.43 | kpfleming | but i was usually quiet too |
| 13:23.10 | mjordan | quite quiet? |
| 13:23.57 | leifmadsen | I'll just throw this out there: If anyone has a lot of experience with AMI integration, the CoreDial team is looking for a consultant to work with to help analyze some issues they are having. Please contact me via /msg. |
| 13:26.42 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1003) |
| 13:26.42 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:27.36 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1005) |
| 13:27.36 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:30.27 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1005) |
| 13:30.27 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 13:31.56 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:31.56 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:39.25 | *** join/#asterisk-dev peppux (~peppux@dynamic-adsl-78-12-148-130.clienti.tiscali.it) |
| 13:39.27 | peppux | hi |
| 13:39.41 | pabelanger | well hello there |
| 13:40.26 | peppux | im trying to recompile asterisk, but i don't see any changes! it's only make, true? |
| 13:41.14 | pabelanger | What changes are you expecting to see? |
| 13:41.14 | putnopvut | You'll also need to 'make install' before re-running Asterisk. |
| 13:41.28 | pabelanger | Ah |
| 13:41.36 | pabelanger | And restart asterisk if it is already running |
| 13:42.38 | peppux | putnopvut: asterisk must be stopped before recompiling? |
| 13:43.09 | putnopvut | You can recompile with Asterisk running. After you recompile and make install, you will have to stop and start Asterisk in order to see the changes. |
| 13:44.42 | peppux | mmm, nothing :S |
| 13:46.46 | peppux | oh, now it's ok :) |
| 13:47.41 | peppux | thanks guys |
| 13:50.07 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 13:50.53 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1005) |
| 13:50.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:58.46 | *** join/#asterisk-dev leedm777 (~Adium@nat/digium/x-onssxdoihsntzgax) |
| 14:03.35 | pabelanger | leedm777: working on asterisk now? Seen your commit the other day |
| 14:03.53 | leedm777 | pabelanger: yeah; getting into it a bit. |
| 14:04.02 | pabelanger | leedm777: \o/ |
| 14:04.51 | tzafrir_laptop | peppux, or you can use 'core restart' (restart now, whatever) from the CLI |
| 14:05.12 | tzafrir_laptop | In case you only changed a single module, unloading it and loading it may do the trick |
| 14:07.52 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 14:09.21 | peppux | tzafrir_laptop: thanks :) |
| 14:15.03 | pabelanger | Just updated the Asterisk 11 configuration files thread, check it out and vote which naming scheme we want for new modules |
| 14:15.05 | pabelanger | that is all |
| 14:15.41 | kpfleming | klingon gets my vote |
| 14:17.40 | *** join/#asterisk-dev GameGamer43 (users.5533@id-5533.hampstead.irccloud.com) |
| 14:18.21 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-94-17.user.veloxzone.com.br) |
| 14:23.01 | *** join/#asterisk-dev Devon_ (~chatzilla@63.214.236.169) |
| 14:32.14 | jmls | _really_ struggling with mixmonitor and audiohooks_inherit |
| 14:32.43 | jmls | surely parking a call shouldn't stop the recording ? |
| 14:33.03 | jmls | (I know that it depends on the channel being recorded) |
| 14:33.17 | jmls | but what is the point of audiohooks_inherit ? |
| 14:35.44 | anonymouz666 | keeps mixmonitoring if you transfer let's say to an extension that does not call mixmonitoring(). |
| 14:36.33 | jmls | anonymouz666: that's the point. it doesn't :( |
| 14:37.06 | jmls | if the source channel goes away (transfer, parking) then mixmonitor stops |
| 14:37.17 | anonymouz666 | source channel is another thing. |
| 14:37.45 | jmls | so if I use parking, I can't record calls ? |
| 14:38.22 | jmls | well, I can, just part of the call :( |
| 14:39.11 | anonymouz666 | In my case, the user call a customer. its mixmonitoring. then the user need to transfer the call (source channel). We use flags in the dial when trasferring to call MixMonitor again using the macro option. |
| 14:50.47 | jmls | what happens with parking ? |
| 14:52.01 | jmls | how hard would it be to stop mixmonitoring only if *both* legs have hung up ? |
| 14:52.38 | mjordan | jmls: hard? |
| 14:53.03 | jmls | bugger. |
| 14:53.28 | mjordan | mixmonitor works by having audiohooks on a channel. Its specific to the channel that the mixmonitor application was run on. It isn't necessarily aware of the channel that the channel its hooked onto is bridged to - its simply recording the inbound/outbound audio on the channel |
| 14:54.16 | jmls | <PROTECTED> |
| 14:54.40 | mjordan | hence why the audiohook_inherit function is needed - it does some things to pass the mixmonitor audiohook onto a descendent channel - but that still isn't any arbitrary channel. |
| 14:55.00 | jmls | what's a descendent channel ? |
| 14:55.11 | mjordan | jmls: sure, but that's kind of like saying "hey, it has a pointer, just make the audiohook pointer something different". it'll be very easy to get that wrong |
| 14:55.57 | mjordan | jmls: interpreting the documentation - something that masquerades into the channel that the audiohook was originally set on. Which is what happens during a transfer. |
| 14:56.42 | jmls | that's what is confusing me ;) |
| 14:57.07 | mjordan | jmls: you're in good company. Masquerades are non-trivial :-) |
| 14:57.17 | jmls | if the source channel is transferred , then mixmonitor stops, regardless of audiohooks_inherit |
| 14:57.41 | jmls | but if the target channel is transferred / parked, then mixmonitor continues |
| 14:57.54 | jmls | so why need the audiohooks_inherit ? |
| 14:57.58 | jmls | is it for local channels ? |
| 14:58.06 | jmls | (optimising them out) |
| 14:58.17 | mjordan | jmls: it has applications there, but no. https://wiki.asterisk.org/wiki/display/AST/Function_AUDIOHOOK_INHERIT |
| 15:01.16 | jmls | mmm. ok. if audiohooks_inherit works, why couldn't the source channel pass the inheritance to the other channel before it hangs up after a transfer / park ? |
| 15:02.06 | jmls | ohh -does the placement of the Set(AUDIOHOOK_INHERIT()) matter ? |
| 15:02.14 | jmls | I have it *before* the mixmonitor |
| 15:02.31 | leifmadsen | I think it matters which channel it is run on at least |
| 15:03.19 | mjordan | jmls: based on the example, you may want to try to run it after the MixMonitor app call. I haven't looked at the audiohook inherit code, so I can't answer that off the top of my head. |
| 15:03.33 | jmls | goes away to have a look |
| 15:03.38 | jmls | thanks |
| 15:06.11 | jmls | dammit. no change :'( |
| 15:06.33 | jmls | so, following the logic on https://wiki.asterisk.org/wiki/display/AST/Function_AUDIOHOOK_INHERIT |
| 15:07.03 | jmls | A calls 2000. 2000 parks / xfers, call recording continues |
| 15:07.18 | jmls | A calls 2000, A parks / xfters, it stops |
| 15:07.53 | mjordan | does A park 2000, or is A put into the parking lot? |
| 15:08.15 | jmls | second scenario, A parks itself |
| 15:08.31 | mjordan | k. What happens when A comes out of the parking lot? |
| 15:08.55 | jmls | doesn't matter - as soon as A is parked, mixmonitor stops |
| 15:09.21 | jmls | (and doesn't resume ;) ) |
| 15:09.56 | mjordan | so it stops while A is on park. And it does not resume when A comes out of park and is re-bridged, or when they resume in some portion of the dialplan |
| 15:10.03 | jmls | yup |
| 15:10.24 | mjordan | forgetting parking for a second, does the mixmonitor continue if A is transferred? |
| 15:10.32 | jmls | tries. |
| 15:10.34 | jmls | wait |
| 15:11.35 | jmls | yup, it also stops |
| 15:30.26 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 15:32.31 | jmls | gotta run for a bit. got a wall to demolish ;) |
| 15:34.08 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:40.33 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 15:40.33 | *** join/#asterisk-dev leedm777 (~Adium@nat/digium/x-onssxdoihsntzgax) |
| 15:40.33 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 15:40.33 | *** mode/#asterisk-dev [+o tzafrir_laptop] by hubbard.freenode.net |
| 16:36.44 | tzafrir_laptop | What's up with svnview? |
| 16:37.01 | tzafrir_laptop | ah. all's well |
| 16:42.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:42.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:56.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:56.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:07.01 | *** join/#asterisk-dev Tim_Toady (~fuzzy@193.92.239.195.dsl.dyn.forthnet.gr) |
| 18:25.14 | pabelanger | 100 new issues in that last 30 days on JIRA |
| 18:28.04 | leifmadsen | O. |
| 18:28.05 | leifmadsen | O |
| 18:28.09 | leifmadsen | fail. |
| 18:29.41 | putnopvut | Thank you for the commentary |
| 18:30.05 | pabelanger | USA, USA |
| 18:32.09 | acidfoo | we had Mark for lunch here :) |
| 18:33.47 | putnopvut | RIP Mark |
| 18:34.07 | acidfoo | we ate with him, not him ;) |
| 18:34.10 | putnopvut | oh |
| 18:34.47 | acidfoo | english isn't my first language ;) |
| 18:35.38 | acidfoo | in french it make perfect sense to have someone for lunch ;P |
| 18:38.28 | opticron | acidfoo, it makes sense in english too but it's just fun to read things incorrectly :) |
| 18:41.37 | acidfoo | I see ;) |
| 18:43.25 | leifmadsen | acidfoo: what you said is common, but it can be subtly interpreted as being eaten :) |
| 18:46.41 | acidfoo | ;) |
| 18:47.07 | acidfoo | what is the more formal way to say the same thing ? |
| 18:47.30 | Qwell | "we had Mark here for lunch" |
| 18:47.35 | Qwell | but then "Mark here" could be referring to putnopvut |
| 18:48.03 | acidfoo | ah |
| 18:48.04 | Qwell | (as in, "This is the Mark we ate for lunch") |
| 18:48.04 | jsmith | "We had Mark join us for lunch" |
| 18:48.10 | jsmith | "We had Mark here during lunch" |
| 18:48.20 | jsmith | Lots of different ways of saying it |
| 18:48.23 | acidfoo | I meant spencer not michelson ;) |
| 18:48.41 | acidfoo | I didn't realised that putnopvut name was mark ;) |
| 18:50.17 | putnopvut | I've gotten used to the fact that if someone in the Asterisk community or at Digium says "Mark" they don't mean me. |
| 18:50.25 | opticron | heh |
| 18:50.44 | acidfoo | putnopvut, hehehe :) |
| 18:50.56 | opticron | luckily for me, Kinsey is pretty unique |
| 18:54.19 | jmls | ok, like I have a couple of "internals" questions to ask before I ask the really big question that may^h^h^hwill make me look _really_ stupid .... |
| 18:55.21 | acidfoo | <leifmadsen> "There are no stupid questions, just stupid people." |
| 18:55.22 | acidfoo | ;) |
| 18:55.25 | jmls | grabs a cold beer |
| 18:55.31 | leifmadsen | heh |
| 18:55.35 | leifmadsen | jmls: I like your hustle |
| 18:55.39 | jmls | oh crap. |
| 18:55.44 | leifmadsen | jmls: going to astricon this year? |
| 18:55.49 | jmls | nope |
| 18:55.54 | jmls | one day. |
| 18:56.01 | leifmadsen | jmls: damn, I was going to buy you 10 beers too |
| 18:56.21 | jmls | bugger |
| 18:56.25 | Qwell | woah, I want 10 beers |
| 18:56.35 | jmls | Qwell: you can have mine :) |
| 18:56.47 | jmls | see, I'm generous too. |
| 18:56.50 | leifmadsen | Qwell: I will buy you as many beers as they stack to your height |
| 18:57.15 | Qwell | Do I get to bring my own glasses? |
| 18:57.15 | jmls | A) why do we/you smart people masquerade a channel |
| 18:57.25 | leifmadsen | Qwell: no, bottles of beer |
| 18:57.31 | jmls | A=question A, not A) as in Answer |
| 18:57.34 | Qwell | Do I get to pick the bottles? |
| 18:57.38 | leifmadsen | Qwell: no |
| 18:57.40 | Qwell | Mickeys, yo |
| 18:57.42 | Qwell | damn |
| 18:57.47 | leifmadsen | ya I know that trick :D |
| 18:57.50 | Qwell | :D |
| 18:57.56 | leifmadsen | or Red Stripe |
| 18:58.13 | Qwell | no thanks |
| 18:58.26 | Qwell | still, 5 ft of beer... |
| 18:58.49 | jmls | we still have yards of ale in certain pubs over here |
| 18:59.01 | leifmadsen | how tall is a beer.... like 8" ? |
| 18:59.50 | jmls | http://www.drinkstuff.com/products/product.asp?ID=126 |
| 19:00.17 | acidfoo | ask him to pile kegs ;) |
| 19:00.29 | Qwell | acidfoo: sideways |
| 19:00.34 | acidfoo | heheh |
| 19:00.36 | Qwell | like a big triangle :P |
| 19:00.51 | acidfoo | we are going in the right direction I think ;) |
| 19:01.04 | jmls | wonders why the conversation always takes the wrong turn when he gets involved .. |
| 19:01.56 | jmls | so, question A) ? |
| 19:03.03 | acidfoo | erm, when we do a transfer ? |
| 19:03.09 | acidfoo | A->B->C |
| 19:03.15 | opticron | also, local channel optimization |
| 19:03.17 | acidfoo | A->C |
| 19:03.48 | opticron | rmudget knows all about that :) |
| 19:04.11 | jmls | ok, so A -> B. A wants to transfer B to C, puts B on hold, calls C. transfers to C |
| 19:04.24 | jmls | or even does a blind xfer |
| 19:04.51 | jmls | masqerades are messy, right ? |
| 19:05.00 | opticron | yes |
| 19:05.24 | opticron | and not to be trifled with |
| 19:05.32 | jmls | B) and have been there for a loooonng time |
| 19:06.01 | opticron | with the current architecture of Asterisk, they are a necessary evil for certain operations |
| 19:06.13 | jmls | yah. stop stealing my thunder |
| 19:06.28 | jmls | hopes that the thunder is not a small fart |
| 19:06.40 | jmls | :-D |
| 19:06.51 | opticron | you can have all the thunder and rain you want |
| 19:06.56 | jmls | heh |
| 19:07.38 | jmls | C) the problem I'm having with mixmonitor is that it is terminated when the channel it's attached to dies |
| 19:07.57 | jmls | by a transfer, park etc |
| 19:08.50 | jmls | how resource intensive is the new confbridge ? |
| 19:10.14 | opticron | the only think I know performance-wise is that meetme is in-kernel while confbridge is not, but confbridge might have other optimizations available to it because of that |
| 19:10.35 | opticron | has no data about running it in production |
| 19:10.40 | jmls | ok, time for the real dumb question |
| 19:14.50 | opticron | waits intently |
| 19:14.58 | jmls | is typing a novella |
| 19:15.34 | jmls | why can't we make every "call" a "conference" using a very special cut-down version of confbridge ? ie. when dialling, the A channel is put into a conference. when B answers, it's also put into the conference. If you want to record the entire conversion, record the conference. chanspy could also change to "listen" to the conference. A "transfer" would remove A from the conference, but add C. "parking" the call would simply |
| 19:15.56 | jmls | iow, make the conference the call - attach and detach channels at will |
| 19:16.29 | jmls | ducks and runs |
| 19:17.21 | Qwell | a lot of stuff would have to start using the (existing..) bridging API. It may be brought up at astridevcon. |
| 19:17.49 | Qwell | transfers and other stuff is a bit different though |
| 19:17.54 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-38-44.user.veloxzone.com.br) |
| 19:18.16 | jmls | only because at the moment , the channel is king |
| 19:19.35 | anonymouz666 | sruffell: when you don't have VPM module, the HWEC in the output of 'dahdi_cfg -vv' should be displayed? that makes me confused |
| 19:19.38 | putnopvut | I was about to comment on that configuration file thread, but then I realized I don't care enough to. |
| 19:20.12 | marv | If someone asked me what one "feature" of asterisk caused me the most headaches, it would be channel masquerades. |
| 19:20.46 | russellb | not a feature |
| 19:20.48 | sruffell | anonymouz666: hmm…I know what you mean. It's a leaky abstraction since there is always a "hwec factory" available in the core of DAHDI that's used when a span actually has hwec available. I agree it should be fixed. Want to open a JIRA issue or shall I? |
| 19:20.56 | russellb | it's an implementation detail ... |
| 19:20.58 | jmls | let's take an attended transfer. A dials B, both in conference 1. A presses transfer. A is removed from conference 1 . A dials C, creates a new conference 2 which joins A and C. when A hangs up, C is removed from conference 2 and added to conference 1. no masquerades needed, surely ? |
| 19:21.27 | russellb | though I suppose it gets leaked to users in a few places (when you see a channel become a zombie) |
| 19:21.43 | marv | and when the channel's uniqueid changes |
| 19:21.50 | jmls | we *know* it's a transfer - we know that A was in conference 1, so it would be "easy" to tell C which conference to join when A hangs up |
| 19:22.21 | jmls | the uniqueid would be the conference , not the a leg or b leg |
| 19:22.22 | russellb | marv: ugh, yeah, that's screwy |
| 19:24.00 | marv | jmls: you can't just change who you're bridged too. Think of an attended transfer to app_queue. No one is bridged, but you need to change which channel is waiting in the queue, perhaps in the middle of playing a "you are next in line" message |
| 19:24.03 | anonymouz666 | sruffell: please, open. I am little busy right now debugging echo issues :-) |
| 19:24.20 | putnopvut | jmls: you've oversimplified things. A doesn't get removed from the conference. To Asterisk, the new call from A to C is just that. A new call. We can't tell that it's part of a transfer until after A hangs up and a SIP REFER or INVITE with Replaces arrives. |
| 19:24.37 | sruffell | anonymouz666: ok, will do |
| 19:25.00 | putnopvut | In Asterisk's view, there are four channels. A1, B, A2, C. A1 and B are bridged, and A2 and C are bridged. The masquerade causes C to take A1's place and be merged with B. |
| 19:25.41 | jmls | when the xfer button is pushed by A, B goes on hold - so B must know that something is afoot |
| 19:25.45 | putnopvut | Unfortunately, when you first press the transfer button on A, there is no "transfer" SIP message sent from your phone. It's exactly the same as putting B on hold. |
| 19:27.33 | jmls | right. so when we get the REFER/INVITE why can't it be sent to the conference that A was in ? |
| 19:28.08 | putnopvut | what is "it" In that sentence? |
| 19:28.17 | jmls | I presume C :) |
| 19:28.36 | marv | C might not even exist |
| 19:29.07 | jmls | if C doesn't exist, how did an xfer take place ? |
| 19:29.16 | putnopvut | Transfer to an IVR |
| 19:29.20 | putnopvut | Or Voicemail |
| 19:29.22 | putnopvut | or something similar |
| 19:29.25 | jmls | still a channel, though ? |
| 19:29.27 | putnopvut | nope |
| 19:29.32 | jmls | oh :* |
| 19:30.42 | jmls | well, if that's the case, then we must know if it's a proper channel or not, and take appropriate action with C |
| 19:31.52 | jmls | oh well. it was just an idea from someone who doesn't really know internals. but then sometimes, that works ;) |
| 19:31.59 | marv | I would think you would have to change every application to handle an event of type "newchannel" that says you know that channel you were passed? well, stop using that, use this new one now. |
| 19:32.26 | jmls | yeah. not an easy task. but so much benefits :-/ |
| 19:32.28 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 19:32.28 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:32.48 | jmls | ok, back to reality |
| 19:33.01 | jmls | that doesn't look right |
| 19:33.18 | jmls | looks like I'm looking for a real estate agent |
| 19:33.38 | jmls | mjordan: perchance any more thoughts on the mixmonitor issue ? |
| 19:34.59 | jmls | what would happen if I were to use non-optimised local channels ? |
| 19:35.26 | jmls | A calls B : A creates a local/n channel, which calls a local/n channel which calls B |
| 19:35.58 | jmls | if A parks itself, which of the 2 channels are actually parked ? A or A/local/n ? |
| 19:40.59 | putnopvut | I'm thinking about this. How does A park himself? |
| 19:42.19 | marv | Big K flag to Dial would allow this. Or something custom with features. Why would A want to park himself might be a good question though. |
| 19:42.31 | jmls | sorry, I meant A presses the park button |
| 19:42.39 | jmls | ie puts B on park |
| 19:42.56 | jmls | therefore hangs up A |
| 19:43.05 | jmls | poof! mixmonitor stops |
| 19:43.15 | jmls | even though B is simply parked |
| 19:43.58 | putnopvut | Okay, so the question is, does a masquerade occur when B gets parked. It's masquerades that trigger the inheritance of AUDIOHOOK_INHERIT. |
| 19:44.30 | putnopvut | And unfortunatley, I don't know off the top of my head. I'll have a look at parking code to see. |
| 19:45.44 | marv | Since A is the A leg of the call that a thread runs on, I think a masq has to happen to get B out of app_dial. If B were parking A (which I think is more common) then asterisk might remove A from app_dial with a soft hangup. |
| 19:46.52 | putnopvut | The other question is the direction of the masquerade. |
| 19:47.20 | jmls | either parking or xfering would cause MM to hang up. A->B with mixmonitor on A. anything that causes A to hangup (parking B or xfer/blindxfer to c) stops MM |
| 19:47.23 | putnopvut | For instance, if a channel gets masqueraded into channel A's structure, then AUDIOHOOK_INHERIT will do no good |
| 19:48.07 | putnopvut | Right, that's another case where masquerade direction affects the usefulness of AUDIOHOOK_INHERIT. |
| 19:48.16 | marv | I *think* a brand new channel would be created and B would be masqueraded into that, just to remove it from the clutches of app_dial |
| 19:48.25 | putnopvut | Try doing the other transfer: B transfers A with AUDIOHOOK_INHERIT set. Mixmonitor should continue working in that case. |
| 19:48.35 | jmls | putnopvut: yup. it does |
| 19:49.06 | jmls | that's why I'm frustrated. why can't it work the other way round as well ? |
| 19:50.07 | putnopvut | That's a good question, to be honest. |
| 19:50.26 | putnopvut | Datastores, for instance, stack on a masquerade. IN other words, the masqueradee doesn't lose its datastores. |
| 19:50.47 | putnopvut | But audiohooks are different. It may be because presumably the channel that the audiohook depends on is going away. |
| 19:51.20 | jmls | ideally, mixmonitor should not be attached to a channel, but behave like a conference recording, it doesn't matter which channels join or leave. When there are no channels connected, stop the MM |
| 19:51.20 | putnopvut | looks at audiohook internals |
| 19:51.58 | putnopvut | jmls: yes, ideally, Asterisk wouldn't be so channel centric. |
| 19:52.03 | putnopvut | It would be bridge-centric. |
| 19:52.07 | jmls | woot! |
| 19:52.22 | jmls | so my idea wasn't so off-base :) |
| 19:52.49 | putnopvut | THere's a fantastic bridging API in Asterisk that would be great if used all over. Unfortunately, it's only used for app_confbridge and app_page at the moment, I believe. |
| 19:53.00 | jmls | smug Mode well and truly engaged |
| 19:53.28 | putnopvut | I'm of the opinion that any call should have a bridge, no matter the number of channels involved. It's much easier to track a "call" that way. Then channels can be added and removed from the bridge as necessary. |
| 19:53.36 | jmls | yes! yes! |
| 19:53.55 | jmls | you just put it so much better ;) |
| 19:54.09 | jmls | the bridge is the call |
| 19:54.20 | marv | putnopvut: so would applications be called on (possibly single party) bridges instead of channels? |
| 19:54.51 | putnopvut | marv: Possibly. It may depend on the application in question. |
| 19:55.07 | putnopvut | Like Set() would probably set per-channel data still. |
| 19:55.39 | jmls | setting an __x variable should be on the bridge |
| 19:55.44 | marv | IMO Set should be a function and not an app (actually I think it's both) |
| 19:55.52 | putnopvut | Yep, there's a SET function |
| 19:55.57 | Qwell | marv: But how wuold you call it? |
| 19:55.59 | Qwell | would* |
| 19:56.25 | putnopvut | You could always noop it (ugly) |
| 19:56.29 | jmls | urgh |
| 19:58.43 | marv | That's because all you can do in dialplan is run applications, there's no way to run a function except through an application. |
| 19:59.38 | jmls | trolls |
| 19:59.55 | jmls | what is the philosophical difference between an app and a function ? |
| 20:00.11 | jmls | and does it really matter ? |
| 20:01.51 | marv | I'm not sure what it is officially. In my mind, an app runs on the channel's thread, it's what the channel does, and can do things like bridging. Functions don't all even require a channel. Some do. You can run functions on a channel from the manager while that channel is in an application without disturbing it. |
| 20:03.33 | jmls | app NoOp does nothing on the channel ;) |
| 20:03.56 | jmls | neither does Verbose() |
| 20:04.09 | marv | Keep in mind, originally functions didn't exist |
| 20:04.20 | jmls | told you, I was trolling ;) |
| 20:04.25 | Qwell | marv: heck, variables were a new invention at one point |
| 20:04.33 | Qwell | BYEXTENSION, anyone? |
| 20:04.42 | jmls | asterisk was a new invention at one point |
| 20:05.15 | jmls | what was the version in 2004 ? 1.0 ? |
| 20:07.28 | marv | right, all i'm saying is that even if my philosophy is what others were following, NoOp would continue to exist for backward compatibility. |
| 20:26.38 | *** join/#asterisk-dev spditner (~simon@206-248-134-196.dsl.teksavvy.com) |
| 20:40.54 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 20:59.29 | russellb | 1.0 was released in the Fall of 2004 |
| 20:59.37 | russellb | at the first astricon |
| 21:27.32 | Corydon76-work | jrose_atDigium: did that make sense? |
| 21:27.40 | jrose_atDigium | yes |
| 21:28.04 | jrose_atDigium | I was thinking along the same lines really |
| 21:28.05 | Corydon76-work | All the good words were taken |
| 21:28.48 | jrose_atDigium | remote and console were taken. That left one good acronym though :P 'rc set verbose' |
| 21:29.05 | Corydon76-work | Remote wasn't taken, but it sounds weird |
| 21:29.10 | jrose_atDigium | oh right |
| 21:29.21 | jrose_atDigium | it does |
| 21:29.34 | jrose_atDigium | But yeah |
| 21:29.46 | jrose_atDigium | I think reading the aliases to see if any of them match is a fine approach. |
| 21:30.12 | jrose_atDigium | And since we are in feature freeze on 11, it probably isn't appropriate to be changing the names of commands anyway. |
| 21:30.41 | Corydon76-work | The only possibly weird thing is that if you change the aliases without reloading asterisk, but then start up a remote console, it's still possible to get what Tim described |
| 21:31.40 | Corydon76-work | Because in essence, you'll be dealing with two different alias files |
| 21:31.55 | Corydon76-work | but that's an extreme corner case |
| 21:33.34 | marv | Ah, Ii see you all are working on the bug I reported. |
| 21:33.50 | Corydon76-work | Indeed |
| 21:34.19 | jrose_atDigium | Are aliases reread/repopulated when just connecting a remote console? |
| 21:34.31 | jrose_atDigium | I didn't think that would be the case. |
| 21:34.38 | Corydon76-work | That's what I suggested for the fix |
| 21:34.40 | jrose_atDigium | I'll have to test that. |
| 21:34.59 | Corydon76-work | Not in the core, but in the remote |
| 21:35.18 | jrose_atDigium | I was under the impression you were just saying to use the existing aliases to convert the command received into the command mapped. |
| 21:35.40 | Corydon76-work | Correct, but that happens before the remote communicates the command to the core |
| 21:36.09 | Corydon76-work | Unless you have a command to resolve a command to its canonical form without actually executing it |
| 21:36.31 | jrose_atDigium | I think I get what you mean now. This is slightly more awkward than I was thinking. |
| 21:37.07 | Corydon76-work | We do have some weird commands like that already. They're used to do tab completion on the remote consoles |
| 21:37.17 | jrose_atDigium | Makes sense. |
| 21:38.19 | Corydon76-work | You could do such a command, but you'd probably need to filter the response in some way so that it wasn't displayed |
| 21:39.10 | Corydon76-work | And secondarily, if someone changed the aliases and did a reload in the core, you'd need the new command to come back out to the remote consoles, for consistency |
| 21:39.11 | tzafrir_laptop | The commit message of AST-2012-012 mentions that the "originate" AMI priv is basically pointless, right? |
| 21:39.43 | Qwell | tzafrir_laptop: pretty much. |
| 21:39.56 | jrose_atDigium | Well, more to the point if you give someone originate, there is a good chance you've inadvertantly given them permission to do horrible things. |
| 21:39.59 | Corydon76-work | tzafrir_laptop: it's not pointless in terms of using it as intended. |
| 21:40.03 | tzafrir_laptop | Maybe it's a matter of whitelisting setenv? |
| 21:40.06 | Corydon76-work | tzafrir_laptop: just in terms of security |
| 21:40.18 | Qwell | tzafrir_laptop: There are dozens of ways we thought of to exploit it. |
| 21:40.28 | mjordan | tzafrir_laptop: when we sat around and starting thinking of ways to break the system than yes what Qwell said |
| 21:40.43 | tzafrir_laptop | Any way that does not involve sneaking data htrough setenv? |
| 21:40.48 | mjordan | it got ridiculous. The solutions would have basically resulted in "remove all shell like commands" |
| 21:41.11 | tzafrir_laptop | mjordan, some variables are used explicitly |
| 21:41.25 | tzafrir_laptop | err... implicitly |
| 21:41.27 | Corydon76-work | mjordan: which is essentially what we'd previously attempted to do |
| 21:41.53 | tzafrir_laptop | sudo can whitelist variables |
| 21:54.04 | *** join/#asterisk-dev Ta^3 (~tacvbo@fixed-203-101-206.iusacell.net) |
| 22:00.07 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xixjghemosqmskjb) |
| 22:54.11 | tzafrir_laptop | So, any way to bypass the originate limitation not involving setenv? |
| 22:55.58 | *** join/#asterisk-dev italorossi (~Adium@187.61.182.39) |
| 22:58.02 | Ta^3 | Hi!, can anyone point me out how to proceed on this? I'm testing trunk and I |
| 22:58.14 | Ta^3 | think that the (new) way that pbx/pbx_config.c uses the new 'missing context feature' from apps/app_stack.c behaves in a way that you can only create the |
| 22:58.35 | Ta^3 | stdexten context and/or the 'usercontext' in extensions.conf syntax and not in AEL2/LUA being not able to arbitrarily set priorities. |
| 22:58.55 | Ta^3 | This is because pbx_config.c instead of create an extension with all the proper and old fashion Gosub options (context,extension,priority) it uses a |
| 22:59.07 | Ta^3 | ${EXTEN},stdexten({ARGS}) syntax wich leads you to necessarily add an include => stdexten to whatever it is 'usercontext' (default or whatever) |
| 22:59.40 | Ta^3 | because the missing context feature in app_stack.cs asumes that context =ast_channel_context(chan). Therefore, the new [stdexten] examples in extensions.conf adds a (stdexten) label inside [stdexten] context but also sets the priority to something aribitrary and pretty high, 50000 for [stdexten] and 60000 for [stdPrivacyexten] so in the case that you add a Return() you don't reach the 2d priority of the pbx_config.c generated 'userconte |
| 22:59.40 | Ta^3 | xt' |
| 22:59.55 | Ta^3 | wichs must have an include => stdexten that if it's coded in AEL2 will reach the second line in the extension part of the AEL2 written [stedexten] context/function. |