| 00:00.54 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 00:04.48 | puzzled | ok, thanks |
| 00:05.00 | puzzled | for the feedback |
| 00:08.40 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:16.27 | *** join/#asterisk-dev Laureano (n=Laureano@OL93-199.fibertel.com.ar) |
| 00:47.08 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 00:59.28 | *** join/#asterisk-dev miguel3239 (n=elguero@ns1.nashuacs.com) |
| 01:05.37 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 01:17.01 | *** part/#asterisk-dev korihor (n=humberto@190.78.209.202) |
| 01:39.04 | tzanger | kpfleming: ping |
| 01:39.55 | file | The person you are attempting to ping is currently at home. Your ping may be responded to in approximately 12 hours. |
| 01:40.02 | tzanger | haha |
| 01:40.08 | tzanger | bugger probably didn't ship the package |
| 01:40.28 | file | have to fill out paperwork and stuff |
| 01:40.36 | file | and then get it approved by 10 people |
| 01:40.43 | file | and then wait 4-10 weeks |
| 01:41.35 | tzanger | if I gotta wait much longer the project *will* get delayed :-( |
| 01:42.09 | file | you should not speak of such things |
| 01:46.53 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:05.48 | *** join/#asterisk-dev korihor (n=humberto@190.74.120.245) |
| 02:33.42 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:41.12 | seanbright | ok, i could get used to this irsii/screen combo |
| 03:42.14 | lmadsen | seanbright: I did that for a many years |
| 03:42.16 | lmadsen | it works nice |
| 04:05.58 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584477.dsl.bell.ca) |
| 04:12.24 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 04:18.12 | moy | anyone familiar with dsp.c around? |
| 04:19.53 | moy | I want to speed up the MFC/R2 call setup, currently what is making it so slow is that the tone detection is taking twice as my early tests with spandsp |
| 04:20.28 | moy | I found that the thing is that there is a check for at least 2 hits before calling store_digits() |
| 04:20.42 | moy | so probably that should be configurable? |
| 04:23.24 | moy | alright, probably not the best hour to ask :-( |
| 04:55.50 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 04:59.09 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 05:05.23 | *** join/#asterisk-dev joshaidan (n=joshaida@S01060090f8009fa6.tb.shawcable.net) |
| 05:09.39 | *** join/#asterisk-dev moy (n=moyhu@189.169.206.200) |
| 05:32.40 | *** join/#asterisk-dev Corydon76-dig (i=silver@pdpc/supporter/bronze/Corydon76-home) |
| 05:32.40 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 05:32.53 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@217-133-80-112.b2b.tiscali.it) |
| 05:35.57 | *** join/#asterisk-dev snuff-home (i=snuff@C-59-101-248-31.bur.connect.net.au) |
| 05:55.19 | *** join/#asterisk-dev snuff-home (i=snuff@C-61-68-178-41.bur.connect.net.au) |
| 06:04.39 | *** join/#asterisk-dev Corydon76-dig (i=three@pdpc/supporter/bronze/Corydon76-home) |
| 06:04.39 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 06:17.17 | *** join/#asterisk-dev vicram (n=vr@bb219-74-51-1.singnet.com.sg) |
| 06:28.29 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:39.50 | *** join/#asterisk-dev friendly12345 (n=friendly@ppp59-167-167-175.lns1.mel4.internode.on.net) |
| 07:32.47 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 07:44.27 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@217-133-80-112.b2b.tiscali.it) |
| 07:57.48 | *** part/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 08:41.39 | *** join/#asterisk-dev Corydon76-dig (i=black@pdpc/supporter/bronze/Corydon76-home) |
| 08:41.39 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 08:44.07 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 09:09.43 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:15.08 | *** join/#asterisk-dev Corydon76-dig (i=beige@pdpc/supporter/bronze/Corydon76-home) |
| 09:15.08 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 09:15.12 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 09:20.32 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 09:50.58 | *** join/#asterisk-dev Corydon76-dig (i=seven@pdpc/supporter/bronze/Corydon76-home) |
| 09:50.58 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 10:02.34 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 10:06.10 | *** join/#asterisk-dev Corydon76-dig (i=black@pdpc/supporter/bronze/Corydon76-home) |
| 10:06.10 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 10:36.45 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 11:07.38 | *** join/#asterisk-dev fmueller (n=user@p548F789F.dip.t-dialin.net) |
| 11:10.42 | *** join/#asterisk-dev puzzled_ (n=patrick@puzzled.xs4all.nl) |
| 11:12.59 | *** join/#asterisk-dev oej (n=olle@12.179.175.2) |
| 11:12.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:13.41 | puzzled | hi |
| 11:20.22 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:29.24 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584477.dsl.bell.ca) |
| 11:46.13 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 11:48.36 | *** join/#asterisk-dev RoyK (n=roy@213.160.242.90) |
| 11:52.44 | *** join/#asterisk-dev ccesario (n=ccesario@multidrogas.ensite.com.br) |
| 12:01.01 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 12:03.24 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 12:05.26 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 12:06.29 | *** join/#asterisk-dev oej (n=olle@75.112.130.67) |
| 12:06.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:08.01 | oej | Morning |
| 12:15.40 | mvanbaak | hey |
| 12:19.50 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 12:23.47 | ctooley | oej, mvanbaak morning |
| 12:24.21 | *** join/#asterisk-dev ccesario (n=ccesario@multidrogas.ensite.com.br) |
| 12:25.58 | *** join/#asterisk-dev jeffg (i=LzrEgMg6@pdpc/supporter/active/jeffg) |
| 12:27.33 | ctooley | Does anyone else thing it would be useful to have a "sip ping peer PEERNAME" CLI command? |
| 12:28.04 | ctooley | Or, more appropriate for the Asterisk terminology, "sip qualify peer PEERNAME" |
| 12:28.27 | ctooley | But, a CLI command that does an Options ping to a peer and displays the results. |
| 12:29.18 | ctooley | Since Realtime peers and users down show up in "sip show peers", I think it would be handy to be able to test that they're available. |
| 12:42.43 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:42.43 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:50.41 | mvanbaak | hhmm, sounds like a good idea |
| 12:52.27 | ctooley | I constantly wonder how I'm going to know if all my realtime peers for this new product are actually available. |
| 12:54.05 | mvanbaak | cant you read that in the database ? |
| 12:55.28 | ctooley | how is that? |
| 12:55.41 | mvanbaak | I think sip updates the database |
| 12:55.43 | ctooley | I don't see a "last ping" kind of time |
| 12:57.06 | ctooley | I particularly like this message: __VOCAL_DATA_SHOULD_READ_THE_SIP_SPEC__ |
| 12:57.31 | ctooley | If only VocalData had broken just the Options messaging instead of half their SIP stack. |
| 13:01.32 | ctooley | is looking for where options responses are handled |
| 13:12.13 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:32.29 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-afe1ea465d06187b) |
| 13:35.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.231.245) |
| 13:38.47 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:53.13 | *** join/#asterisk-dev ACiDV (n=joel@122-205-229.dr.cgocable.ca) |
| 13:59.24 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 14:00.58 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 14:02.27 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:02.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:06.50 | *** join/#asterisk-dev qdk (n=qdk@195.184.98.6) |
| 14:17.39 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:17.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:18.33 | ctooley | dlsvpbx01*CLI> sip qualify peer 100 |
| 14:18.33 | ctooley | Sending Options ping to peer 100. |
| 14:18.33 | ctooley | [Apr 25 09:17:13] NOTICE[23497]: chan_sip.c:12637 handle_response_peerpoke: Peer 100 responded in 39ms |
| 14:18.51 | ctooley | mvanbaak, That's for a peer that has "qualify=no" |
| 14:19.51 | mvanbaak | not bad |
| 14:20.13 | ctooley | Can't do direct CLI output for the response |
| 14:22.10 | ctooley | I'll make a bug and, submit the patch and someone will need to "fix" it. |
| 14:31.13 | putnopvut | high-fives seanbright |
| 14:33.15 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:39.37 | seanbright | hmmm? |
| 14:40.26 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 14:44.22 | *** join/#asterisk-dev juanjoc (n=juanjoc@host30.190-31-245.telecom.net.ar) |
| 14:46.45 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:01.32 | *** join/#asterisk-dev jtodd (n=jtodd@204.11.231.198.static.etheric.net) |
| 15:11.26 | *** join/#asterisk-dev dawebber (n=dawebber@209.136.161.135) |
| 15:13.12 | dawebber | @anyone: anyone knows why cdr_pgsql lost its spool file capabilities in 1.4 (bug id=4909)? Most interestingly, does anyone care to look at a patch from me? |
| 15:14.08 | Corydon76-dig | dawebber: because there's spooling in the core |
| 15:14.08 | file | it never had it, the decision was made to do that in the core so all CDR modules could benefit |
| 15:15.08 | dawebber | not reading doxygen then :) hmm, ok, so noob question then: what's the magic directive to make it work. I tried setting spool= in cdr_pgsql to no avail |
| 15:15.26 | Corydon76-dig | Look in cdr.conf, not cdr_pgsql.conf |
| 15:16.19 | dawebber | nothing in the directions in that file |
| 15:16.21 | Corydon76-dig | and the directive is "batch" |
| 15:16.22 | dawebber | I'm on 1.4.19 |
| 15:16.27 | dawebber | batch |
| 15:16.34 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:16.34 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:17.01 | dawebber | so batch effective does the same as spooling? |
| 15:17.16 | Corydon76-dig | Not exactly, but that's what's in 1.4 |
| 15:17.27 | dawebber | I was under the impression that if the DB goes down, batch won't help |
| 15:17.35 | Corydon76-dig | You're correct |
| 15:18.15 | dawebber | ok, so it's isn't quite the same then---wouldn't this be a good feature to add to batch then? |
| 15:18.24 | Corydon76-dig | However, new features are not a candidate for 1.4 right now |
| 15:18.41 | dawebber | ok, can I buy a vowel for 1.6 then? :) |
| 15:18.53 | Corydon76-dig | You can help with the effort, sure |
| 15:19.06 | Corydon76-dig | I think Juggie or perhaps seanbright are working with spooling support |
| 15:19.40 | seanbright | points at Juggie and then hides |
| 15:19.44 | dawebber | this seems like an important piece to have |
| 15:19.50 | dawebber | Juggie, you are it |
| 15:20.05 | Corydon76-dig | I don't know, but I suspect that they need testing of their patch |
| 15:20.09 | dawebber | @JuggieL what are your thoughts |
| 15:20.14 | dawebber | I'm game |
| 15:20.37 | Corydon76-dig | seanbright: do you remember the issue number or the branch location? |
| 15:20.38 | file | he's probably at work... or not around |
| 15:20.58 | dawebber | and we are talking 1.6 now, right?> |
| 15:21.16 | Corydon76-dig | 1.6.1 or later. 1.6.0 is already feature frozen |
| 15:21.31 | dawebber | man, I'm always late to the table :) |
| 15:27.23 | dawebber | ok, thanks I'll wait for Juggie to come out of hibernation then |
| 15:27.54 | *** join/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) |
| 15:30.18 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:34.46 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:46.55 | Qwell | seanbright: my condolences. |
| 15:51.48 | Corydon76-dig | file: ping |
| 15:52.54 | file | Corydon76-dig: pong |
| 15:53.05 | Corydon76-dig | Is SVN painfully slow for you today? |
| 15:53.28 | file | nods |
| 15:53.31 | Qwell | Corydon76-dig: it's painfully slow here too |
| 15:53.39 | file | pokes russellb |
| 15:53.45 | Corydon76-dig | Really? That's very odd. |
| 15:53.46 | atis_work | putnopvut: ping |
| 15:54.10 | Corydon76-dig | I wonder if we have disk space issues |
| 15:54.59 | russellb | wibbles |
| 15:55.57 | russellb | <PROTECTED> |
| 15:55.59 | Corydon76-dig | Okay, now it's better |
| 15:56.14 | russellb | i'm sprinked fairy dust on it |
| 15:56.57 | putnopvut | atis_work: pong |
| 15:57.35 | atis_work | putnopvut: hey, i'm considering adding queue argument to change strategy.. how reasonable (or not) would that be.. |
| 15:57.50 | putnopvut | atis_work: could you explain what you mean? |
| 15:58.22 | atis_work | putnopvut: i'm thinking to copy strategy from queue to queue_entry and replace all checks for it |
| 15:58.44 | atis_work | putnopvut: so, default would be what's specified in queue.conf but you can override that with argument |
| 15:59.03 | atis_work | putnopvut: i'm just wondering, how two calls with different strategies will behave then.. |
| 15:59.10 | putnopvut | atis_work: I don't think that would work very well |
| 15:59.21 | putnopvut | Especially if one of the strategies you use is ringall. |
| 15:59.47 | atis_work | putnopvut: umm, i was thinking exactly for ringall.. some crazy business requirements :( |
| 16:00.15 | putnopvut | Yikes. |
| 16:00.52 | putnopvut | Well, because queue member status are based on their device state, I guess what you're asking about could work, it just might make for some confused queue members occasionally. |
| 16:02.46 | atis_work | putnopvut: i haven't thought of promlem at that point.. i suspect that all devices for ringall call should be set to ringing, so no problem with that.. i'm more worried about autofill |
| 16:03.37 | putnopvut | atis_work: I see what you mean...in most cases, autofill option is ignored if the strategy for the queue is ringall. |
| 16:04.06 | putnopvut | So if you had someone enter the queue, and their strategy was ringall, but you expected autofill to work, it would probably not. |
| 16:04.35 | atis_work | putnopvut: btw, why it's ignored, can't next call just ring agents with higher penalty? |
| 16:05.34 | putnopvut | atis_work: atis_work well, possibly, but typically, we do not ring the next higher penalty members just because the lower-penalty members are in use or ringing. |
| 16:08.16 | atis_work | putnopvut: well, thanks for comments. i'll probably going to mirror existing queue or write something in agi.. |
| 16:09.00 | atis_work | putnopvut: btw, would be really cool if next generation queue would be separated into FIFO and strategy commands |
| 16:09.20 | putnopvut | atis_work: what do you mean by that? |
| 16:09.45 | atis_work | huh, separate modules to hold calls and select devices |
| 16:10.04 | putnopvut | Oh, I see what you're saying. |
| 16:10.53 | atis_work | yup, something like one command to just hold calls (or order them by prio), play music, etc, and another one that signals that it can take N calls |
| 16:11.46 | atis_work | putnopvut: btw, how it's going with that next-generation queue.. i remember that something about that was mentioned some time ago.. |
| 16:12.29 | putnopvut | atis_work: yeah, um, it's not really progressing. |
| 16:14.18 | atis_work | ok, i should probably go home.. friday evening is not a good time for crazy business requirements.. :p |
| 16:14.30 | atis_work | thanks again :) |
| 16:14.40 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 16:14.40 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:29.08 | *** join/#asterisk-dev qdk (n=qdk@195.184.98.6) |
| 16:29.50 | seanbright | branch for the lossless CDR stuff is /team/group/NoLossCDR-Redux2 |
| 16:29.58 | seanbright | but its horribly out of date and far from done |
| 16:31.19 | dawebber | ok, and of course there is no hope for me to backport it to 1.4 for private testing |
| 16:31.21 | dawebber | correct? |
| 16:31.42 | dawebber | my test * box is 1.4 also..... |
| 16:32.23 | dawebber | @seanbright: were you guys specifically writing it for 1.6? |
| 16:32.44 | seanbright | dawebber: correct, trunk only. |
| 16:35.03 | seanbright | [A |
| 16:35.03 | seanbright | [Basda |
| 16:35.04 | seanbright | dasd |
| 16:35.04 | seanbright | a |
| 16:35.14 | seanbright | (woops! sorry!) |
| 16:35.19 | dawebber | @seanbright: ??? |
| 16:35.23 | dawebber | what lang was that? |
| 16:35.54 | seanbright | it was my-network-connection-died-inexplicably-and-i-was-frantically-pounding-on-the-keyboard... v2 |
| 16:36.19 | dawebber | ah, ok |
| 16:36.32 | seanbright | i think it will compile with gcc though. |
| 16:36.33 | seanbright | heh |
| 16:36.38 | dawebber | I was looking for a Klingon plugin for my IRC client meanwhile, just in case :) |
| 16:36.57 | seanbright | i'm sure its valid perl |
| 16:37.31 | jmls_home | seanbright: nah. |
| 16:37.47 | jmls_home | it's got to be Microsoft's new super-cool language. |
| 16:38.07 | seanbright | don't talk bad about MS |
| 16:38.08 | jmls_home | you know, the one noone understands, gets, uses or wants. |
| 16:38.14 | seanbright | i heart them |
| 16:38.35 | jmls_home | suddenly has a light bulb above his head. |
| 16:38.53 | jmls_home | _that's_ what Vista is written in ! |
| 16:39.13 | jmls_home | curses Vista for the 18th time today |
| 16:39.20 | dawebber | @seanbright: which source files does it live in? |
| 16:39.23 | seanbright | runs vista at home. i heart it. |
| 16:39.46 | seanbright | dawebber: main/cdr.c and cdr/*.c, but as i said, its out-dated |
| 16:39.49 | jmls_home | can't get the dammned thing to work properly with my nvidia 9600 gt and C&C 3 |
| 16:39.53 | seanbright | dawebber: you'd be better of starting from scratch |
| 16:40.02 | jmls_home | BSOD 4 times today. |
| 16:40.21 | jmls_home | goes back to lurking on the forum, muttering away to himself |
| 16:40.22 | seanbright | jmls_home: weak. i got a dell m1330 pre-loaded with it. so no problems. |
| 16:41.01 | jmls_home | boo! hiss! |
| 16:41.47 | seanbright | heh |
| 16:42.23 | dawebber | @seanbright: the only reason I'm asking is because I did a private patch for cdr_pgsql, not knowing you guys were dooing spooling at the core |
| 16:42.50 | dawebber | so I'm wondering if I could live with that, or start this -- which will be considerably more effort |
| 16:43.29 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 16:49.06 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 16:52.43 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 16:55.11 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:14.35 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-443b00bfc6af7e07) |
| 17:21.14 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 17:32.46 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 17:53.05 | moy | hello there, there is a small change that should be done in zaptel 1.4, in kernel/zaptel-base.c, function __do_dtmf, the 'F' should not be used to choose Forward R2 tones, otherwise when dialing the tone F it wont work. Could someone change it to 'O', that's the way the patch for chan_zap for R2 expect it to be |
| 17:53.58 | Qwell | moy: fOrward? |
| 17:53.58 | moy | also in start_tone() in the same file, when digitmode is any MFR2, chan->dialing should not be set to 1 |
| 17:54.01 | russellb | i thought mark already changed that .... |
| 17:54.10 | moy | Qwell: yup |
| 17:54.20 | moy | russelb: yeah he was supposed to :P |
| 17:54.26 | Qwell | huh |
| 17:54.31 | russellb | i remember seeing that commit though |
| 17:54.31 | Qwell | I think he changed it in the wrong place |
| 17:54.33 | Qwell | heh |
| 17:54.36 | russellb | ahh |
| 17:54.38 | Qwell | see line 3004 |
| 17:54.51 | Qwell | 1,2,3,4,5,6,7,8,9,A,B,C,D,E,O |
| 17:55.22 | moy | Ah!, well, I'm leaving by now, back in 1 hour ... will try that, thanks for the help ... tho the chan->dialing is still there |
| 17:57.01 | Qwell | moy: chan->dialing is set to 1 in DTMF too. |
| 17:57.15 | tzafrir_home | moy, wasn't this change already done? |
| 17:57.41 | Qwell | tzafrir_home: see above. I think it was done in the wrong place |
| 17:57.49 | Qwell | the 'F' vs 'O' thing |
| 17:59.46 | Qwell | r4130 |
| 18:01.16 | Qwell | http://pastebin.ca/997554 |
| 18:01.20 | Qwell | I think that is what was intended |
| 18:01.52 | Qwell | the case before and after the second block are M and R |
| 18:02.52 | Qwell | tzafrir_home, moy: would you agree with that? |
| 18:11.58 | Qwell | committed :p |
| 18:13.01 | tzafrir_home | sorry for the late call: that moves the change from "forward" to "reverse" |
| 18:13.23 | tzafrir_home | So "F" is used if Forward, right? |
| 18:13.56 | Qwell | O would be used for fOrward |
| 18:14.07 | Qwell | I'm pretty sure that this is what Mark meant to do in 4130 |
| 18:14.33 | Qwell | seeing as the case before the first block has 1-F, and the case in the second block has M, R, etc |
| 18:16.11 | kpfleming | Qwell: yes, that is correct |
| 18:16.25 | kpfleming | the digits to be played out are 1-9 and A-F, the mode selection characters should O and R |
| 18:16.49 | Qwell | excellent |
| 18:17.06 | Qwell | I'm not sure what moy was saying about chan->dialing though |
| 18:19.00 | kpfleming | i believe dialing should be set to non-zero any time there is a string of tones being played out |
| 18:21.16 | *** part/#asterisk-dev dawebber (n=dawebber@209.136.161.135) |
| 18:21.33 | russellb | yeah, i'm pretty sure that is the meaning of that flag |
| 18:23.37 | ZaVoid | can someone look at a backtrace for me? |
| 18:23.43 | ZaVoid | 1.4.19 is contstantly crashing on me |
| 18:24.01 | ZaVoid | as soon as i dial out sip it dies |
| 18:24.36 | russellb | pastebin it |
| 18:24.39 | ZaVoid | http://www.woot.us/backtrace.txt |
| 18:24.42 | ZaVoid | err pastebin |
| 18:24.43 | ZaVoid | one sec |
| 18:24.49 | russellb | that's fine too |
| 18:26.00 | russellb | ahh ... sin is NULL ... |
| 18:26.03 | ZaVoid | http://pastebin.ca/997588 |
| 18:26.11 | ZaVoid | line nubmers A:) |
| 18:26.21 | tzafrir_home | Maybe moy's original problem was that the code originally mapped 'O' to ZT_TONE_MFR2_FWD_10 + ('O' - 'A')? |
| 18:26.34 | ZaVoid | sin? |
| 18:26.43 | tzafrir_home | (instead of (ZT_TONE_MFR2_FWD_10 + 6)? |
| 18:27.10 | ZaVoid | howdy russellb btw :) |
| 18:27.40 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 18:27.50 | russellb | hey |
| 18:28.58 | ZaVoid | so whats the mean sin is null? |
| 18:28.58 | ctooley | russellb, sin shouldn't need to be populated though if peer contains data. At least I hope not, I just wrote code that uses it with a NULL sin. |
| 18:28.59 | ZaVoid | can someone tell me what sin is for? |
| 18:29.00 | ZaVoid | <-- stupid |
| 18:29.15 | ctooley | struct sockaddr_in *sin |
| 18:29.21 | ZaVoid | ctooley: my configs worked fine on 1.4.15 though |
| 18:29.24 | ZaVoid | ok |
| 18:29.33 | ctooley | you did say 1.4.19, right? |
| 18:30.02 | ZaVoid | this is 1.4.19 |
| 18:30.05 | ctooley | yeah |
| 18:30.06 | ZaVoid | my good stable build is 1.4.15 |
| 18:30.50 | ctooley | russellb, ah, I was looking in find_peer, not in realtime_peer |
| 18:31.35 | ZaVoid | hey ctooley you ever see where agi pauses in the middle of returning results ever? then 10 seconds later starts again |
| 18:32.44 | ctooley | uhhh, no |
| 18:33.03 | ZaVoid | i got that happening too on one of my boxes during 1 hour of the day :) |
| 18:33.06 | ZaVoid | but thats minor to this issue |
| 18:33.25 | putnopvut | seanbright: ping |
| 18:34.05 | ctooley | ZaVoid, someone smarter than me will have to figure your problem out. I was working in "find_peer" today, but this is in a different part of the code which find_peer calls. |
| 18:34.38 | ZaVoid | i hear russellb is s smart guy :) |
| 18:35.10 | ctooley | I know he is, he's also occasionally busy. |
| 18:35.13 | putnopvut | ZaVoid: I believe you are encountering the following bug, which was fixed shortly after 1.4.19 was released. |
| 18:35.16 | putnopvut | M12362 |
| 18:35.17 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0012362: Asterisk crashes everytime i try to dial a realtime peer. e.g.DIAL(SIP/peer/number,60,tTwW) reported by vinsik http://bugs.digium.com/view.php?id=12362 |
| 18:35.23 | ZaVoid | thanks let me look |
| 18:35.52 | ZaVoid | ahh ya know what MuffinMan |
| 18:35.54 | ZaVoid | that makes sesne |
| 18:36.00 | ZaVoid | 1/2 my carriers are in realtime... |
| 18:36.06 | ZaVoid | thsoe are the ones that crash it |
| 18:36.12 | ZaVoid | 1/2 still in sip.conf and those aren't crashing |
| 18:36.36 | putnopvut | yep, that backtrace looked awfully familiar. |
| 18:36.49 | seanbright | putnopvut: pong |
| 18:36.51 | ZaVoid | cool thanks guys |
| 18:37.05 | ZaVoid | so what about the agi freezing for like 10 seconds and then starting again.. |
| 18:37.10 | ZaVoid | i don't even have any good trace to show for that |
| 18:37.13 | putnopvut | seanbright: I recall you talking to file recently about something regarding audiohooks, and I was curious what it was you were doing? |
| 18:37.15 | ZaVoid | ethereal shows a pause in activitiy |
| 18:37.43 | seanbright | putnopvut: i have sales managers that are whispering to reps during calls |
| 18:38.17 | seanbright | putnopvut: based on a small change to chanspy, the manager can press '*' to "barge in" to the call, which i accomplish by just attaching a second whisper hook on the bridged peer |
| 18:38.20 | putnopvut | seanbright: okay, I've been tasked with implementing something (a way to whisper to both sides of a call in chanspy), but I wasn't sure if I'd be stepping on your toes with something you've done. |
| 18:38.33 | putnopvut | seanbright: ah ha! barging is what I was going to write. |
| 18:38.40 | seanbright | putnopvut: right, i've implemented that, but its not mine |
| 18:38.44 | putnopvut | So a second audiohook does the trick. |
| 18:38.46 | Qwell | not yours? |
| 18:38.53 | seanbright | putnopvut: belongs to my company |
| 18:38.57 | seanbright | err |
| 18:38.59 | Qwell | boo! |
| 18:39.02 | seanbright | Qwell: belongs to my company |
| 18:39.04 | putnopvut | seanbright: gotcha... |
| 18:39.04 | ZaVoid | AGI Rx << GET VARIABLE CCPIN |
| 18:39.04 | ZaVoid | AGI Tx >> 200 result=0 |
| 18:39.05 | ZaVoid | 10 second pause........ |
| 18:39.05 | ZaVoid | AGI Rx << SET VARIABLE ACCTFOUND "t" |
| 18:39.06 | ZaVoid | AGI Tx >> 200 result=1 |
| 18:39.09 | ZaVoid | very strange |
| 18:39.25 | ZaVoid | and i know the sql query is done and took .002 seconds or somthing like that |
| 18:39.36 | seanbright | putnopvut: but basically, i just create a second whisper hook on the bridged peer, and then spit the audio out both sides |
| 18:39.41 | seanbright | putnopvut: trivial to implement |
| 18:39.46 | putnopvut | seanbright: sounds like it. |
| 18:40.09 | putnopvut | I wasn't sure if I should instead implement a "barge" audiohook type, but if a second whisper hook can be used, might as well just do that. |
| 18:40.12 | seanbright | putnopvut: the downside is that on the calls recording, you can not hear the sales manager at all, be it whispering or barging |
| 18:40.37 | seanbright | putnopvut: which is bad for us, so i changed the audiohooks code so that it whispers before it spies |
| 18:40.41 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:40.49 | seanbright | putnopvut: but this has the downside of the whispering hearing him/herself |
| 18:40.59 | seanbright | s/whispering/whispering party/ |
| 18:41.26 | seanbright | putnopvut: so i'm still trying to work that part out |
| 18:41.37 | ZaVoid | any ideas? |
| 18:41.53 | putnopvut | seanbright: okay, I'll work on getting some sort of official implementation of the barge mode for chanspy. |
| 18:42.06 | seanbright | putnopvut: wonderful. |
| 18:42.52 | seanbright | putnopvut: file created a branch for audiohook chaining (which would make my monitor/whisper problem easier to resolve) but i don't think he's had the time to work on it yet |
| 18:43.10 | seanbright | putnopvut: and therefore i am not speaking to him |
| 18:43.15 | seanbright | ;-) |
| 18:43.16 | putnopvut | lol |
| 18:43.18 | file | :D |
| 18:43.28 | seanbright | who's that? did someone say something? |
| 18:43.30 | seanbright | hehe |
| 18:43.43 | Qwell | <putnopvut> lol |
| 18:43.43 | Qwell | <seanbright> who's that? did someone say something? |
| 18:43.45 | Qwell | nope |
| 18:43.49 | seanbright | weird |
| 18:43.52 | file | I feel so alone! |
| 18:43.53 | putnopvut | seanbright: thanks, I appreciate the feedback. |
| 18:44.00 | putnopvut | gets to work |
| 18:44.20 | seanbright | putnopvut: 30 lines of code, tops. |
| 18:44.56 | ZaVoid | any ideas on the agi freeeze? |
| 18:45.09 | putnopvut | ZaVoid: no idea man :( |
| 18:45.09 | ZaVoid | or how to debug it better.... debug level 6 doesn't help |
| 18:46.31 | ctooley | ZaVoid, you might strace your AGI |
| 18:51.14 | ZaVoid | err |
| 18:51.22 | ZaVoid | strace it |
| 18:51.24 | ZaVoid | gotcha |
| 18:54.25 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:08.11 | Juggie | ZaVoid, i think i've seen an agi freeze before |
| 19:08.16 | Juggie | is it effecting all channels or just one? |
| 19:08.43 | ZaVoid | all channels |
| 19:08.47 | *** join/#asterisk-dev qdk (n=qdk@213.173.230.2) |
| 19:09.06 | ZaVoid | call comes in.. i do a query... like account balance.... and while its returning the values.. it "freezes".. then continues on 10 seconds or so later... |
| 19:09.17 | ZaVoid | and does it on all scripts at times |
| 19:09.57 | ZaVoid | althought i just noticed juggies that they have different(slight) versions of php installed.. |
| 19:13.06 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 19:13.43 | moy | Qwell: I'm back |
| 19:13.45 | moy | sorry |
| 19:13.51 | moy | getting back to the chan->dialing |
| 19:13.59 | moy | for MF tones that should not be there |
| 19:15.01 | moy | MF tones must be continuous and allow the tone generation while read()ing, with chan->dialing = 1 when read() is called only zeroes are read, it's a fake read |
| 19:15.18 | moy | and I agree with the fix you put in pastebin |
| 19:15.25 | Qwell | that fix was committed |
| 19:15.55 | moy | including the chan->dialing thing? |
| 19:15.58 | Qwell | no |
| 19:16.00 | Qwell | just the pastebin |
| 19:18.07 | moy | kpfleming: chan->dialing set for DTMF is ok, but for R2 is disruptive, I need to let the tone being generated continously while I read() the other end tone. with chan->dialing any read() while generating tone return just zeroes |
| 19:19.53 | kpfleming | ahh.. OK, i forgot about that aspect of R2 signaling |
| 19:20.10 | kpfleming | yes, i agree, there is no need for dialing to be set, because you won't ever be sending strings of tones anyway, only single tones |
| 19:20.25 | moy | agreed |
| 19:24.35 | *** join/#asterisk-dev Skarmeth (n=Skarmeth@iris.aspec.com.br) |
| 19:24.43 | Skarmeth | moy, hi |
| 19:25.53 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 19:27.00 | Skarmeth | Digium guys, there is any incompatibility between Zaptel 1.4.10 and Digium TE220B card on kernel 2.6.24.4 kernels on 64 bits platform's (specially Fedora 8 64 bits)? |
| 19:28.49 | *** join/#asterisk-dev korihor (n=humberto@190.78.209.202) |
| 19:29.32 | Qwell | Skarmeth: I have not heard of any such thing. If you're having issues, you should call Digium support. |
| 19:31.27 | jsmith | Skarmeth: Not that I'm aware of... |
| 19:32.12 | ZaVoid | hey juggie? |
| 19:36.22 | *** join/#asterisk-dev oej (n=olle@75.112.130.67) |
| 19:36.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:37.04 | kpfleming | Fedora tends to use 4K stacks in their kernels, which can cause problems for Zaptel |
| 19:37.26 | kpfleming | there have been reports of problems with the VPMADT032 initialization process in that evironment (on asterisk-users) |
| 19:37.37 | kpfleming | i would suggest trying SVN branch 1.4 of Zaptel to see if it helps, Skarmeth |
| 19:37.50 | *** join/#asterisk-dev qdk_ (n=qdk@213.173.230.3) |
| 19:38.44 | Skarmeth | this one ? http://svn.digium.com/svn/zaptel/branches/1.4 |
| 19:39.41 | kpfleming | yep |
| 19:42.36 | M1s3ry | omg... I've never seen kpfleming here. X0 |
| 19:42.45 | M1s3ry | wait... that looks wrong |
| 19:42.49 | M1s3ry | =0 |
| 19:42.58 | file | kpfleming is everywhere |
| 19:43.10 | Qwell | omnipresent? |
| 19:43.54 | M1s3ry | true true.... |
| 19:44.05 | Corydon76-dig | Some are omnierroneous |
| 19:44.57 | jsmith | kpfleming is a lot of places, but he tends to be busy working instead of just lurking in IRC |
| 19:45.12 | file | keeping the executive folk off of our backs. |
| 19:46.25 | Juggie | ZaVoid, yes? |
| 19:46.44 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 19:46.50 | kpfleming | but IRC is always on my screen (one of the three) |
| 19:47.00 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:48.13 | ZaVoid | think the php version could matteR? |
| 19:49.15 | M1s3ry | wishes he had three screens.... |
| 19:49.47 | M1s3ry | kpfleming, maybe you could req one for me? :D |
| 19:49.48 | file | gives M1s3ry a screen door |
| 19:50.00 | M1s3ry | jumps in |
| 19:51.11 | kpfleming | it's a trap! |
| 19:51.33 | file | transfers M1s3ry to Canada to work in a slave call center |
| 19:51.46 | M1s3ry | omg... I was so about to say I was in canada |
| 19:52.37 | M1s3ry | I like it in the HSV, where the blood suckers take pints of blood from your arm, leaving you half asleep at work |
| 19:53.30 | Qwell | ^ huge mosquitoes. |
| 19:54.05 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:54.07 | M1s3ry | if they drive a bus in our parking lot, then yes |
| 20:04.42 | Skarmeth | kpfleming, no sucess with the 1.4 branch, same crazy red blinking lights |
| 20:04.55 | kpfleming | any messages in the kernel log |
| 20:04.59 | *** part/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) |
| 20:05.44 | moy | Qwell: now that kpfleming has agreed, do you think you could commit that fix, some people is going to try the chan_zap patch and they will need an updated zaptel |
| 20:08.14 | korihor | moy: i waiting like you :) |
| 20:09.29 | moy | korihor: hello, yeah, if we're lucky we will get that commited soon |
| 20:10.04 | korihor | moy: cool |
| 20:11.37 | moy | there is other improvement I want to discuss with someone who actually understands dsp.c :-) |
| 20:12.14 | korihor | moy: coppice :p |
| 20:13.40 | moy | hehe yeah, he is one of those. The MF R2 detection in dsp.c is quite slow for setting up calls, it could be improved for R2 if the code in dsp.c mf_detect() avoided requiring 2 hits per tone |
| 20:14.40 | Qwell | moy: that chan->dialing = 1; just needs to be removed, right? |
| 20:14.55 | moy | yes, just removed for the cases where any R2 MF mode is enabled |
| 20:16.32 | moy | Qwell: any idea who should I talk to regarding the issue with dsp.c? |
| 20:17.29 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 20:17.47 | Qwell | I understand dsp.c for the most part now |
| 20:18.14 | Qwell | moy: for the chan->dialing thing, would you mind attaching a patch to a bug? |
| 20:18.21 | jpeeler | bt |
| 20:18.30 | Qwell | I want to make sure that A) I don't miss anywhere, and B) credit you properly |
| 20:19.03 | jpeeler | russellb: your parking_updates changes conflicted with one of my bug fixes |
| 20:20.08 | russellb | heh |
| 20:20.11 | russellb | sorry :-p |
| 20:20.16 | ctooley | Corydon76-dig, I updated 12524. I would really appreciate some advice, I'm not afraid of fixing it, I'm just not seeing exactly what you're talking about. Feel free to berate me, my code is usually far from flawless. :) |
| 20:20.29 | russellb | basically, it's now the parkinglot that is in the park_call_full_args struct |
| 20:20.33 | russellb | instead of the arg to the function |
| 20:20.40 | Skarmeth | kpfleming, no, just board load process |
| 20:20.45 | jpeeler | yes, but it didn't actually need to be an argument to the function |
| 20:21.00 | Skarmeth | I removed the echo can module.... |
| 20:21.10 | Skarmeth | I am trying without it |
| 20:21.20 | Corydon76-dig | ctooley: "if (cond) {" and "} else {" |
| 20:21.33 | Corydon76-dig | ctooley: all on one line, not interspersed |
| 20:22.17 | Corydon76-dig | not "if (cond)\n{" or "}\nelse {" |
| 20:22.20 | kpfleming | Skarmeth: ok.. beyond this point you should really contact Digium support |
| 20:22.40 | russellb | jpeeler: ok, so remove it from the struct |
| 20:24.25 | Corydon76-dig | ctooley: I probably could have fixed it myself, but I prefer patches that are ready to go... |
| 20:25.15 | ctooley | Corydon76-dig, I'd prefer to know where the errors are so I can attempt not to make the same mistakes in the future. |
| 20:25.36 | Corydon76-dig | ctooley: It's all in the CODING_GUIDELINES document |
| 20:26.01 | ctooley | I'm guessing line 104 of the patch should not be wrapped in {} as well. |
| 20:27.13 | Corydon76-dig | ctooley: No, keep those |
| 20:27.40 | Corydon76-dig | ctooley: that was the most recent change... ALWAYS wrap code blocks in braces, even if not strictly necessary |
| 20:27.41 | ctooley | But, I'm not actually seeing where in the patch you're talking about that I can condense an if/else to one line, unless I remove comments |
| 20:28.01 | Corydon76-dig | Lines 98-99, for example |
| 20:28.02 | ctooley | Good, I prefer bracing |
| 20:28.11 | Corydon76-dig | 102-103 |
| 20:28.33 | ctooley | OH! I see what you mean now |
| 20:28.34 | ctooley | ok |
| 20:28.43 | Corydon76-dig | 106-108 |
| 20:28.46 | ctooley | no newlines around the braces |
| 20:28.53 | seanbright | ding ding ding |
| 20:28.53 | Corydon76-dig | right |
| 20:29.03 | ctooley | I thought you meant condensing an entire if/else to a single line, I misread your comment. |
| 20:29.24 | ctooley | been a long week |
| 20:29.31 | Corydon76-dig | Understood |
| 20:29.55 | Corydon76-dig | Technically, 93-94 should have braces around them, as well |
| 20:30.04 | moy | Qwell: sure |
| 20:30.25 | ctooley | I'll fix it |
| 20:30.30 | Corydon76-dig | and add braces for 53 |
| 20:31.05 | ctooley | ok |
| 20:31.12 | ctooley | I'll go through the whole thing and fix those. |
| 20:31.51 | Corydon76-dig | Just the lines that your patch touches |
| 20:31.58 | Corydon76-dig | and related lines |
| 20:32.06 | Corydon76-dig | You don't need to do the entire file |
| 20:32.57 | Corydon76-dig | In fact, I'd prefer any patches that did go through and modify the entire file to be separate from patches with functionality changes |
| 20:33.07 | ctooley | Oh, I was just going fix the stuff that I did. |
| 20:33.15 | Corydon76-dig | Right, that's good |
| 20:33.16 | ctooley | There's no way I'm going to try to reformat all of chan_sip |
| 20:33.24 | Corydon76-dig | Heh |
| 20:33.31 | Qwell | ctooley: where's your sense of adventure? :) |
| 20:33.41 | Qwell | common sense must be overriding it. |
| 20:33.41 | ctooley | There is of course the question of whether this is even a desirable patch. |
| 20:33.49 | outtolunc | suggests left justify everything <G> |
| 20:34.00 | ctooley | Qwell, definitely laziness, I have no common sense |
| 20:34.08 | Qwell | heh |
| 20:34.27 | ctooley | If I did, I wouldn't have had to ask 4 questions of Corydon76-dig because I misread a very simple comment. |
| 20:37.04 | *** join/#asterisk-dev oej (n=olle@12.179.175.2) |
| 20:37.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:38.28 | kpfleming | oej is internally implemented using SIP, it appears |
| 20:39.05 | russellb | orly? |
| 20:40.15 | Skarmeth | kpfleming, I called my reseller and asked it to replace the card |
| 20:40.20 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 20:40.21 | kpfleming | based on his twitter |
| 20:40.34 | russellb | oh, i see it, hehe |
| 20:40.35 | Skarmeth | kpfleming, thank's |
| 20:41.07 | kpfleming | sure |
| 20:42.34 | ctooley | Corydon76-dig, posting new file |
| 20:42.55 | file | is posted |
| 20:43.58 | Corydon76-dig | copies file to his home directory |
| 20:45.37 | Qwell | moy: so it is just those 2 then? perfect |
| 20:46.20 | moy | Qwell: yup, I was wondering if we should do it with ZT_DIAL, but in anycase I don't see much use to R2 MF with ZT_DIAL |
| 20:47.06 | Qwell | fixed :D |
| 20:50.53 | Qwell | moy: hopefully my commit message did the patch justice.. |
| 20:50.54 | moy | Qwell: thanks sir! |
| 20:51.02 | Qwell | if you think it should be revised, let me know |
| 20:51.11 | moy | sure |
| 20:53.29 | *** join/#asterisk-dev jtodd (n=jtodd@204.11.231.198.static.etheric.net) |
| 20:54.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:05.07 | moy | Qwell: so, what about the tone hits in dsp.c, mf_detect() around line 901, 2 hits are required to store the digit, that slows down the MF R2 call setup, what about making that configurable? I suppose I can do it and post it in mantis, just wanted to hear some comments before writing it |
| 21:07.30 | Qwell | hmm, does it make sense for mfr2 to use the same mf_detect function? |
| 21:07.53 | Qwell | seems a bit bell specific. (I know almost nothing about mf/mfr2) |
| 21:08.42 | moy | I cannot claim being an expert on the tone generation/detection, but Mark was the one adding the R2 tone detection there, so I assume he tought it makes sense |
| 21:09.19 | moy | btw, I am talking about team/markster/mfr2 branck dsp.c |
| 21:09.27 | Qwell | let me check that out |
| 21:09.28 | moy | s/branck/branch |
| 21:14.16 | Qwell | moy: check out DTMF_HITS_TO_BEGIN |
| 21:14.32 | Qwell | what if something like that were added, similar to the mf_gsize array? |
| 21:15.01 | Qwell | if mfr1 always needs 2, and mfr2 always needs 1... |
| 21:15.14 | moy | checking ... |
| 21:16.24 | moy | ah!, yeah, just like that :) |
| 21:16.45 | Qwell | why does mfr2 only need one hit? |
| 21:16.57 | Qwell | is there like nothing else going on at the time that could be non-mf? |
| 21:17.22 | Qwell | like, if there is audio, it *is* mf, we just need to find which? |
| 21:21.01 | moy | R2 MF tones are for call setup, the speech path is not open |
| 21:21.09 | moy | when open, I turn off the detector |
| 21:21.21 | moy | yes |
| 21:21.24 | moy | just what you said |
| 21:23.02 | oej | So what's really the policy for 1.6.0 beta? Someone just added a new dialplan function. Just trying to learn. |
| 21:23.21 | russellb | who just added a function? |
| 21:23.26 | russellb | it's supposed to be feature frozen. |
| 21:24.10 | russellb | and are you sure you weren't looking at a commit that blocked it from 1.6.0 |
| 21:24.11 | russellb | ? |
| 21:24.40 | oej | No, the MEETME stuff. I'll check again. |
| 21:25.50 | jsmith | Quick question... do hints work in realtime? |
| 21:26.00 | oej | No |
| 21:26.11 | jsmith | Fair enough ;-) |
| 21:26.14 | jsmith | That's what I was looking for |
| 21:26.33 | oej | Realtime dialplan doesn't support it |
| 21:26.42 | oej | Tilghman has been working on finding a fix |
| 21:26.46 | jsmith | OK. |
| 21:27.03 | jsmith | Just trying to help a friend... I'll just tell him "they don't work" and forget about it |
| 21:27.07 | Corydon76-dig | I have? |
| 21:27.13 | seanbright | heh |
| 21:27.16 | russellb | you might need to point me to a rev ... i don't see any dialplan functions in meetme in 1.6.0 |
| 21:27.18 | seanbright | confusion abounds |
| 21:27.26 | russellb | Corydon76-dig was working on variables for hints in the dialplan |
| 21:27.32 | Corydon76-dig | The only thing I was working on (and it's now committed) is the ability to use pattern matches for hints |
| 21:27.43 | russellb | yeah, that was it |
| 21:28.23 | jsmith | Yeah, I knew about that... |
| 21:28.40 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 21:29.09 | Skarmeth | have a nice weekend guys |
| 21:29.18 | oej | russellb: I might have misread, but I just wanted to clear that we're actually in freeze |
| 21:29.29 | russellb | yup |
| 21:29.50 | jpeeler | that could have been me |
| 21:29.57 | jpeeler | are you talking about meetme_info? |
| 21:29.57 | Corydon76-dig | Correct, bug fixes only |
| 21:30.02 | oej | right |
| 21:30.51 | jpeeler | actually... |
| 21:31.03 | jpeeler | file is the one who committed my patch |
| 21:31.37 | Corydon76-dig | Yes, but that was only in trunk |
| 21:31.51 | Corydon76-dig | the dialplan function didn't go into 1.6.0 |
| 21:33.12 | jpeeler | ok then file made no mistake |
| 21:33.40 | file | blame me anyway! for nothing. |
| 21:33.55 | Corydon76-dig | It's file's fault! |
| 21:34.03 | jpeeler | file: i have to have a scape goat |
| 21:34.25 | jpeeler | and apparently it's one word |
| 21:34.34 | Corydon76-dig | scapekitty! |
| 21:34.40 | jsmith | scapemuffin! |
| 21:41.24 | oej | Hey Russell - you merged in the chanvar SIPPEER change that I thought I couldn't merge to 1.6.0 |
| 21:41.26 | oej | he he |
| 21:41.36 | russellb | ooh |
| 21:41.38 | oej | Thank you. |
| 21:41.52 | russellb | well the message said it came from 1.4 |
| 21:41.55 | oej | tries to catch up with old commits |
| 21:41.57 | russellb | so, if that was the case, i figured it was fine |
| 21:42.37 | oej | Well, then I wrote a bad message that fooled you. I have a branch for 1.4 so I brought it in to trunk, but bot into 1.4 as it is a change/additional function. |
| 21:44.03 | russellb | oh, ha |
| 21:44.06 | russellb | oh well :) |
| 21:45.00 | oej | That's just life. You brought in another commit that I forgot to merge with 1.6.0, so thank you for that. |
| 21:45.33 | russellb | np, i occasionally check the list to see what's pending |
| 21:47.38 | oej | codefreeze: On line? |
| 21:47.59 | *** join/#asterisk-dev matthew_i (n=mnichols@pdpc/supporter/sustaining/MasterYoda) |
| 21:48.12 | file | oej: he is not. |
| 21:48.17 | matthew_i | should the channel be locked when calling ast_channel_datastore_find? |
| 21:48.19 | file | he'll be back next week |
| 21:48.54 | file | matthew_i: yes. |
| 21:48.59 | matthew_i | ok |
| 21:49.51 | oej | Time to explore Orlando. |
| 21:50.04 | oej | Will arrive to Huntsville Sunday by lunchtime |
| 21:50.12 | jsmith | oej: C'mon... you'd rather go shopping than close bugs? |
| 21:50.23 | jsmith | oej: I get into Huntsville on Monday evening |
| 21:50.45 | oej | Huntsville - beware. |
| 21:50.59 | oej | Both jsmith and oej at the same time... He he. Power to the community! |
| 21:51.01 | putnopvut | I'm looking forward to your visit oej |
| 21:51.20 | oej | Wednesday = hacking day |
| 21:52.04 | oej | Time to see if this town has anything to offer. Later. |
| 21:52.54 | mvanbaak | if it has an apple store you can get me a macbook air |
| 21:53.06 | oej | mvanbaak: Don't even try... |
| 21:53.33 | oej | mvanbaak: I've already have a full bag of apple stuff. And they did not have ANY iPhones, so I don't know if I dare returning to Sweden |
| 21:53.46 | mvanbaak | whehehehe |
| 21:54.25 | mvanbaak | no iphone for me |
| 21:55.02 | mvanbaak | the OpenMoko looks better |
| 21:55.28 | mvanbaak | you can run asterisk on it |
| 21:55.31 | mvanbaak | ;) |
| 22:02.06 | seanbright | hearts his iphone |
| 22:02.16 | *** part/#asterisk-dev moy (n=moyhu@nat/ibm/x-443b00bfc6af7e07) |
| 22:06.21 | jsmith | russellb: Would it be worthwhile to have a 1.6 directory under asterisk.org/doxygen/ ??? |
| 22:06.30 | russellb | meh |
| 22:06.37 | russellb | 1.6 == trunk |
| 22:07.14 | matthew_i | so with the new release structure will that always be a valid assertion? |
| 22:07.33 | matthew_i | 1.6.0 != 1.6.16 |
| 22:10.25 | Corydon76-dig | We may need to have a separate 1.6.0, 1.6.1, 1.6.2, etc. |
| 22:11.09 | russellb | yeah, maybe |
| 22:11.09 | *** join/#asterisk-dev snuff-home (i=snuff@C-59-101-231-252.bur.connect.net.au) |
| 22:19.24 | mvanbaak | anyone wants cake, beer or wine ? |
| 22:19.36 | mvanbaak | s/or/and\/or/ |
| 22:19.38 | russellb | will accept all 3! |
| 22:19.51 | mvanbaak | gives russellb all 3 |
| 22:20.05 | mvanbaak | time to celebrate |
| 22:20.13 | russellb | runs in circles |
| 22:20.16 | mvanbaak | my wife is 27 for 20 minutes now |
| 22:20.37 | mvanbaak | and yes, I'm on IRC, I know ;) |
| 22:20.50 | russellb | happy birthday to your wife! |
| 22:20.58 | mvanbaak | thankies |
| 22:21.12 | *** join/#asterisk-dev RoyK (n=roy@ip-150-20-149-91.dialup.ice.no) |
| 22:21.32 | *** part/#asterisk-dev RoyK (n=roy@ip-150-20-149-91.dialup.ice.no) |
| 22:32.16 | putnopvut | Happy birthday Mrs. van Baak! |
| 22:38.41 | mvanbaak | :) |
| 22:43.00 | mvanbaak | ok, time to do something else then staring at the screen |
| 22:43.03 | mvanbaak | latero all |
| 22:43.14 | russellb | cya |
| 22:53.29 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 23:28.50 | *** part/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 23:48.20 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |