| 00:19.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.35) |
| 00:38.56 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:20.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.46) |
| 01:39.26 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 01:39.32 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:45.04 | *** join/#asterisk-dev suneye (~atcmmi@119.139.60.197) |
| 02:21.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 02:31.05 | *** join/#asterisk-dev dpeloquin (uid13057@gateway/web/irccloud.com/x-surugmpvjlnnftyh) |
| 02:40.01 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:22.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.49) |
| 03:36.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 03:40.32 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:22.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.45) |
| 04:41.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:23.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.57) |
| 05:41.43 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:24.19 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.53) |
| 06:42.16 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:57.42 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:59.24 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:25.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.46) |
| 07:36.11 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:36.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 07:42.47 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:09.41 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d8f4:d116:8ffa:6d3a) |
| 08:09.42 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:09.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:09.53 | oej | Morning folks |
| 08:10.54 | *** join/#asterisk-dev saghul (~saghul@15.83-213-189.dynamic.clientes.euskaltel.es) |
| 08:10.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.47) |
| 08:13.11 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-184-183-148-253.ph.ph.cox.net) |
| 08:34.07 | *** join/#asterisk-dev suneye (~atcmmi@119.139.60.197) |
| 08:43.17 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:58.55 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.57) |
| 09:01.21 | *** join/#asterisk-dev saghul (~saghul@15.83-213-189.dynamic.clientes.euskaltel.es) |
| 09:13.27 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:16.47 | *** join/#asterisk-dev BorjaGVO (d51beb92@gateway/web/freenode/ip.213.27.235.146) |
| 09:18.59 | BorjaGVO | Hi all. What does exactly Hangup cause 34 (AST_CAUSE_INVALID_MSG_UNSPECIFIED) means? |
| 09:23.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:72:ff8a:9fa:63b6) |
| 09:28.16 | bulkorok | BorjaGVO: http://networking.ringofsaturn.com/Routers/isdncausecodes.php |
| 09:31.15 | BorjaGVO | bulkorok: I understand that numbers correspond to the ones in Asterisk Hangup cause, right? |
| 09:31.36 | bulkorok | right |
| 09:31.52 | BorjaGVO | Thank you bulkorok |
| 09:32.55 | bulkorok | sure |
| 10:11.30 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 10:13.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 10:20.54 | *** join/#asterisk-dev Greenlight (wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginm.net) |
| 12:07.04 | *** join/#asterisk-dev tzafrir (~tzafrir@37.26.147.196) |
| 12:07.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:16.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.42) |
| 12:16.42 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 13:25.29 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:45.26 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:03.01 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-sbxrofkiyxayzatc) |
| 14:08.08 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:10.34 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:26.25 | *** join/#asterisk-dev saghul (~saghul@15.83-213-189.dynamic.clientes.euskaltel.es) |
| 14:29.41 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 14:44.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 14:44.43 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:44.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:45.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.69.245.162) |
| 15:08.21 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qaupemjliqmtlmfz) |
| 15:08.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:23.29 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:29.19 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-poddhfbskmqxhptz) |
| 15:44.29 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 15:53.27 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 16:23.04 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 16:23.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:35.25 | file | mjordan, oh! nudge |
| 16:40.29 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-bylzzscrovikjhck) |
| 16:45.02 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 16:45.02 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:58.09 | mjordan | file: apologies, but I'm about to disappear for an extended period :-P |
| 16:58.18 | file | oic |
| 16:58.29 | file | well, I think CDR is doing funky stuff with channels marked as internal :P |
| 16:59.03 | mjordan | yes it is. |
| 16:59.11 | mjordan | I shall need a question or a more concrete statement however |
| 16:59.15 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qaupemjliqmtlmfz) |
| 17:08.14 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:08.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:16.35 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:24.40 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-pzqaztufmcvkexoj) |
| 17:24.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:26.13 | file | mjordan, wb! |
| 17:27.29 | mjordan | file: so, CDRs and the joy of implementation detail channel drivers |
| 17:27.34 | mjordan | file: what did you run into? |
| 17:28.09 | file | mjordan, Snoop channels are marked as internal now but I noticed that when shutting down (long after the Snoop channel had been destroyed) that the CDR core finalized a CDR for it... |
| 17:28.17 | mjordan | hm. |
| 17:28.29 | mjordan | looks |
| 17:29.12 | mjordan | that is odd. |
| 17:29.18 | mjordan | filter_channel_cache_message should drop any updates from it. |
| 17:29.42 | mjordan | did you have a tech property of AST_CHAN_TP_INTERNAL? |
| 17:29.48 | file | yes. |
| 17:30.59 | mjordan | huh. |
| 17:31.05 | mjordan | Do you see a CDR for the channel? |
| 17:31.23 | mjordan | or is it the party b in someone else's CDR? |
| 17:31.48 | file | I think that looks like a CDR... |
| 17:32.18 | file | one sec |
| 17:33.44 | file | yup, there's a CDR |
| 17:33.44 | file | "","","s","default",""""" <>","Snoop/1384245813.0-00000000","","","","2013-11-12 08:43:45","2013-11-12 08:43:45","2013-11-12 08:43:56",10,10,"ANSWERED","DOCUMENTATION","1384245825.1","" |
| 17:33.46 | mjordan | hm |
| 17:33.48 | mjordan | phooey. |
| 17:33.58 | mjordan | That's an origination |
| 17:34.11 | mjordan | which makes sense. I wonder why it didn't get filtered. |
| 17:35.21 | file | that I can not answer but it makes me wonder if the other internal impl channels are doing the same... |
| 17:35.43 | mjordan | well, there was an error with filtering channel snapshots from Dial messages some time ago, but I fixed it. |
| 17:36.15 | mjordan | I will say this though... after filing that issue, I did have to wonder how we would know that SIP/foo is snooping on some other channel without knowledge of the Snoop channel |
| 17:36.53 | file | the answer is no - an announcer in a bridge does not create a CDR |
| 17:37.06 | mjordan | huh. |
| 17:37.21 | mjordan | are they originated? |
| 17:37.25 | file | ooo |
| 17:37.31 | file | I... have a thought. |
| 17:37.58 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 17:38.00 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 17:38.56 | file | mjordan, allocating a channel does not set the tech... and that does create and publish a snapshot |
| 17:39.06 | mjordan | eek |
| 17:39.13 | mjordan | that would do it |
| 17:39.23 | mjordan | I wonder why the announcer channels don't trigger it |
| 17:41.23 | file | that I do not have an answer to at this time. |
| 17:52.44 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 17:52.44 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 17:53.07 | mjordan | file: thinking about this some more however, I think I may have been wrong with the Snoop channels. |
| 17:53.25 | mjordan | There is use to knowing that SIP/bob is snooping on SIP/alice. |
| 17:53.33 | mjordan | The only way to know that is to have the Snoop channel represented. |
| 17:53.42 | file | well a channel never directly snoops on another channel... |
| 17:53.42 | mjordan | Otherwise, all you have is Snoop/bob in a bridge with no one |
| 17:53.44 | mjordan | right |
| 17:53.48 | file | aye. |
| 17:53.59 | mjordan | my picture of that should look like SIP/bob <B> ? SIP/alice |
| 17:54.01 | mjordan | without the Snoop cahnnel |
| 17:54.14 | mjordan | in reality, it is SIP/bob <B> Snoop/... SIP/alice |
| 17:54.23 | file | aye |
| 17:54.35 | mjordan | the question I have is - from a larger, conceptual, defining this kind of thing... how do you know Snoop/foo is snooping on Alice? |
| 17:55.11 | file | the way, right now but open to suggestions, you can tell is the name |
| 17:55.23 | file | Snoop channels have the uniqueid of the channel they are snooping on |
| 17:55.50 | mjordan | right, they are a child channel and should share the linkedid |
| 17:56.02 | mjordan | I hate that there isn't something more explicit however |
| 17:56.22 | file | wouldn't the linkedid get mucked with though if you start doing things with the Snoop channel? |
| 17:56.26 | mjordan | file: would it be worthwhile to refactor the existing ChanSpyStart/Stop events? |
| 17:56.29 | mjordan | probably |
| 17:56.42 | file | ummmm |
| 17:56.46 | mjordan | particularly when it joins the bridge with SIP/bob. It stands a chance to get updated, if SIP/bob is older than SIP/alice |
| 17:56.56 | file | yeah. |
| 17:57.05 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 17:57.33 | file | I can give a start event... |
| 17:57.53 | file | but Snoop does not (on purpose) have any reference to the channel on which it is spying |
| 17:57.55 | mjordan | it would be "nice" from an AMI client listening in |
| 17:58.03 | file | or whispering |
| 17:58.04 | mjordan | file: if it has the unique id |
| 17:58.12 | mjordan | it can get it from the cache. If not in the cache, don't send it |
| 17:58.19 | file | yes |
| 17:58.33 | mjordan | from an AMI perspective, it should be a spy start/stop |
| 17:59.02 | file | and just have spyer be the Snoop channel itself |
| 17:59.05 | mjordan | yup |
| 17:59.10 | file | yup yup |
| 17:59.11 | mjordan | it is the channel that is attached |
| 17:59.26 | mjordan | but I think I was wrong: it shouldn't be an internal detail |
| 17:59.36 | mjordan | otherwise you have no way of knowing that a snoop operation is occurring |
| 17:59.42 | mjordan | and you actually *do* want to know that. |
| 17:59.51 | file | hrm, that gets published on the spyer channel topic |
| 18:00.03 | file | (currently) |
| 18:00.04 | mjordan | that's ok |
| 18:00.06 | file | I find that interesting |
| 18:00.10 | mjordan | well |
| 18:00.12 | mjordan | yes. |
| 18:00.21 | mjordan | But currently the spyer is the one who initiates the chanspy |
| 18:01.03 | file | yeah, for AMI it doesn't really matter... for stasis users I'd just expect both since you may want to know that someone has suddenly started spying on your channel |
| 18:04.55 | mjordan | what does a Redirect do to a Snoop channel? |
| 18:05.07 | mjordan | (and what did you mean by both)? |
| 18:05.12 | file | redirects it? |
| 18:05.27 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 18:05.29 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 18:05.29 | file | both channel topics, spyer and spyee |
| 18:06.00 | mjordan | ah |
| 18:06.18 | mjordan | file: if I'm an AMI user, and I 'see' a Snoop channel show up, and I issue an AMI Redirect action, what happens? |
| 18:06.44 | file | it will redirect it to wherever you specify |
| 18:07.13 | mjordan | but stay attached? |
| 18:07.17 | file | yup. |
| 18:07.21 | mjordan | that should work then |
| 18:07.40 | file | it is a real live channel, nothing "special" about it |
| 18:07.53 | file | the audio paths just happen to connect to another channel |
| 18:07.54 | mjordan | the only real reason for the internal details flag - other than so that CDRs don't get more cluttered then they already are - is to avoid people doing things to those channels that could cause catastrophes |
| 18:07.58 | mjordan | since that doesn't happen... yay |
| 18:08.22 | file | yes... I'm quite... pleased |
| 18:08.36 | mjordan | I'd say drop my finding :-) |
| 18:08.56 | file | yeah I've left myself a note re: the events so I'll get those sorted soon |
| 18:09.22 | mjordan | the topic/message type should be in core |
| 18:09.51 | file | did you want a new one, or use the old one |
| 18:10.00 | mjordan | if we can, it'd be nice to use the old one |
| 18:10.01 | file | (message types are in core) |
| 18:10.03 | mjordan | it may need tweaking |
| 18:10.13 | mjordan | but from the perspective of AMI, the operation is the same |
| 18:10.37 | mjordan | you took some channel and attached it to another one with the purpose of sending/receiving audio directly into it |
| 18:10.41 | file | yup |
| 18:22.35 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 18:40.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-acncaaqyrtpxtgvp) |
| 19:33.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.70) |
| 19:35.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.70) |
| 19:50.22 | *** join/#asterisk-dev saghul (~saghul@15.83-213-189.dynamic.clientes.euskaltel.es) |
| 20:00.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:00.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:45.00 | *** join/#asterisk-dev saghul (~saghul@15.83-213-189.dynamic.clientes.euskaltel.es) |
| 21:00.00 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-pbuoshyrxsiyplqk) |
| 21:23.48 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-kjtgxbgnlsqcpfve) |
| 21:27.34 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-pzqaztufmcvkexoj) |
| 21:29.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.159.253) |
| 21:44.56 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 21:47.29 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jkhzgfdtoqkofqcx) |
| 22:04.36 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-grpgbxvsnikmivsj) |
| 22:04.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 22:20.44 | file | opticron, I'm not sure if I like lumping no endpoints found together with invalid tech |
| 22:20.47 | file | but that's just me |
| 22:23.00 | opticron | <_< |
| 22:23.03 | opticron | >_> |
| 22:25.50 | kharwell | file: there didn't seem to be a list of valid techs to check |
| 22:26.39 | kharwell | file: each endpoint registers its tech upon creation |
| 22:28.03 | file | ast_get_channel_tech :D |
| 22:33.58 | kharwell | file: channel and endpoint techs don't seem to be the same thing...I think. |
| 22:34.01 | kharwell | looks some more |
| 22:34.44 | file | an endpoint is a dialable device made up of the technology and resource |
| 22:35.39 | opticron | file, despite all appearances, not my doing :) |
| 22:35.51 | file | true |
| 22:36.05 | file | that's what I get for not putting on my glasses and also casually seeing k and assuming kmoore |
| 22:36.15 | file | opticron, you are off the hook |
| 22:36.55 | opticron | I inherited ownership when I renamed everything from stasis[-_]http to ari |
| 22:36.55 | opticron | hooray |
| 22:43.45 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 22:43.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:45.05 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 22:50.49 | kharwell | file: I see now. They both have the same tech name...or should at least, so yeah I will change it to use get_channel_tech as that would allow a check for invalid tech vs empty |
| 22:51.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.56) |
| 22:51.27 | file | nifty |
| 22:51.50 | kharwell | do you think a 404 should still be returned if empty as it is also not found or does an empty array make more sense? |
| 22:52.51 | file | as a developer using that API I think an empty array would make more sense |
| 22:52.51 | sgriepentrog | It should be possible to "find" an empty set.. |
| 22:52.59 | file | yeah |
| 22:56.51 | pabelanger | file, how do you stop a snoop in ARI? |
| 22:57.13 | leedm777 | guessess you DELETE the snoop channel |
| 22:57.20 | file | leedm777 would be correct |
| 22:57.33 | pabelanger | Are you going to add that to your patch? |
| 22:57.44 | file | no? |
| 22:57.48 | file | a Snoop channel is a regular channel |
| 22:57.52 | file | you just DELETE it and it gets hung up |
| 22:58.23 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 22:58.23 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 22:59.51 | pabelanger | Hmm |
| 23:00.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.56) |
| 23:02.13 | pabelanger | okay, so once the snoop channel is created, can you use channels/:id/mute / unmute functionality. Or do you need to modify the snoop channels whisper / spy parameters each time? |
| 23:02.37 | kharwell | is the tech on an endpoint considered case sensitive? meaning "SIP" is diff than "sip" |
| 23:02.47 | file | anything you can do on a channel you can do to a snoop channel, including snooping (snoopception) |
| 23:02.57 | pabelanger | kharwell, in ARI I noticed it is. IAX2 != iax2 |
| 23:03.02 | file | if you want to change the spy/whisper directions you need a new snoop channel |
| 23:04.12 | pabelanger | file, why do you need to create a new channel? Apposed to modifying the existing |
| 23:04.17 | pabelanger | Opposed* |
| 23:04.59 | file | it's code so that could be done... but internally that would complicate things a lot (keeping a reference to the old channel - hello masquerades, keeping a container of snoop channels, providing an interface for it) |
| 23:05.18 | mjordan | pabelanger: did you see the debate on the app-dev mailing list? :-) |
| 23:05.53 | pabelanger | mjordan, for snoop, not really. I haven't been following it too closely. |
| 23:05.57 | mjordan | http://lists.digium.com/pipermail/asterisk-app-dev/2013-November/000201.html |
| 23:05.57 | pabelanger | file, fair enought |
| 23:06.14 | mjordan | specifically, starting here: http://lists.digium.com/pipermail/asterisk-app-dev/2013-November/000206.html |
| 23:06.21 | pabelanger | Somebody is going to as why PUT /snoops/:id can't be used to update the original |
| 23:06.32 | pabelanger | unless somebody already did |
| 23:06.51 | file | Dan asked about changing but I told him what I told you if I remember right |
| 23:07.46 | mjordan | pabelanger: I'd go back and re-read the archives and see if you think file and I beat each other up enough |
| 23:08.33 | file | mjordan, yet we lived to fight another battle |
| 23:08.35 | mjordan | leedm777 also has a good API perspective on file's approach here - http://lists.digium.com/pipermail/asterisk-app-dev/2013-November/000218.html |
| 23:08.58 | mjordan | file: I know, right? Almost like we had our technical design discussions in an open, transparent manner, commensurate with being an open source project ;-) |
| 23:09.52 | pabelanger | I'll ready it on my trip to NYC tomorrow. I need to implement chan spy functionality here in the next few weeks on 1.8, so I should already get up to speed with ARI |
| 23:10.12 | mjordan | file's approach is really cool |
| 23:10.26 | mjordan | and when you think of what you can do with multiple Snoop channels and the bridging API, it gets ridiculous quickly |
| 23:10.46 | file | let me add the word "safely" in there |
| 23:11.24 | mjordan | it actually is useful for a scenario a professor described to me once. He wanted the ability to have his students sit in on a conference call with business folks |
| 23:11.36 | mjordan | and, if they failed to use proper etiquette, whisper to them to shut up |
| 23:11.44 | mjordan | and then forcibly mute them |
| 23:12.07 | mjordan | with this, you could Snoop to multiple students at the same time (shaming them!), then individually mute their channels |
| 23:12.15 | mjordan | all from a single channel from the professor |
| 23:12.34 | mjordan | as he could be Snooped as well, with a bi-directional audio flow into the bridge containing the student's Snoop channels |
| 23:12.41 | mjordan | so.... a channel is in multiple bridges |
| 23:12.42 | mjordan | bwahahahaha |
| 23:12.53 | mjordan | and they said I was mad |
| 23:13.14 | file | BWAHAHAHAHAHAHAHAHAHA |
| 23:15.52 | file | I sadly don't have anything really cool brewing in my brain right now |
| 23:17.31 | mjordan | :-( |
| 23:17.34 | mjordan | I am disapointed. |
| 23:17.46 | mjordan | I need a cloner right now. |
| 23:45.36 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:52.46 | tm1000 | user -> "Asterisk needs to do this too, "the GVJackApp for magicJack and the GVMate Phone Adapter both of which are signalling independent will not be adversely affected and will continue to work for users as normal after support for XMPP has been terminated.["" |
| 23:52.49 | tm1000 | hmmmmm |
| 23:52.57 | tm1000 | mjordan: file quick waste more of your life.... |
| 23:53.52 | file | :D |
| 23:54.14 | tm1000 | man the rumor mill is awesome today |
| 23:54.16 | tm1000 | file: "iirc google worked with digium to write xmpp support" |
| 23:54.23 | tm1000 | didn't know you worked with google ;-) |
| 23:55.20 | file | Google, Google, Google |
| 23:57.13 | mjordan | yeah, I have no idea what magic jack did. |