| 00:26.33 | *** join/#asterisk-dev philippel_mac_ (~p_lindhei@pool-71-188-251-53.sttlwa.fios.verizon.net) |
| 00:35.36 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 01:29.23 | Kobaz | poke |
| 01:38.04 | snuff-work | ? |
| 01:38.36 | Kobaz | hehe |
| 01:38.48 | Kobaz | is there anything special i need to do to get mutexes usable across threads? |
| 01:38.50 | *** join/#asterisk-dev philippel_mac (~p_lindhei@pool-71-188-251-53.sttlwa.fios.verizon.net) |
| 01:39.01 | Kobaz | <PROTECTED> |
| 01:39.04 | Kobaz | is that everything? |
| 01:41.05 | Kobaz | i think i need to add more precise time logging |
| 01:49.51 | snuff-work | has no idea |
| 04:47.13 | *** join/#asterisk-dev luckman212_ (~irc@pool-173-77-253-145.nycmny.fios.verizon.net) |
| 04:57.01 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@c-67-170-173-27.hsd1.wa.comcast.net) |
| 05:56.00 | *** join/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 05:56.06 | rushowr | exit |
| 05:56.24 | *** join/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 06:10.41 | rushowr | hey gentlemen, I wonder if you could clear up a disagreement regarding SVN source.... My memory's fuzzy and I can't find a solid answer but.... |
| 06:11.01 | rushowr | IIRC, if I have a checkout from the asterisk/branches/1.8 trewe |
| 06:11.03 | rushowr | tree* |
| 06:11.29 | rushowr | whenever a new 1.8.x comes out, doesn't that branch hold that code? |
| 06:11.43 | rushowr | (as well as the tag for that full version number) |
| 06:14.51 | Kobaz | http://svn.asterisk.org/svn/asterisk/branches/1.8 has the newest 1.8 branch |
| 06:14.59 | rushowr | right on |
| 06:15.00 | Kobaz | it's pre-release though |
| 06:15.03 | rushowr | ouch |
| 06:15.04 | rushowr | ah |
| 06:15.14 | Kobaz | if you want the latest stable. check it out directly |
| 06:15.26 | rushowr | as in, it's basically the 1.8 "trunk" ? |
| 06:15.31 | Kobaz | ie: http://svn.asterisk.org/svn/asterisk/tags/1.8.2.3 |
| 06:15.32 | Kobaz | yeah |
| 06:15.36 | rushowr | right on |
| 06:15.53 | Kobaz | and then there's 1.8.3-rc2/ for bleeding edge stuff |
| 06:16.02 | rushowr | yeah, I was trying to get around having to either download a tarball manually or changing the URL for the svn co |
| 06:16.07 | rushowr | damn |
| 06:16.07 | Kobaz | yeah |
| 06:16.09 | rushowr | thanks mate |
| 06:16.34 | Kobaz | they should set up a finger server |
| 06:16.37 | Kobaz | like kernel.org |
| 06:16.49 | rushowr | yeah, that'd be most sweet |
| 06:17.21 | rushowr | well, I'm off to download 1.8.2.3 to see if it resolves an issue I'm having with Local channels :D thanks again |
| 06:17.59 | Kobaz | what issue? |
| 06:18.13 | rushowr | ah, huzzah! interest has been piqued! |
| 06:18.27 | rushowr | ok, SIP1 calls in a enters a queue |
| 06:18.28 | Kobaz | local channels are my thing |
| 06:18.46 | rushowr | resulting in a Local channel, which looks up the number to call the agent at over channel SIP2 |
| 06:19.08 | rushowr | SIP2 answers, and both SIP channels can talk (bridged) |
| 06:19.15 | rushowr | now, here's the fun |
| 06:19.24 | rushowr | the Local channel is specified with the /n opt |
| 06:19.46 | rushowr | because SIP2 (the agent) has dynamic feature codes to do various crap |
| 06:19.51 | Kobaz | heh |
| 06:20.11 | rushowr | and without it, SIP2 can't use 'em |
| 06:20.12 | rushowr | so..... |
| 06:20.24 | rushowr | Local stays inbetween SIP1 and SIP2 |
| 06:20.29 | Kobaz | yeap |
| 06:20.30 | rushowr | follow so far? |
| 06:20.31 | rushowr | k |
| 06:21.07 | rushowr | SIP2 presses ** which triggers an AGI that transfers SIP1 and SIP2 to a predefined conference |
| 06:21.10 | rushowr | or it's supposed to |
| 06:21.17 | rushowr | what I end up with is..... |
| 06:21.43 | rushowr | (doublechecking which channel hangs up/zombies and which does weird crap and then connects to the conf) |
| 06:22.26 | rushowr | one sec, need to grab the full log, my scrollback ios full |
| 06:22.34 | Kobaz | double checking as in? |
| 06:22.42 | Kobaz | the channel is, or you are looking for something? |
| 06:22.58 | rushowr | I'm looking] |
| 06:24.17 | rushowr | ok here we go |
| 06:24.44 | rushowr | SIP2 is sent directly to the conference |
| 06:25.34 | rushowr | SIP1 is just hung up |
| 06:25.50 | Kobaz | you want to send both to the conference? |
| 06:26.06 | Kobaz | supervisor monitoring/assistance? |
| 06:26.28 | rushowr | er...kinda...it's for a complicated as hell setup...Ik'm under NDA |
| 06:26.40 | rushowr | this section of the call is SIP1 = customer |
| 06:26.51 | rushowr | SIP2 = operator |
| 06:26.55 | Kobaz | you can tell me if it's for monitoring, i doubt that's really any kind of secret |
| 06:27.02 | rushowr | not for monitoring\ |
| 06:27.10 | Kobaz | people do that sort of stuff all the time, i have a monitoring setup for my queues |
| 06:27.19 | rushowr | it's for a company that does over the phone translations, hence the need for conferences |
| 06:27.21 | rushowr | ;-) |
| 06:27.31 | Kobaz | so you need someone in the middle |
| 06:27.34 | Kobaz | who can talk to both people |
| 06:27.35 | rushowr | the operator |
| 06:27.40 | Kobaz | i just wanna get the gist of it |
| 06:27.43 | rushowr | right |
| 06:27.46 | rushowr | here, do me a favor |
| 06:28.00 | Kobaz | so someone hits **, and they get assistance from the operator |
| 06:28.07 | rushowr | join me in a private, soi I can at least keep ir FAIRLY PRIVATE ;-) |
| 06:28.08 | rushowr | OOPS |
| 06:28.11 | rushowr | shit...sorry caps |
| 06:28.14 | Kobaz | heh |
| 06:28.53 | rushowr | basically, customer calls in, igets operator_queue...operator is reached, hits feature code to drop operator and customer injto a confernce |
| 06:29.07 | Kobaz | that's not very private if you talk in here still |
| 06:29.12 | rushowr | lol |
| 06:41.05 | *** part/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 06:56.20 | *** join/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 06:56.41 | *** part/#asterisk-dev rushowr (~rushowr@99-28-31-100.lightspeed.stlsmo.sbcglobal.net) |
| 07:35.33 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:35.35 | schmidts | good morning |
| 07:43.33 | schmidts | could some please take a look at https://reviewboard.asterisk.org/r/966/ my last question about flags. is there any nice function/api/whatever i can use to print a nice output of the flag value? |
| 07:59.39 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 08:03.09 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:1499:98c:646c:c8f9) |
| 08:15.00 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:15.00 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:16.59 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:20.06 | *** join/#asterisk-dev luckman212 (~irc@pool-173-77-253-145.nycmny.fios.verizon.net) |
| 08:28.13 | *** join/#asterisk-dev ApOgEE__ (apogee@gateway/shell/bshellz.net/x-qhtjflwmvviohwya) |
| 08:54.32 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 10:11.50 | *** join/#asterisk-dev frawd (~francois@3.Red-81-44-76.dynamicIP.rima-tde.net) |
| 10:15.41 | *** join/#asterisk-dev kaii (~kh@ciphron.de) |
| 10:28.30 | *** join/#asterisk-dev Jasnejac (kvirc@81.91.107.236) |
| 10:38.43 | snuff-home | schmidts: at a guess.. since they are all 'defines' there is unlikely a function like that.. |
| 10:39.26 | snuff-home | but check channels/sip/include/sip.h |
| 10:40.37 | snuff-home | should note that he cannot see code in question.. it never loads |
| 10:45.13 | *** join/#asterisk-dev frawd (~francois@3.Red-81-44-76.dynamicIP.rima-tde.net) |
| 11:00.17 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:1499:98c:646c:c8f9) |
| 11:13.46 | *** join/#asterisk-dev frawd (~francois@3.Red-81-44-76.dynamicIP.rima-tde.net) |
| 11:19.20 | schmidts | snuff-home i know these defines,but the question is if there is something to create a string out of these defines |
| 11:27.31 | schmidts | snuff-home i will take a look at the include file maybe i find something usefull ;) |
| 11:52.01 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 11:52.02 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:13.05 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:13.05 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 13:23.03 | schmidts | blitzrage ??? |
| 13:23.12 | blitzrage | ohai! |
| 13:23.33 | schmidts | are you incognito here today? |
| 13:24.58 | blitzrage | nah, just another window on another computer (this is my win7 system -- I'm doing some book review today) |
| 13:25.33 | schmidts | ;) |
| 13:40.05 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:41.03 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 13:41.03 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 14:28.44 | *** join/#asterisk-dev erinspice1 (~erin@nat/digium/x-byvhfvcdflneffub) |
| 14:31.13 | *** part/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 14:38.32 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 14:42.46 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 14:59.31 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 14:59.58 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.27.127.95.dynamic.adsl.gvt.net.br) |
| 15:09.25 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:09.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:21.09 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:21.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:23.21 | *** join/#asterisk-dev i_heart_asterisk (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 15:24.22 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-kibvwodwjotqcdyj) |
| 15:26.12 | i_heart_asterisk | hello |
| 15:32.42 | *** join/#asterisk-dev moy_ (~moy@h96-61-34-34.mdsnwi.tisp.static.tds.net) |
| 15:36.04 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:36.49 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 15:36.50 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:37.19 | *** part/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 15:40.26 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:40.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:45.45 | *** join/#asterisk-dev bklang__ (~bklang@c-76-97-4-235.hsd1.ga.comcast.net) |
| 15:47.29 | *** join/#asterisk-dev bklang__ (~bklang@c-76-97-4-235.hsd1.ga.comcast.net) |
| 15:49.18 | *** join/#asterisk-dev w9sh (~chatzilla@adsl-068-209-117-205.sip.asm.bellsouth.net) |
| 16:04.11 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 16:04.11 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:10.30 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:21.33 | Kobaz | what do you guys use for debugging threads |
| 16:21.52 | Kobaz | any decent gui tools these days |
| 16:22.02 | Kobaz | last stuff i used was gdb and emacs, which works well actuallyu |
| 16:33.53 | putnopvut | gdb + vim myself |
| 16:39.06 | philippel_mac | putnopvut: ping, got your email and just replied, thanks |
| 16:39.32 | philippel_mac | putnopvut: the one 'bug' I am curious about and will report if confirmed it is not operator error is |
| 16:40.32 | philippel_mac | When making CallCompletionRequest() and there is no call available (timer expired), or there is already a pending request (generic mode limited to 1), the the app returns with a non-zero code and hangs up the call to the feature code |
| 16:40.52 | putnopvut | philippel_mac: Yeah, hanging up the call seems...wrong in that case. |
| 16:40.56 | philippel_mac | no chance to tell the user anything, or give any form of intelligible sgnal back |
| 16:41.20 | philippel_mac | ok - so that is a valid bug for me to toss in the tracker then? |
| 16:41.26 | putnopvut | philippel_mac: yes sir! |
| 16:41.36 | philippel_mac | ok - check, will do |
| 16:41.45 | philippel_mac | let me bounce a couple more as mentioned int he email |
| 16:41.53 | putnopvut | fire away |
| 16:42.03 | philippel_mac | first - when the callback_macro is fired for a call competion |
| 16:42.30 | philippel_mac | nothing not even the INTERFACES channel variable is set yet (I looked in the code, it would appear that changing the order of setting that variable could address that |
| 16:43.02 | philippel_mac | beyond that, it would be useful to have a channel variable saying the extnesion that is about to be called back as well, is that something conceptually easy to add in at that time in the code? |
| 16:44.55 | putnopvut | Hm, let me think for a moment. |
| 16:45.05 | putnopvut | (also I'm pulling up the code :)) |
| 16:45.40 | philippel_mac | np - for what it's worth, when using the dialstring option, I've been able to jump through hoops to get this back, but if using the direct device dialback option, that would be the only place to get that |
| 16:45.55 | philippel_mac | where you could say "calling extnesion xyz" for example in the macro... |
| 16:47.12 | philippel_mac | while you are looking, here's the next one |
| 16:47.14 | putnopvut | So taking a look at the code, first off I would agree with you that setting CC_INTERFACES before calling the macro should cause no harm. In fact, that would give you the freedom to alter the variable at the point if you desire. |
| 16:47.35 | philippel_mac | yup, that's what that one looked like |
| 16:47.58 | philippel_mac | should I file that as another 'bug' / 'request' or are you confident enough to just do it now? |
| 16:48.41 | putnopvut | Honestly, it looks as easy as just swapping some lines of code. I could do that within the next few minutes. I'll take a second (and third) look just to be safe though. |
| 16:49.05 | philippel_mac | k I'll hold off filing it for right now |
| 16:49.13 | philippel_mac | next idea to bounce off you, 'device states' |
| 16:49.48 | philippel_mac | I'm wondering what it would take to have a state that could be connected to a custom device state as to wether an extension has one or more pending callback reqeusts? |
| 16:50.10 | philippel_mac | this would be conceptuall similar to Conferences with the exception that callbacks are dynamic |
| 16:50.55 | philippel_mac | my simplistic though is that you are already tracking the exact same state internally, so a call to something to create the state and then remove it would not be far fetched |
| 16:51.38 | philippel_mac | that - or maybe it needs to be configured for the potential extensions that you would want a callback state updated which would also be fine |
| 16:51.50 | putnopvut | So the idea would be that you could query a custom device state, and by doing so what you'd really be doing is seeing how many calls a specific extension has waiting? Did I understand that correctly? |
| 16:52.12 | philippel_mac | not quite, don't think you could see how many calls |
| 16:52.21 | philippel_mac | but for example, I could have a BLF for my feature code |
| 16:52.30 | philippel_mac | say in generic mode where I am limited to a single callback |
| 16:52.43 | philippel_mac | if I press it and it is not lit, if will attempt to do a Request |
| 16:52.51 | philippel_mac | if it is lit, it will do a cancel |
| 16:53.06 | philippel_mac | and once the callback timed out, since it is connected to the state, of course the blf will go off |
| 16:53.28 | philippel_mac | so I can be visually reminded that there is an active callback pending, in case I want to clear it because the guy jsut walked in my office |
| 16:53.33 | philippel_mac | make sense? |
| 16:53.34 | putnopvut | ahh, that makes sense. |
| 16:53.54 | philippel_mac | and I figured you have all that state, it's the hard job you are already doing |
| 16:54.22 | philippel_mac | so my simplistic mind makes me think it may be like a single line added to create and update some device state variagble |
| 16:54.32 | philippel_mac | and would be a HUGE boost in the quality of the feature code |
| 16:55.03 | putnopvut | So you're suggesting having some sort of predefined well-known one that we document somewhere. |
| 16:55.24 | philippel_mac | yes |
| 16:55.30 | *** join/#asterisk-dev guilhermebr (~Guilherme@187.114.232.71) |
| 16:55.32 | putnopvut | and by "one" i meant custom device state :) |
| 16:55.38 | philippel_mac | yes |
| 16:55.51 | philippel_mac | and it could be purely dynamic based on someone enacting the feature |
| 16:56.10 | philippel_mac | of if it's not that simple then we could define what extension needed it in the config file |
| 16:56.26 | putnopvut | Just thinking about it in theory, it seems like it would be very doable. Not necessarily a single line of code, but not a whole lot either. |
| 16:56.55 | philippel_mac | from what you described about manager events, seems like you are basically already tracking it for that so that is what I was thinking |
| 16:57.14 | philippel_mac | I'll turn on the logging per your email to get a better picture at leas tin the log of what is being reported |
| 16:58.00 | philippel_mac | so ... what is the policy these days wrt to 1.8 and new features, are we allowing new ones in or are they stalled until 2.10 ? |
| 16:59.00 | putnopvut | I *think* the policy is still not to add new features to 1.8. The thing is, I would say that the items you're suggesting are small enough and localized enough that I'd think that putting them in 1.8 wouldn't be a problem. |
| 17:00.07 | philippel_mac | would be great if that was the case, especially given there is no legacy base to be affected most likely, especially if they are localized to the ccss.c code |
| 17:02.09 | philippel_mac | ok - I think those are my main thrust. I would say moving the INTERFACE channel variable up, and adding a new channel variable that tells me what number I'm about to call as soon as the macro exits would be high on the list (almost consider them grey area bugs) |
| 17:03.16 | philippel_mac | and ... depending on what is returned for the chanel variable on who you are about to call, would be awsome if that is what the ccss code used to actually make the call - though just thinking out loud |
| 17:03.31 | putnopvut | Yeah, the cahnnel variable that tells you what number you're about to call is a little hazy to me. I know you gave the example of printing "about to dial extension xyz" earlier, but I'm curious what's different beetween that and CC_INTERFACES? |
| 17:03.35 | philippel_mac | I didn't look to see what the MACRO_EXTEN, MACRO_CONTEXT, etc were set, maybe you indirectly already have that |
| 17:03.59 | philippel_mac | CC_INTERFACES is not the same, it's the crux end result |
| 17:04.13 | philippel_mac | for example, if I had originally called a ringgroup (say exten 600) |
| 17:04.22 | putnopvut | Okay, I think I get what you're saying. |
| 17:04.28 | philippel_mac | well that is what you are going to fire me off to, 600 |
| 17:04.50 | philippel_mac | but I can do a quick check, like I said, I never looked at MACRO_EXTEN, etc. maybe you already have that? |
| 17:05.14 | putnopvut | I never explicitly set that in the code. It may be set correctly by default though |
| 17:05.28 | philippel_mac | anyhow the other important thing is the Request() and Cancel() behavior which I will file a bug for |
| 17:06.02 | philippel_mac | and then, the cusotm device state would be awesome to have as the third on the list, though clearly a feature request and not a 'bug' :) |
| 17:06.24 | philippel_mac | no .. checking to see what MACRO vairable are set to, brb 3 minutes ... |
| 17:08.14 | putnopvut | I'm currently test-compiling the switch to set CC_INTERFACES prior to calling the callback macro. |
| 17:08.47 | philippel_mac | ok checked the macro, no go: |
| 17:08.50 | philippel_mac | MACRO_PRIORITY=1 |
| 17:08.50 | philippel_mac | MACRO_CONTEXT=from-internal |
| 17:08.50 | philippel_mac | MACRO_EXTEN= |
| 17:08.58 | putnopvut | ah yuck |
| 17:09.06 | philippel_mac | from show channel where I put in a wait |
| 17:09.18 | philippel_mac | the first two are correct :) |
| 17:10.36 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 17:10.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:10.43 | philippel_mac | even the CDR at that point: |
| 17:10.46 | putnopvut | All right, so getting the extension that you're going to dial and putting that in a channel variable would not be a difficult thing to do considering that we have that information handy anyway. |
| 17:10.54 | philippel_mac | level 1: dnid= |
| 17:11.47 | philippel_mac | would be great, to be technically correct though, you probably just want to set the MACRO_EXTEN and make sure that that CDR dnid is also set right in case someone decides to do something crazy wrt to CDR(dnid) or CDR in general in such a macro |
| 17:12.20 | philippel_mac | then there wouldn't be a need to (I don't think) to add another channel variable though it obvioulsy woudn't hurt I dont think |
| 17:14.39 | putnopvut | I need to look at how the MACRO_* variables are set. I think those are set automatically by the macro when called into. So what I may need to do is just set the channel's extension and such before calling into the macro, and then it will be set properly. I'll take a look real quick to see if that's right. I'm just afraid that if I set MACRO_EXTEN directly in the CCSS code that it will be overwritten when I actually call ou |
| 17:14.39 | putnopvut | t to the macro. |
| 17:15.17 | philippel_mac | completely understand |
| 17:15.36 | philippel_mac | and by setting the extension first, it will probably fix your CDR dnid issue as well |
| 17:23.44 | philippel_mac | btw - logging to cli very helpful and fyi: |
| 17:23.45 | philippel_mac | [Feb 7 09:22:28] CC[10693]: ccss.c:3886 ccreq_exec: Couldn't find a core instance for caller SIP/3000 |
| 17:24.12 | philippel_mac | that's what the hangup when calling Request() with nothing to request or a pending request already there comes from |
| 17:26.35 | putnopvut | Right, that makes sense. What doesn't though is the fact that the call gets hung up. |
| 17:28.30 | putnopvut | philipp64|laptop: Okay, I think you'll like what I'm about to commit. It's going to make it so that CC_INTERFACES can be retrieved from the macro AND it's going to make MACRO_EXTEN in the macro be the extension that is to be called. |
| 17:30.27 | *** join/#asterisk-dev ccesario (~ccesario@187.75.139.188) |
| 17:30.36 | putnopvut | philippel_mac: ^^ sorry that was meant for you. |
| 17:30.45 | philippel_mac | putnopvut: awsome |
| 17:30.48 | putnopvut | Silly alphabetical order tab completion mumble mumble |
| 17:31.13 | philippel_mac | so should I file a bug so you can close against it or is that just unncecessary red tape? |
| 17:31.56 | philippel_mac | thinks still need to file the Request() hanging up bug (and the Cancel() which there is no log message to the CLI about) |
| 17:32.31 | putnopvut | Ah, don't worry about reporting it. |
| 17:32.41 | philippel_mac | putnopvut: btw, do you know off hand what phones might support any of the native mode stuff (sip phones) |
| 17:33.25 | putnopvut | I'm not sure that any have it yet. I believe that Siemens was planning to implement it in some of their phones but I don't know if any are available at this point. |
| 17:33.57 | philippel_mac | k - will ignore it for now then |
| 17:34.31 | philippel_mac | so ... who might be best to discuss/lobby wrt to the device state discussion (or have I peeked your interest enough :) ) |
| 17:35.10 | philippel_mac | thinks it's a good sign that several devs did not suddenly drop off of the irc since that last question :) |
| 17:35.48 | putnopvut | Well it definitely sounds interesting to me, it's just I don't have the necessary time to be working on Asterisk stuff in that amount of depth. |
| 17:36.35 | putnopvut | I don't think anyone has stepped up as the CCSS maintainer, but Richard Mudgett (who's not on IRC) is the person who wrote the ISDN CCSS stuff and I'd wager he'd end up being the guy that fields most issues related to CCSS. |
| 17:37.25 | philippel_mac | k - is he normally on irc (and if so what's his handle) or is there a better way to ping him? |
| 17:37.52 | putnopvut | I don't think I've ever seen him on IRC. |
| 17:40.58 | philippel_mac | putnopvut: thanks for everything, all and all, awesome feature from what I have tested so far. I'll grab the 1.8 head to get the changes, and track down Richard to see what his thoughts are on the device state stuff |
| 17:41.22 | philippel_mac | and get that other bug filed |
| 17:41.31 | putnopvut | It really feels good knowing that people are actually using the CCSS stuff :) |
| 17:42.21 | philippel_mac | once it hits FreePBX I suspect there will be a lot more, and once BLF enabled buttons are available, I suspect that user's will use it a lot more also |
| 17:42.47 | philippel_mac | (since the general rule of thumb is, without a button or menu item on a phone, 99% of users don't touch it and don't even know it exists) |
| 18:06.50 | philippel_mac | ? |
| 18:07.04 | philippel_mac | ok what's the format again to have a bug link created? |
| 18:14.40 | Corydon76-home | M12345 |
| 18:14.42 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0012345: [patch] call-limit is not an error, it should be logged as just a warning (it's a VERY TINY change) reported by caio1982 https://issues.asterisk.org/view.php?id=12345 |
| 18:15.37 | philippel_mac | thanks, so |
| 18:15.46 | philippel_mac | M18763 |
| 18:15.48 | MuffinMan | [acknowledged] [Asterisk] Core/CallCompletionSupplementaryServices 0018763: CallCompletionRequest() / Cancel() exit non-zero if no call/pending call reported by p_lindheimer https://issues.asterisk.org/view.php?id=18763 |
| 18:15.52 | philippel_mac | works :) |
| 18:28.33 | *** join/#asterisk-dev ccesario (~ccesario@189-29-59-116-ac.cpe.vivax.com.br) |
| 18:46.10 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 18:46.10 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:04.30 | *** join/#asterisk-dev moy (~moy@h96-61-34-34.mdsnwi.tisp.static.tds.net) |
| 19:31.31 | *** join/#asterisk-dev ccesario (~ccesario@187.75.139.188) |
| 19:34.54 | WIMPy | Ja, the ccss stuff was something I was very curious about. But after finding out how it works I have some lack of motivation to try it out. |
| 20:30.41 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:33.33 | *** join/#asterisk-dev Mw3 (~mw3@mw3.hu) |
| 20:37.06 | *** join/#asterisk-dev ClintGoudie-Nice (~clint@smtp.callware.com) |
| 20:42.05 | philippel_mac | WIMPy: just curious what you don't like about the ccss stuff, I've been playing with hit and it looks like a pretty good implementation so far? |
| 20:54.25 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 20:58.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 21:06.03 | WIMPy | The fact that you have to use feature codes. |
| 21:06.15 | WIMPy | I generally think they are a horrible hack. |
| 21:07.32 | WIMPy | If it was the real feature the phone would take care of all the user interface. |
| 21:08.34 | WIMPy | Just like when using a SIP phone that does it by subscribing to the dialled extension, which has been working great, but obviousely only for local extensions supporting devstate. |
| 21:09.14 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 21:13.26 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 21:59.41 | philippel_mac | WIMPy: from what I have looked at, CCSS does support native modes which could allow you to use phone built features though I don't know if any phones have that yet |
| 22:00.09 | philippel_mac | also - the way it is written , you can also build it directly in and, for example, have it automatic |
| 22:00.28 | WIMPy | On SIP only, and I haven;t got a clue where that's supported, either. |
| 22:00.42 | philippel_mac | also - it would appear from what I have seen so far that it would be very possible to create XML based applications on the phone |
| 22:01.04 | philippel_mac | WIMPy: looks like on ISDN also, what type of phone did you want to get it working with ? |
| 22:01.11 | WIMPy | But (almost) all legacy phones support it, but no ISDN suppport. |
| 22:01.37 | philippel_mac | all legacy phones? not sure what you mean or otherwise how they are supporting it? |
| 22:02.02 | WIMPy | ISDN :-) |
| 22:03.15 | philippel_mac | I thought ISDN support was built into it, and generically, it looks like it was designed flexibly so that channel drives will be able to add technology support as appropriate? |
| 22:04.02 | philippel_mac | I don't do anything with ISDN phones though so don't know beyond reading the notes on that front |
| 22:04.04 | WIMPy | It's definitely not supported on the user side. Only on the network side. |
| 22:05.02 | philippel_mac | ok - so is that an issue on the ccss side, or does there need to be some development on the isdn channel side? |
| 22:06.06 | WIMPy | Hmm. At least the channel driver. |
| 22:09.36 | *** join/#asterisk-dev luckman212 (~irc@pool-173-77-253-145.nycmny.fios.verizon.net) |
| 22:29.31 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 22:29.31 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 22:30.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 22:30.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:39.55 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:39.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:49.35 | *** join/#asterisk-dev russellb (~russell@asterisk/digium-open-source-team-lead/russellb) |
| 23:49.35 | *** mode/#asterisk-dev [+o russellb] by ChanServ |