| 00:00.59 | *** join/#asterisk-dev moy (n=moy@189.169.90.224) |
| 00:10.25 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 00:30.25 | *** join/#asterisk-dev anthm][ (n=anthm@68-31-185-234.area4.spcsdns.net) |
| 01:04.26 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 02:31.30 | *** join/#asterisk-dev mosty (n=mosty@ppp191-34.static.internode.on.net) |
| 02:38.52 | *** join/#asterisk-dev Corydon76-dig (i=black@pdpc/supporter/bronze/Corydon76-home) |
| 02:38.52 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 03:41.35 | *** part/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 04:18.33 | *** join/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 04:38.25 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:42.56 | *** join/#asterisk-dev pputman (n=centrex@nat/digium/x-93355106917b4e7f) |
| 04:47.38 | *** join/#asterisk-dev jameswf-home (n=james@ip72-200-94-120.tc.ph.cox.net) |
| 05:36.06 | *** join/#asterisk-dev bkw__ (n=brian@freeswitch/developer/bkw) |
| 05:40.08 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.27.111) |
| 05:55.43 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 06:12.34 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:21.21 | *** join/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 07:23.24 | *** part/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 07:24.55 | *** join/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 08:06.28 | sivadnz | I spent a few hours last night changing app_sms.c IF and WHEN condtructs to be trunk guideline compliant, It would be good if one of the dev's could look at it before it's too late. refer http://bugs.digium.com/view.php?id=13677. No code changes were done other than adding braces where required. |
| 08:23.38 | *** join/#asterisk-dev freddyk (n=freddy@79.43.93.73) |
| 08:23.47 | freddyk | Goodmorning all |
| 08:24.11 | freddyk | i would like to ask a question about "UNBRIDGING CHANNELS" |
| 08:24.41 | freddyk | is there any function to do that ? |
| 08:46.38 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 08:46.38 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 08:46.38 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 08:46.38 | *** join/#asterisk-dev CtRiX (n=CtRiX@aretha.navynet.it) |
| 08:46.38 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) [NETSPLIT VICTIM] |
| 08:46.38 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) |
| 08:46.38 | *** mode/#asterisk-dev [+oo file citats] by irc.freenode.net |
| 08:48.48 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:57.32 | *** part/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 09:05.08 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/daviey) |
| 09:05.08 | *** join/#asterisk-dev wedhorn (n=nnnnnnnn@123-243-209-34.static.tpgi.com.au) [NETSPLIT VICTIM] |
| 09:05.08 | *** join/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) [NETSPLIT VICTIM] |
| 10:24.10 | *** join/#asterisk-dev elearner (n=pete-joh@triton.dsv.su.se) |
| 10:29.29 | atis_work | freddyk: AMI action Redirect? |
| 10:56.50 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:23.11 | *** part/#asterisk-dev elearner (n=pete-joh@triton.dsv.su.se) |
| 11:23.29 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.27.111) |
| 11:50.22 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:57.18 | *** join/#asterisk-dev lvl- (n=lvl@145.52.248.101) |
| 11:57.54 | *** join/#asterisk-dev oej (n=olle@90-84-254-204.ip.sipit.net) |
| 11:57.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:58.31 | oej | Afternoon, folks |
| 12:10.26 | snuff-home | hello oej |
| 12:13.14 | mvanbaak | hey oe |
| 12:13.16 | mvanbaak | j |
| 12:50.36 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 12:55.45 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:55.45 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:56.01 | lmadsen | morning all |
| 12:56.38 | snuff-home | ello leif |
| 12:57.16 | lmadsen | snuff-home: heya snuff. How was your day? |
| 12:58.03 | snuff-home | dodged being the main person doing a presentation to customer |
| 12:58.16 | snuff-home | that was nice.. |
| 12:58.51 | snuff-home | playing try do some xml for eliel.. before sleep |
| 13:01.14 | *** join/#asterisk-dev juanjoc (n=juanjoc@OL4-215.fibertel.com.ar) |
| 13:15.39 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-7ab2621544651f19) |
| 13:15.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:31.06 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.199.65) |
| 13:47.23 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 13:47.23 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:48.10 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 13:48.46 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-042b41eee7f9a080) |
| 13:48.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:54.53 | *** join/#asterisk-dev DarkRift (n=dark@65.92.166.33) |
| 14:05.39 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-abdb25d68470f335) |
| 14:05.39 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:13.24 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:13.24 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:31.37 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:31.37 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:32.28 | seanbright | goedemorgen |
| 14:44.43 | eliel | hello! |
| 14:45.11 | lmadsen | godmorgen! |
| 14:45.48 | oej | god morgon! |
| 14:45.53 | oej | Or rather God Eftermiddag |
| 14:46.09 | oej | We're taking off for a tour around the city, me and kpfleming |
| 14:46.11 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 14:46.11 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 14:49.21 | file | yay bweschke! |
| 14:49.30 | bweschke | hey file! |
| 14:50.38 | lmadsen | bweschke: omghi! |
| 14:50.42 | lmadsen | we missed you at astricon! |
| 14:51.03 | bweschke | yes - I'm still kinda bummed davevg and I didn't make it out there this year |
| 14:51.13 | file | bweschke: astridevcon was gr8t |
| 14:51.29 | file | should have Fedexed yourself! |
| 14:51.47 | bweschke | file: yes - I've been following these PineMango and Security threads in -dev ... it has definitely piqued my interest |
| 15:03.43 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-5657864c53582502) |
| 15:03.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:13.55 | *** part/#asterisk-dev corramor (n=corramor@nat/digium/x-fd579e4e697c8b25) |
| 15:15.48 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:17.36 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.35.35) |
| 15:21.21 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 15:27.31 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-d6c5048d458cbaea) |
| 15:41.02 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 15:41.02 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:43.40 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:51.25 | file | bweschke: ooh |
| 15:51.36 | bweschke | file: like that? |
| 15:51.41 | file | yes. |
| 15:51.49 | bweschke | ya - me too. |
| 15:52.03 | bweschke | hopefully it's a good compromise |
| 15:59.29 | *** join/#asterisk-dev bbryant (n=Brett_Br@adsl-159-32-97.flo.bellsouth.net) |
| 15:59.29 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 16:00.22 | jsmith | Works for me |
| 16:01.37 | *** join/#asterisk-dev bkw__ (n=brian@freeswitch/developer/bkw) |
| 16:18.57 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 16:18.57 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 16:22.45 | *** part/#asterisk-dev dandre (n=daniel@was59-3-82-236-48-30.fbx.proxad.net) |
| 16:30.06 | bweschke | it's a slight adjustment through to the angle that Tim/russellb/kpfleming have been going down |
| 16:30.15 | bweschke | ~s/through/though/ |
| 16:33.42 | bweschke | my problem with letting the framework handle things solely is the same as oej I think. the framework then becomes "big brother" and it's then up to "big brother" to know about everything that is behind the access control point |
| 16:34.19 | bweschke | vs. being a proxy to everything that *could* be behind the access control point and letting the resource itself make the decision on whether or not access should be allowed |
| 16:34.31 | russellb | it's a tough topic because it gets at the question of "What is Asterisk?" |
| 16:34.53 | russellb | i think a lot of these suggestions are valid. |
| 16:35.03 | russellb | and the disagreements get down to disagreements on what asterisk should be ... |
| 16:35.17 | bweschke | russellb: 100% agreed - when you look at the Asterisk that powers Switchvox, I can see how it's very, very, very easy to just "let the framework handle it" |
| 16:35.45 | russellb | and really, I think that's the direction forward so that Asterisk is scalable in app development land |
| 16:35.48 | russellb | Asterisk can't be everything |
| 16:35.53 | russellb | we have to draw a line |
| 16:35.57 | bweschke | because you've got a canned product. you know what's going to be requested of what |
| 16:36.21 | russellb | and the trick is, make the telephone engine powerful enough and flexible enough to power whatever app you want |
| 16:36.33 | bweschke | but you're no longer talking about just "app development land" |
| 16:36.37 | russellb | and it really is the app that defines what security model you need in place |
| 16:36.39 | bweschke | with what PineMango is going to be |
| 16:36.57 | russellb | pinemango is just about making it technically _possible_ to do everything you'd want to do when building telephony apps on top of asterisk |
| 16:37.56 | jameswf | technicaly through AGI asterisk can be everything :) |
| 16:38.06 | russellb | well, maybe. |
| 16:38.16 | Qwell | can't originate a call from AGI |
| 16:38.17 | russellb | AGI is great, manager is great ... they both allow some level of development |
| 16:38.25 | russellb | but there is a lot you can't do through either of those interfaces |
| 16:39.07 | bweschke | I think we have to be careful about the decisions being made here and the significance of them. In a platform where you're responsible for EVERYthing going on, again, it's ok to just say "let the framework handle it". |
| 16:39.18 | russellb | nods |
| 16:39.25 | russellb | it's quite important, and I wish I had more time to talk about it :-/ |
| 16:39.45 | bweschke | However, that then pushes the angle that one needs to be responsible for EVERYthing going on. |
| 16:40.10 | bweschke | which is counter productive really ... for what I think is being pitched with the Asterisk Marketplace |
| 16:40.33 | bweschke | eg - "You like this app? Ok cool, come get it. It will install automatically, and everything will be great" |
| 16:40.35 | russellb | right, that is one place where this is still a bit sticky. |
| 16:40.57 | russellb | what happens when you have two frameworks/apps/whatever ... do you need to segment them from each other |
| 16:41.19 | bweschke | "oh wait. did the guy who put this together take the framework into consideration? Am I opening myself to a security hole here? Maybe I ought to think twice about this. I don't know ANYthing about this app I'm putting on to my system automagically" |
| 16:41.31 | russellb | nods |
| 16:41.47 | tzafrir_laptop | russellb, so how do you let Eve modify its part of the dialplan without affecting Alice and Bob? |
| 16:41.59 | Qwell | tzafrir_laptop: SIP doesn't support Eve making calls. |
| 16:42.02 | russellb | I'm going to have to stop the conversation now, though, or else this will go on all day |
| 16:42.15 | russellb | i mean, carry on if you want, but i've got to get back to something else ... |
| 16:43.07 | tzafrir_laptop | Can you make a multi-user version of the asterisk-gui? where some users are actually limited? |
| 16:43.36 | tzafrir_laptop | currently the is not possible, because every user with the power to UpdateConfig has the power to do everything |
| 16:43.58 | russellb | correct. |
| 16:44.15 | Qwell | well... |
| 16:44.24 | seanbright | you could limit the access within the GUI |
| 16:44.29 | Qwell | seanbright: yeah |
| 16:44.29 | bweschke | well I've said my $0.02.. I think we'd be remiss if we put all the security into the framework alone and really making a clear statement about what Asterisk is going to become.. which may not fit with what people who use Asterisk today already see it as. |
| 16:44.43 | russellb | seanbright: correct. (except in this case, the gui is entirely client side, so ...) |
| 16:44.44 | seanbright | i mean, if it wasn't based solely on HTML and JS, anyway. |
| 16:44.46 | Qwell | seanbright: though if somebody wanted, they could just use the xml manager interface |
| 16:44.58 | tzafrir_laptop | seanbright, but this means that the interface is not sobust. |
| 16:45.04 | seanbright | sobust? |
| 16:45.05 | tzafrir_laptop | s/sobust/robust/ |
| 16:45.23 | seanbright | correct, i think that is why this discussion is even taking place |
| 16:45.40 | russellb | no need to beat down manager ... we know it sucks already, heh |
| 16:45.43 | bweschke | and don't get me wrong - PineMango cannot wait for the complete model to be designed and implemented |
| 16:45.58 | seanbright | manager doesn't suck |
| 16:45.59 | bweschke | there's too much that manager doesn't do .. or doesn't do well... already |
| 16:46.02 | tzafrir_laptop | and my main point is that relying on the dialplan alone for authorization is not good enough |
| 16:46.05 | seanbright | it does exactly what is advertised |
| 16:46.46 | seanbright | i should probably stay quiet as i haven't been following the pinemango thread |
| 16:47.07 | russellb | seanbright: it's all about security right now ... and where the policy engine should live |
| 16:47.28 | bweschke | but we're talking about building a building with multiple floors... at some point ... down the road ... if we don't create the foundation to support the multiple floors - we're just not going to knock the building down later on to redo it |
| 16:48.08 | tzafrir_laptop | russellb, I posted some examples on the list and hoped that this would enable the discussion to be less theoretical |
| 16:48.29 | tzafrir_laptop | (well, but I did come up with Alice, Bob and Eve, so that theory) |
| 16:49.37 | seanbright | russellb: "live"? inside or outside asterisk itself? |
| 16:49.46 | seanbright | or where within asterisk? |
| 16:49.53 | russellb | seanbright: in or out for the most part |
| 16:50.04 | seanbright | in. |
| 16:50.07 | seanbright | ^^ |
| 16:50.09 | seanbright | :) |
| 16:51.03 | seanbright | that is my contribution. |
| 16:52.31 | seanbright | i think based on what i /have/ read on the mailing list, no matter what the long term direction is, it's going to over engineered. |
| 16:52.48 | seanbright | and only useful to a very small percentage of users |
| 16:53.01 | seanbright | out-of-thin-air estimate would be < 1% |
| 16:53.25 | russellb | seanbright: always the optimist |
| 16:53.42 | seanbright | realist |
| 16:54.43 | seanbright | i'm not trying to crap on the idea, i think security is important. |
| 16:55.15 | seanbright | but why a simple user/group/possibly role system isn't sufficient, i don't know. |
| 16:55.20 | seanbright | maybe i don't understand all the issues. |
| 16:56.07 | russellb | because defining what a "user" is, is complicated as hell |
| 16:56.14 | russellb | and the complications are because of business rules |
| 16:56.22 | russellb | that make it such that the definition is different for different people |
| 16:56.41 | russellb | so we have to make it easy for people to create their own definitions of users and act those definitions appropriately |
| 16:56.50 | russellb | by making it easy to track and control things via various means ... |
| 16:56.55 | seanbright | a user is an entity to which permissions are applied. |
| 16:57.06 | russellb | sounds easy, doesn't it |
| 16:57.12 | seanbright | "create their own definitions of users" |
| 16:57.17 | seanbright | that sounds frigtening |
| 16:57.19 | tzafrir_laptop | russellb, enforcing it can only be done at the core. Otherwise it cannot be done in real-time |
| 16:57.25 | russellb | it's the permissions part that is where it gets tricky |
| 16:57.28 | seanbright | frightening, rather. |
| 16:57.41 | russellb | tzafrir_laptop: that's not true, we can add hooks at important decision points. |
| 16:58.01 | seanbright | anyway, i am well behind on the discussion |
| 16:58.06 | tzafrir_laptop | hooks? so run an external process at bridging time? |
| 16:58.07 | russellb | as am I, really |
| 16:58.35 | russellb | tzafrir_laptop: not necessarily ... could be a number of things |
| 16:58.43 | russellb | ok, seriously, i have to go back to work |
| 16:58.44 | russellb | heh |
| 16:58.49 | russellb | forces his mouth shut |
| 16:58.52 | tzafrir_laptop | defining what a hook can do is about as complicated as abstracting security events |
| 16:58.53 | seanbright | in my mind, the core would have a concept of a permission. read/write/execute. |
| 16:59.19 | seanbright | each module or "touch point" could add their own permissions, probably in a hierarchy. |
| 16:59.26 | seanbright | permissions specific to that module. |
| 16:59.48 | tzafrir_laptop | again, please look at the metaphore of OS, where the kernel enforces permissions but userspace decides them |
| 16:59.53 | seanbright | kinda like... well... Windows ACL |
| 17:00.51 | seanbright | i guess i should say "their own permission types" |
| 17:01.04 | seanbright | anyway. |
| 17:01.13 | seanbright | shuts up |
| 17:03.02 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 17:03.02 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 17:06.57 | *** join/#asterisk-dev juanjoc (n=juanjoc@OL4-215.fibertel.com.ar) |
| 17:09.12 | *** join/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 17:31.45 | tzafrir_laptop | hmm... is spandsp 0.0.6 api-stable yet? |
| 17:32.02 | russellb | didn't sound like it from steve's post on -dev |
| 17:34.06 | seanbright | is zt_registration part of zaptel? |
| 17:34.45 | putnopvut | based on the name, I'd say it's either part of zaptel or chan_zap |
| 17:34.51 | seanbright | ah, xorcom stuff |
| 17:34.54 | seanbright | delete |
| 17:34.57 | seanbright | heh |
| 17:36.19 | tzafrir_laptop | well, maybe a better name is needed for it |
| 17:37.02 | seanbright | i just am going through deleting zaptel stuff on my system |
| 17:37.04 | tzafrir_laptop | the name of it comes from a the file /proc/xpp/XBUS-mm/XPD-nn/zt_registration |
| 17:37.12 | seanbright | wanted to make sure it wasn't imporant for my install |
| 17:38.24 | tzanger | wt |
| 17:38.25 | tzanger | er wtf |
| 17:38.35 | tzanger | I can't make menuselect on amd64 with dahdi-tools? |
| 17:38.40 | seanbright | sigh... |
| 17:38.43 | seanbright | what's the error? |
| 17:38.50 | tzanger | segfault. I'm grabbing gdb to track it down now |
| 17:38.59 | seanbright | aw crap... |
| 17:39.02 | tzanger | I'm using r4955 |
| 17:39.40 | seanbright | just built and worked fine from me with r5088 |
| 17:39.40 | tzafrir_laptop | built 32bit from the same working copy? |
| 17:39.50 | seanbright | (x86, though) |
| 17:40.01 | seanbright | and menuselect isn't based on the revision of dahdi, so. |
| 17:40.18 | tzanger | seanbright: don't worry about it |
| 17:40.21 | tzanger | it's a make clean problem |
| 17:40.26 | seanbright | oh thank jeebus. |
| 17:40.34 | tzanger | I copied it over from an x86 system, make clean, ./configure && make menuselect and it segfaulted |
| 17:40.43 | tzanger | blew the directory away, untarred fresh and it builds fine |
| 17:40.47 | seanbright | cool |
| 17:40.58 | tzanger | so there's a little corner case make clean bug there |
| 17:41.01 | tzanger | but nothing significant |
| 17:41.14 | seanbright | make distclean might have fixed you up |
| 17:41.20 | tzanger | that may indeed be true |
| 17:41.31 | tzanger | I can never remember the difference between clean and distclean (not just or dahdi, but in general) |
| 17:41.37 | seanbright | neither can i |
| 17:41.38 | seanbright | heh |
| 17:41.47 | seanbright | when clean doesn't work, try distclean. |
| 17:42.04 | seanbright | distclean cleans up the configure madness i believe. |
| 17:42.25 | jsmith | Or, in the case of dahdi-complete, it ends up *running* configure again :-/ |
| 17:42.31 | seanbright | lame |
| 17:45.14 | tzanger | haha |
| 17:46.38 | seanbright | building wanpipe for DAHDI... |
| 17:46.57 | seanbright | i have some goats blood and the eye of a newt... i hope that does the trick |
| 17:53.29 | seanbright | that was relatively painless. |
| 17:53.40 | seanbright | not for the goat or newt... but for me, anyway. |
| 17:54.49 | tzafrir_laptop | there's wanpipe dahdi drivers? |
| 17:55.22 | tzafrir_laptop | and don't use dahdi-complete |
| 17:58.00 | *** join/#asterisk-dev pgarcia (n=chatzill@yoda.kanatek.com) |
| 18:02.32 | seanbright | there are, yes. |
| 18:02.41 | seanbright | and i'm using svn trunk for both linux and tools. |
| 18:07.11 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@66.152.207.97) |
| 18:07.11 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 18:11.21 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:12.48 | putnopvut | Corydon76-dig: ping |
| 18:47.38 | jameswf | lmadsen: jsmith "O'Reilly Media is conducting research about in-person, live workshops on software and business topics" so they have a survey would said survey promote sales and development of "the book" |
| 18:48.21 | lmadsen | jameswf: I have no idea... |
| 18:48.33 | lmadsen | jsmith would be better able to answer that question |
| 18:52.52 | jsmith | jameswf: Would the survey itself promote sales, or would in-person live workshops drive sales? |
| 18:53.29 | jsmith | jameswf: I'm guessing that the survey itself *might*... but workshops definitely would. |
| 18:53.34 | jameswf | jsmith: I forewarded you the email i got |
| 18:53.35 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 18:53.54 | jsmith | jameswf: Danke |
| 18:58.52 | *** join/#asterisk-dev moy (n=moy@189.169.90.224) |
| 18:59.28 | Corydon76-dig | putnopvut: pong |
| 19:00.36 | putnopvut | Corydon76-dig: your commit for AST-107 is breaking the build for me in app_voicemail, because in make_email_file, len_passdata may be used uninitialized. |
| 19:00.52 | Corydon76-dig | putnopvut: in which branch? |
| 19:01.25 | putnopvut | Corydon76-dig: 1.4 |
| 19:01.30 | Corydon76-dig | I got that warning and fixed it in 1.6.1, but not in 1.4 or trunk |
| 19:01.51 | Corydon76-dig | You can safely initialize it to 0 |
| 19:02.05 | putnopvut | That's what I've been doing as a workaround, but I wasn't sure if there was more to it. |
| 19:05.26 | Corydon76-dig | Nope, that's a working solution |
| 19:07.32 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:09.09 | jameswf | I noticed in 1.6 if i set a dahdi channel to DND then call it it spits out a failure but doesnt reference the DND status |
| 19:14.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:17.43 | jeffg | russellb, so no backports to 1.4 point releases? too many release policies to keep track of, my head asplode ;) |
| 19:18.00 | russellb | i know .. |
| 19:18.02 | russellb | sorry |
| 19:18.06 | Corydon76-dig | jeffg: backports on svncommunity only |
| 19:18.52 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 19:18.52 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 19:18.57 | tzafrir_laptop | jameswf, you try to originate a call from a channel? group? |
| 19:19.43 | tzafrir_laptop | and I don't think this has changed from 1. and 1.4 |
| 19:19.50 | tzafrir_laptop | 1.2 and 1.4 , that is |
| 19:20.12 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:20.52 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:23.14 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:24.00 | jeffg | russellb, Corydon76-dig, thanks and no worries -- some guy showed up on our -discuss list asking where those objects are in 1.4.22. i'll tell him he'll have to backport it himself or upgrade. |
| 19:24.27 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 19:24.27 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 19:25.20 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:26.37 | russellb | jeffg: sorry ... luckily we have not restricted ourselves from doing this type of thing in 1.6 |
| 19:27.16 | jeffg | russellb, i'm sure that's the source of my confusion -- thought the features-in-point-releases applied to 1;4 as well. |
| 19:27.19 | jeffg | sits corrected |
| 19:27.35 | russellb | nods |
| 19:27.37 | russellb | no problem |
| 19:27.37 | Corydon76-dig | jeffg: what feature did the guy want? |
| 19:27.50 | jeffg | M13679 |
| 19:27.53 | MuffinMan | [closed] [Asterisk] Resources/res_snmp 0013679: Backport astConfigCallsActive and astConfigCallsProcessed MIB objects to Asterisk 1.4 reported by jeffg (Karma: +12.00) http://bugs.digium.com/view.php?id=13679 |
| 19:28.30 | Corydon76-dig | jeffg: would you like a repository of your own on svncommunity? |
| 19:28.40 | russellb | Corydon76-dig: don't sign me up for work :-p |
| 19:29.28 | Corydon76-dig | russellb: don't you have a script that does that yet? |
| 19:29.33 | russellb | no. |
| 19:30.39 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 19:30.39 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 19:31.02 | lmadsen | create4community :) |
| 19:32.34 | Corydon76-dig | lmadsen: mkcommunity ;-) |
| 19:32.49 | lmadsen | ya... after I said that I realized my naming scheme was off :) |
| 19:37.00 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:49.18 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 19:49.18 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 20:00.32 | seanbright | http://www.nj.com/gloucester/index.ssf?/base/sports-6/1223801714204420.xml&coll=8 |
| 20:01.38 | tzafrir_laptop | waits for someone else to give some specific examples |
| 20:01.54 | tzafrir_laptop | in that "pine-mango" thread |
| 20:02.32 | seanbright | but much more importantly, the headline of that link i sent is super. |
| 20:02.51 | putnopvut | seanbright: lol |
| 20:03.24 | bweschke | waits for Corydon76-dig to pick up on it and start knocking NJ |
| 20:06.09 | jsmith | bweschke: What's wrong with NJ? (Well, except for the industrial grime and swamps...) |
| 20:06.23 | tzafrir_laptop | specifically, I completely don't understand how those hooks are supposed to work |
| 20:06.31 | bweschke | ahh.. I see jsmith has filled in for Corydon76-dig today |
| 20:06.44 | jsmith | bweschke: Just doing my part :-) |
| 20:07.25 | jsmith | tzafrir_laptop: Think of hooks as a list of callback functions. When an event happens, Asterisk would go down through the list of "hooks" (callback functions) and execute each one. |
| 20:07.36 | bweschke | good thing... I'd have been disappointed if no one took advantage. :-) |
| 20:08.06 | jsmith | tzafrir_laptop: So, let's say someone tries to register a phone... during that process, Asterisk would see that the framework had registered a callback function to be called whenever someone tries to register a phone. |
| 20:08.10 | tzafrir_laptop | jsmith, ok, explain how hooks can allow multiple users to edit the dialplan |
| 20:08.22 | jsmith | OK, fair enough |
| 20:08.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:08.45 | jsmith | Let's say the framework registers a hook for "dialplan manipulation" |
| 20:09.23 | Deeewayne | seanbright: those gloucester football players think they are all high and mighty |
| 20:09.31 | seanbright | Deeewayne: ba dum dum |
| 20:09.32 | jsmith | When someone tries to modify the dialplan (through AMI, let's say), it would call the callback function and the framework could say "Hey, is this user allowed to perform this action"? |
| 20:09.35 | Deeewayne | :-( |
| 20:09.36 | bweschke | jsmith: and then Eve modifies her dialplan and Adam was the guy registered to get the callbacks about dialplan manipulation |
| 20:10.02 | seanbright | Deeewayne: noo... 'ba dum dum *ching*' |
| 20:10.08 | seanbright | Deeewayne: wasn't callinig you a dum dum |
| 20:10.09 | seanbright | :) |
| 20:10.26 | jsmith | bweschke: I'm not seeing your point. Guys don't get callbacks... the framework registers the callback functions, and the framework gets to decide to allow or disallow the action. |
| 20:10.28 | tzafrir_laptop | jsmith, so whatabout Goto(${name_created_dynamically},1,1) ? |
| 20:10.41 | Deeewayne | file usually calls me a dum dum |
| 20:10.53 | seanbright | well, i question file's judgement sometimes |
| 20:11.00 | tzafrir_laptop | checking at manipulation time is far from enouh |
| 20:11.05 | file | I call you Dwayne Dwayne silly! not dum dum |
| 20:11.06 | bweschke | I think we're confusing registered "hook actions" based on events happening vs. actually making the call that allows that makes the action that, in return, spawns off the event broadcast process |
| 20:11.29 | jsmith | tzafrir_laptop: I agree that it's not perfect, but I'd also say that anyone that can arbitrarily change the dialplan can arbitrarily work around all kinds of security |
| 20:12.26 | tzafrir_laptop | also, do you think such a hook is possible if there are two completely frameworks running, |
| 20:12.29 | bweschke | jsmith: again .. like I mentioned earlier .. the problem then is that the framework plays the function of "big brother" |
| 20:12.39 | tzafrir_laptop | one by Eve and one by Allice? |
| 20:13.05 | jsmith | bweschke: Sure... how else do you suggest we do this, without rewriting every single Asterisk API function? |
| 20:13.52 | tzafrir_laptop | jsmith, I claim that the hooks don't really buy you anything. They only add complexity |
| 20:14.24 | tzafrir_laptop | becasue such things can only be enforced by core api |
| 20:15.06 | bweschke | jsmith: like I suggested... wrap the API function and then either the original API function know what to do with the new request context information or it doesn't... and in the case that it doesn't, there's a default policy for those scenarios |
| 20:15.10 | tzafrir_laptop | in the previous round of "let's add a bandaid because asterisk needs a better interface" we got users.conf |
| 20:15.40 | bweschke | and that default policy is configurable. |
| 20:16.38 | jsmith | tzafrir_laptop: The problem is, the core often doesn't know what the business logic is. How is the core of Asterisk supposed to know that Alice can't transfer calls to Bob? Or can't register their phone over the weekend? |
| 20:16.56 | tzafrir_laptop | jsmith, I addressed that on the list |
| 20:17.06 | jsmith | hasn't checked his email for an hour |
| 20:17.17 | bkruse | seanbright: what was that chris kid talking about -1 about? |
| 20:17.18 | tzafrir_laptop | we provide an interface that is simple and clear enough |
| 20:17.34 | seanbright | bkruse: eh? |
| 20:18.48 | bkruse | seanbright: nvm, long post ago |
| 20:18.49 | tzafrir_laptop | jsmith, it should be the jobs of the API, config files or whatever to tell the core which objects have which ownership/credentials, roles, or whatever you call it |
| 20:18.56 | tzafrir_laptop | The core's job is to enforce it |
| 20:19.35 | bweschke | jsmith: and the core shouldn't know what the business logic is. it's only job is to say "this role is allowed to have access to this resource... or... it isn't" |
| 20:19.37 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 20:19.37 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 20:19.38 | tzafrir_laptop | I gave an example: add an optional "owner" to every dialplan section |
| 20:19.52 | tzafrir_laptop | maybe also to every channel section? |
| 20:20.18 | tzafrir_laptop | channels carry authentication credentials around with them |
| 20:20.44 | tzafrir_laptop | jsmith, please give a use case |
| 20:20.58 | tzafrir_laptop | So far I'm the only one providing those |
| 20:21.17 | jsmith | The ones discussed during the devcon (from the top of my head are) |
| 20:21.39 | tzafrir_laptop | err... I wasn't there |
| 20:21.41 | jsmith | People being able to only register phones during a certain time period |
| 20:21.54 | Corydon76-dig | I kind of like bmd's suggestion on using hooks for authorization purposes |
| 20:21.57 | jsmith | Alice being able to transfer calls to Bob, but not Charlie |
| 20:22.02 | tzafrir_laptop | why isn't this possible today? |
| 20:22.27 | tzafrir_laptop | Corydon76-dig, I have just explained why this doesn't help |
| 20:23.01 | tzafrir_laptop | jsmith, likewise: solving this with hooks means creating a very complex logic to run at runtime |
| 20:23.13 | tzafrir_laptop | but solving this with a permissions system? |
| 20:23.26 | jsmith | tzafrir_laptop: There's no argument that it's going to be complex... the question is where to put the complexity |
| 20:23.29 | Corydon76-dig | tzafrir_laptop: it's going to be computationally expensive either way |
| 20:23.30 | tzafrir_laptop | we have something basically similar with call-groups and pickup groups |
| 20:23.50 | bweschke | jsmith: that's really easy. at 9a on Saturday morning, roles are updated and users that previously had access, no longer do have access to give resources |
| 20:24.00 | bweschke | and then at 9a on Monday morning - roles change back |
| 20:24.17 | tzafrir_laptop | checking permissions is not necessarily such an expensive operation |
| 20:24.41 | Corydon76-dig | tzafrir_laptop: but given a set of business rules, it certainly could be |
| 20:24.44 | jsmith | bweschke: Well, the idea was that it could be more complex than that... that the framework could basically say "yay" or "nay" to all kinds of different actions |
| 20:25.10 | Corydon76-dig | tzafrir_laptop: the issue with permissions is that we cannot model every single plan that sys admins might want to do |
| 20:25.15 | tzafrir_laptop | Corydon76-dig, which is why I want to make it a matter of permissions and not of arbitrary hooks |
| 20:25.28 | bweschke | I agree 100% with tzafrir here. it's one thing to register for events based on when actions happen. it's completely another thing to seek premission for that action to happen based on event notification |
| 20:25.31 | tzafrir_laptop | Corydon76-dig, ok. Please suggest something it can't |
| 20:25.39 | Corydon76-dig | tzafrir_laptop: with hooks, ANY set of logic can prohibit an action |
| 20:25.50 | tzafrir_laptop | but this logic is complex |
| 20:26.01 | Corydon76-dig | tzafrir_laptop: prohibit user A from doing more than 3 transfers in a 60 second period |
| 20:26.15 | bweschke | jsmith: right - which is exactly why the framework shouldn't be the ultimate decision point as to who can and cannot do what |
| 20:26.21 | tzafrir_laptop | and furthermore, we don't want Allice's logic in the core |
| 20:26.38 | Corydon76-dig | tzafrir_laptop: precisely, which is why it should be a hook |
| 20:26.47 | tzafrir_laptop | Or rather's Eve might put some expensive logic tests to DoS Allice's calls |
| 20:27.27 | tzafrir_laptop | Thus the hooks can't really come from the user. They can only come from the administrator |
| 20:27.37 | tzafrir_laptop | I prefer to get data from the user. Not code |
| 20:28.05 | Corydon76-dig | tzafrir_laptop: you're seeing the problem, though, for implementing any sort of permissions system |
| 20:28.17 | bweschke | the design of this dictates that ACL's can only be applied when a specific use case has been defined |
| 20:28.23 | Corydon76-dig | which is why we're resistant to the whole concept |
| 20:28.35 | jsmith | It sounds to me like maybe we're not on the same page as far as what the framework is and where that logic comes from |
| 20:28.38 | bweschke | that's a very dangerous precedent for something that's been as free form, to date, as Asterisk |
| 20:29.50 | Corydon76-dig | bweschke: right, we're damned if we do, damned if we don't |
| 20:30.36 | bweschke | Corydon76-dig: it doesn't really have to be that way. Setup the foundation, and then people will either code to it and use it, or... they won't .. and either way - both sides are satisfied |
| 20:31.45 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 20:31.45 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:32.45 | jsmith | bweschke: I agree with that sentiment, but people will either use it or not, whether it's permissions based or hooks based or based on cosmic rays |
| 20:34.14 | bweschke | jsmith: the hooks approach creates the ability for the whole platform to have some real stability problems with poorly implemented event actions on what are some very basic and core functions |
| 20:34.27 | Corydon76-dig | bweschke: We're damned if we do nothing, we're damned if people think the security mechanisms are too bulky and slow Asterisk down, and we're damned if people think the security mechanisms are not fine-grained enough |
| 20:35.04 | jsmith | bweschke: I agree... but an administrator can currently do dumb things to make an Asterisk system have stability and scalability problems |
| 20:35.21 | jsmith | It comes down to the point that we have to trust the administrator not to do stupid things |
| 20:35.37 | bweschke | jsmith: yes.. they can .. so why are we designing and implementing what could become another vulnerability when there are alternatives? |
| 20:35.43 | jsmith | If the admin does stupid things, there's not a lot we can do about it |
| 20:37.01 | De_Mon | remote shutdown via sip uri backdoor |
| 20:37.21 | tzafrir_laptop | regarding the transfer issue: where would you normally use such a limitation? |
| 20:37.41 | Corydon76-dig | tzafrir_laptop: maybe not on transfers, maybe on origination |
| 20:37.58 | Corydon76-dig | Limit Suzie from originating more than 2 calls per minute |
| 20:37.59 | tzafrir_laptop | I'm trying to understand if the groups involved normally have some other significance |
| 20:39.00 | Corydon76-dig | Trying to collect statistics and make business decisions upon them is massively complicated and difficult to do in a way that satisfies everybody |
| 20:39.23 | Corydon76-dig | and yet, that's precisely the kind of functionality that people want to limit |
| 20:39.56 | bweschke | Corydon76-dig: and should be the framework's job.. if someone wants to implement that, register to listen for transfer events, and when you've hit the limit, revoke the permission from the role |
| 20:40.12 | bweschke | sorry.. s/should/should NOT/ |
| 20:40.21 | Corydon76-dig | bweschke: but it's time-based |
| 20:40.42 | bweschke | right |
| 20:40.47 | bweschke | so |
| 20:40.56 | bweschke | you need to code that into the event listener logic |
| 20:41.02 | bweschke | and likewise |
| 20:41.08 | Corydon76-dig | bweschke: the issue with the framework doing it is that there are different frameworks, some of which that makes sense for and others for which that is a security risk |
| 20:41.37 | bweschke | Corydon76-dig: I'm not sure I get you. |
| 20:42.02 | Corydon76-dig | bweschke: Consider a JSON client for Asterisk, where the framework is running on a remote PC |
| 20:42.07 | bweschke | yup |
| 20:42.16 | tzafrir_laptop | Corydon76-dig, it's not that simple, as you need to tell a successful call from a failed call |
| 20:42.19 | jsmith | Which is why I said, I think there's a fundamental misunderstanding of the role of the frameworks |
| 20:42.29 | Corydon76-dig | bweschke: a rogue JSON client can subvert the entire security of the Asterisk instance |
| 20:43.25 | Corydon76-dig | and yes, there are people who do that in the wild. I've met some of them. |
| 20:43.36 | bweschke | Corydon76-dig - if implemented that way, yes, I supposed they could .. |
| 20:43.51 | cj | Corydon76-dig: yipe. don't you think there might be too much overhead in JSON for reasonable call quality? |
| 20:44.30 | Corydon76-dig | cj: we're not talking about audio transmissions. We're talking about the ability to originate calls to Cuba |
| 20:44.36 | bweschke | personally.. I'd set it up that the only way you could redefine roles would be outside of the framework or interface itself.. and when the logic on the outside decided that it was time to change roles, it pulled a trigger somewhere else |
| 20:44.40 | cj | anything that depends on the modern javascript engine ... oh :) |
| 20:45.08 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 20:45.08 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:46.18 | bweschke | and to jsmith's earlier point ... would you really *want* to open up the interface to a really remote site such that others defined as "rogue" could get in? I'd not to that under the hooks principle simply because I cannot count on the network SLA and I wouldn't want a call to hang indefinitely while we're waiting for permission to transfer from some "remote JSON client" |
| 20:46.48 | Corydon76-dig | bweschke: we covered that by saying remote hooks would have a default timeout |
| 20:47.11 | Corydon76-dig | bweschke: most hooks would be on the same machine, if not internal to the process |
| 20:47.14 | bweschke | Corydon76-dig: it's still an undesirable user experience |
| 20:47.31 | Corydon76-dig | bweschke: we're thinking of a default timeout of maybe 50ms |
| 20:47.37 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 20:47.58 | Corydon76-dig | So the remote engine has to reply within 50ms to cancel a hook'ed event |
| 20:49.52 | bweschke | so you're essentially then limiting, based on sheer performance, what can really be done to make a decision one way or the other when deciding to cancel a hook'ed event? |
| 20:50.41 | bweschke | don't get me wrong - hooks are great ... and a simple solution to a complex problem - in a canned environment |
| 20:51.50 | bweschke | but it's not the panacea - and certainly would be something that if I wasn't taking advantage of, I'd want to disable entirely |
| 20:52.10 | Corydon76-dig | bweschke: if you had no hooks registered, then nothing would fire |
| 20:53.09 | Corydon76-dig | bweschke: I honestly think 50ms is gobs of time for most calculations |
| 20:53.15 | bweschke | right - so as a general policy - do we make any callback registrations that are going to use this approach configurable such that they can be disabled outside of code? |
| 20:53.31 | Corydon76-dig | If it takes longer, you're using the wrong engine to make business decisions |
| 20:54.16 | Corydon76-dig | bweschke: Please clarify |
| 20:56.29 | bweschke | there was a period of time in the 1.2 branch days where I actually made it configurable (in queues.conf) for app_queue to not register any events at all out to the manager because I had no need for them in my application and even though I had clients coming in on the manager with "Events: Off" a very busy app_queue infrastructure generated a crap ton of processing to handle those events that no one card about |
| 20:57.34 | seanbright | did the same |
| 20:57.35 | Corydon76-dig | Interesting |
| 20:58.27 | Corydon76-dig | Did you submit that back as a patch? |
| 20:58.42 | seanbright | wasn't allowed to |
| 20:59.19 | bweschke | Corydon76-dig: you say "if you had no hooks registered, then nothing would fire" - but who makes that decision? The administrator of the system or the developer who's putting in place the functionality? fine ... to say "I don't like the way this app is implemented, and therefore, I'm not going to use it ... but it's quite a different animal when these hooks are embedded into chan_sip" |
| 20:59.58 | bweschke | Corydon76-dig: negative.. it was quite the hack job at the time.. if I was reviewing what I submitted, I sure wouldn't have approved it. :-) |
| 21:06.03 | bweschke | again - bmd has raised plenty of great use cases for the hooks approach - and that approach probably works splendidly for how he wants to use them, but if by implementing the hooks approach in the core (and it's not configurable) we take anything more than a 1% performance hit at the core, then that's bad. |
| 21:06.07 | Corydon76-dig | bweschke: but as the administrator of the system, you can choose not to load any modules that implement the hooks |
| 21:06.37 | Corydon76-dig | Or rather, that REGISTER for those hooks |
| 21:07.05 | bweschke | Corydon76-dig: as I said.. yes.. I agree.... but if chan_sip has these buried within it and it is enabled by default, it's not really fair to say "just don't use chan_sip" right? |
| 21:07.41 | Corydon76-dig | bweschke: No, you misunderstand |
| 21:07.54 | bweschke | Corydon76-dig: do I? |
| 21:08.04 | Corydon76-dig | chan_sip may have hooks, but chan_sip won't have hooks registered into other places |
| 21:08.20 | Corydon76-dig | only something like res_api will have hooks registered |
| 21:09.09 | Corydon76-dig | chan_sip is a server for hooks, res_api is a client of those hooks |
| 21:09.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:09.34 | Corydon76-dig | chan_sip may generate hook events, but if res_api isn't loaded, those hook events do nothing at all |
| 21:10.04 | bweschke | Corydon76-dig: we need to be way more granular than that ... |
| 21:10.17 | bweschke | what if you want res_api for other functionality, but not hooks? |
| 21:10.38 | Corydon76-dig | bweschke: I think it's an all or nothing proposition |
| 21:10.59 | Corydon76-dig | or will be, at the initial time |
| 21:11.44 | Corydon76-dig | bweschke: nothing says we wouldn't accept a patch to turn off the hook registration in res_api if somebody thought that was useful |
| 21:13.04 | *** join/#asterisk-dev stephbul (n=stephbul@bulot.org) |
| 21:19.03 | bweschke | Corydon76-dig: we really need to avoid what was .. and might very well still be the way manager events are implemented now.. It's been a while since I've been into manager.c, but for a long period of time, so long as you had manager clients logged in, even if they logged in with "Events: off" the manager went through the efforts of queueing the event and then deciding that it didn't need it after all for the client logged in before popping it back |
| 21:21.23 | bweschke | those are wasted cycles - and come at a cost that's directly relational to how busy the system is to begin with |
| 21:22.06 | Corydon76-dig | bweschke: that'd be a welcome optimization patch |
| 21:23.48 | tzanger | any ISDN BRI experts here? I have a lowlevel state machine question. |
| 21:25.49 | lmadsen | tzanger: sure... what is your question? |
| 21:26.16 | bweschke | Corydon76-dig: yes. agreed. :-D and as we look towards implementation of res_api.. I only point that out because I think we need to be very careful not to make the same mistake twice. |
| 21:26.33 | tzanger | blinks |
| 21:26.37 | tzanger | lmadsen: you? |
| 21:26.42 | lmadsen | tzanger: aye |
| 21:26.52 | tzanger | ok |
| 21:27.18 | lmadsen | tzanger: I'm just yankin' yer chain because I'm curious about the question |
| 21:27.27 | tzanger | I thought so :-) |
| 21:27.31 | tzanger | but sure |
| 21:27.41 | jsmith | tzanger: What's the question... I have ISDN gurus at my beck and call |
| 21:28.01 | tzanger | NT side |
| 21:28.59 | tzanger | I've just come out of reset |
| 21:29.23 | tzanger | so G0 -> G1, I start T1 and hit G2 (pending activation) |
| 21:29.39 | tzanger | I sit there until I receive INFO3 or T1 expires (2s) |
| 21:29.47 | tzanger | T1 expires since the port is unconnected |
| 21:30.02 | tzanger | that means I start T2 and jump to G4 (pending deactivation) |
| 21:30.24 | tzanger | so now I'm sitting in G4... I should have T2 expire |
| 21:30.25 | tzanger | aha |
| 21:30.28 | tzanger | answered my own question |
| 21:30.36 | Qwell | that worked well |
| 21:30.39 | jsmith | tzanger: Awesome! |
| 21:30.39 | tzanger | I should be starting T2 and don't seem to be |
| 21:30.40 | Qwell | jsmith: You're good.. |
| 21:30.48 | jsmith | is humble too |
| 21:31.04 | tzanger | [ 562.096159] wcb4xxp 0000:01:0a.0: 2000: hfc_timer_expire, Port 1 T1 expired (value=2000 ena=1) |
| 21:31.07 | tzanger | [ 562.096180] wcb4xxp 0000:01:0a.0: forced port 1 to state 4 (auto: 1), new decode: P1: NT state G4 (PEND.DEACT) SYNC: no, RX INFO0: no, T2 OK, auto G2->G3: no |
| 21:31.10 | tzanger | [ 562.096212] wcb4xxp 0000:01:0a.0: port 1 old=0xc2, new A_ST_RD_STA=0xc4, decoded: P1: NT state G4 (PEND.DEACT) SYNC: no, RX INFO0: yes, T2 OK, auto G2->G3: yes |
| 21:31.12 | lmadsen | actually I think I was the one telling him to ask the question anyways :) |
| 21:31.22 | tzanger | I'm not starting T2 |
| 21:31.23 | tzanger | dammit |
| 21:31.37 | tzanger | and I didn't mean to paste all that either, that was supposed to be in another window |
| 21:31.51 | tzanger | meanwhile, in another channel |
| 21:32.12 | tzanger | 17:32 < Catonic_lp> You know the phrase "drink until she's pretty" has led me to the verge of alcohol poisoning so many times... |
| 21:32.57 | tzanger | I hope all you canuckistanis voted |
| 21:34.20 | tzafrir_laptop | tzanger, why does the NT port drop the connection? |
| 21:34.53 | ctooley | Because I've seen NT drop ports since it's first release? |
| 21:35.08 | tzanger | this isn't dropping, it's never started :-) |
| 21:41.39 | codefreeze-lap | Ah, that's nice. Now we can actually get vehicles in & out of the driveway again to the house. Gave the boys some scoop shovels and said: clear the snow out of the driveway. And they did. |
| 21:42.07 | *** join/#asterisk-dev bkw___ (n=brian@freeswitch/developer/bkw) |
| 21:42.18 | tzanger | ... snow? |
| 21:42.23 | tzanger | where the hell are you? |
| 21:44.30 | codefreeze-lap | NW Wyoming |
| 21:44.35 | tzanger | wow |
| 21:44.37 | tzanger | snow |
| 21:44.38 | tzanger | crazy |
| 21:44.42 | codefreeze-lap | Had 4 foot drifts in the driveway |
| 21:44.43 | tzanger | we're having almost an indian summer here |
| 21:45.24 | ctooley | We're cooling off, it's definitely fall here. |
| 21:45.37 | codefreeze-lap | We were too. 70 & 80s F then bang. 3 day snowstorm. Trees still green. |
| 21:45.50 | tzanger | heh |
| 21:46.01 | ctooley | They won't be green long. :) |
| 21:46.24 | codefreeze-lap | Yeah, it's a visible shower of brown leaves out there now. |
| 21:50.22 | *** join/#asterisk-dev alerios (n=alerios@190.144.75.22) |
| 22:00.19 | tzanger | mother fucker |
| 22:00.26 | tzanger | I think I got bit by a god damned off-by-one |
| 22:00.30 | file | language! |
| 22:00.36 | file | tzanger: you seem to get bit by those a lot |
| 22:00.50 | tzanger | for(timer=HFC_T1; timer < HFC_T3; timer++) { ... } |
| 22:00.58 | tzanger | will never work on HFC_T3 |
| 22:01.12 | tzanger | that is perfectly appropriate language for such an insidious bug |
| 22:01.17 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 22:03.31 | *** part/#asterisk-dev alerios (n=alerios@190.144.75.22) |
| 22:04.55 | tzanger | prays |
| 22:10.57 | tzanger | shit |
| 22:20.33 | jsmith | tzanger: Was that your prayer? |
| 22:20.36 | jsmith | ducks |
| 22:41.45 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:46.46 | *** join/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 22:50.51 | tzanger | jsmith-away: haha |
| 22:53.26 | *** join/#asterisk-dev CGMChris (n=chris@mail.cgmyes.com) |
| 23:05.43 | jsmith | tzanger: Your humor makes me think you solved your problem :-) |
| 23:11.26 | tzanger | no |
| 23:11.32 | tzanger | I think I'm on the right track though |
| 23:12.01 | tzanger | basically it's on the TE side, not the NT side |
| 23:12.03 | tzanger | I think |
| 23:12.32 | jsmith | Gotcha |
| 23:12.33 | tzanger | when in F3 (deactivated) it should be expiring and jumping to awaiting signal, expiring T3 and jumping to F3, etc. |
| 23:12.50 | jsmith | Makes sense |
| 23:15.34 | jsmith | tzanger: Does this help or hurt? http://www.somemore.com/tips.html |
| 23:17.30 | tzanger | nice, I'll take a closer look momentarily |
| 23:28.45 | Corydon76-dig | pokes Qwell with the Weird Al song "Smells like Nirvana" |
| 23:36.11 | jsmith | Corydon76-dig: I saw that bug... that rocks! |
| 23:38.15 | tzanger | there's a smells like nirvana bug? |
| 23:39.53 | Corydon76-dig | M13693 |
| 23:39.54 | MuffinMan | Failed to retrieve issue data for 13693. Try again later. |
| 23:44.49 | I-MOD | tzanger, that's the same conclusion I came to (that the issue was on the TE side) |
| 23:45.32 | I-MOD | as i could plug in a TE from a system running the mISDN stack and get it to come up |
| 23:49.27 | tzanger | I-MOD: I think I got it |
| 23:49.37 | tzanger | I'm just building up patches right now to bring 5096 to where I am |
| 23:49.45 | tzanger | piece by piece, as I cleaned up some stuff too |
| 23:50.21 | tzanger | I-MOD: sorry to hear about your illness, unless you were faking it because it's such a lovely day, in which case: lucky bugger. :-) |
| 23:52.00 | lmadsen | I spent yesterday outside |
| 23:52.05 | lmadsen | it was quite nice out |
| 23:52.43 | jsmith | lmadsen: Question for you... if you celebrate Thanksgiving on Columbus Day, when do you celebrate Columbus Day? |
| 23:52.46 | tzanger | today was pretty nice too |
| 23:52.54 | tzanger | jsmith: on thanksgiving, of course. |
| 23:53.26 | jsmith | tzanger: Good one... which means you *admit* that Thanksgiving is in November... thanks! |
| 23:53.30 | tzanger | hahahaha |
| 23:53.40 | lmadsen | lol |
| 23:53.40 | I-MOD | nah, i've been inside all day |
| 23:53.46 | lmadsen | tzanger doesn't speak for Canada |
| 23:53.56 | tzanger | I don't speak at all, in fact |
| 23:54.16 | file | yes you do |
| 23:54.21 | I-MOD | he types |
| 23:54.21 | file | I have heard you before! |
| 23:54.26 | I-MOD | no need for spoken words |
| 23:55.22 | tzanger | I think you were ignoring me when I was speaking that one time |
| 23:55.26 | tzanger | crushed my spirit |
| 23:55.30 | tzanger | haven't spoken since |