| 00:16.21 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 00:16.21 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:40.28 | *** join/#asterisk-dev monad777 (n=dan@70.36.138.2) |
| 00:40.30 | monad777 | hello |
| 00:40.46 | monad777 | I am trying to read DTMF tones using agi |
| 00:41.02 | monad777 | I can receive calls, record calls, record the dtmf, etc |
| 00:41.14 | monad777 | however wait_get_digits never gets a digit |
| 00:41.22 | monad777 | the DISA application works... |
| 00:41.30 | monad777 | wait_for_digit rather |
| 00:41.39 | monad777 | WAIT FOR DIGIT -1 for instance waits forever |
| 00:47.24 | snuff-work | monad777: bugs.digium.com is where this query belongs |
| 00:47.51 | snuff-work | make sure you put a full dump of your agi execution there as well |
| 00:49.01 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:49.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:58.47 | jsmith | monad777: You could always do "EXEC Read blah", where blah is the arguments you'd pass to the Read() dialplan application |
| 01:00.56 | *** join/#asterisk-dev nny_2 (n=Scott@64.203.237.47) |
| 01:31.58 | *** part/#asterisk-dev nny_2 (n=Scott@64.203.237.47) |
| 01:36.20 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 01:37.57 | monad777 | snuff-home: you really think this is a bug? how do I get a full dump? |
| 01:38.13 | monad777 | jsmith: not sure I understand |
| 01:39.39 | jsmith | monad777: From within AGI, you can use the "EXEC" command to execute dialplan applications. |
| 01:39.58 | jsmith | monad777: I'm suggesting that you call the Read() dialplan application from within your AGI script |
| 01:41.09 | monad777 | ok, ill take a look |
| 01:51.12 | monad777 | I wrote out the Read example from the asterisk oriely book... |
| 01:51.25 | jsmith | Yeah... I didn't know jack when I wrote that :-) |
| 01:51.30 | monad777 | still no go |
| 01:51.32 | monad777 | ahah |
| 01:51.48 | monad777 | Read(NUMBER,,2) ...SayNumber(${NUMBER}) |
| 01:51.49 | monad777 | etc |
| 01:51.51 | monad777 | no go |
| 01:52.00 | monad777 | all in extensions.conf |
| 01:52.13 | monad777 | i didn't use agi or anything |
| 01:52.25 | monad777 | disa works, and I can record dtmf |
| 01:52.30 | monad777 | but i cannot select based on it |
| 01:53.36 | monad777 | so sad. ;( |
| 01:53.53 | jsmith | You can't do something like: |
| 01:54.00 | monad777 | exten => _XX.,1,Answer() |
| 01:54.04 | monad777 | exten => _XX.,2,Read(NUMBER,,2) |
| 01:54.11 | jsmith | exten => 123,1,Read(NUMBER,hello-world,2) |
| 01:54.19 | monad777 | number is always '' |
| 01:54.21 | jsmith | wonders why monad777 isn't passing in a sound prompt |
| 01:54.33 | monad777 | ill add the sound prompt |
| 01:54.39 | monad777 | do you think the _XX. could have something to do with it? |
| 01:55.44 | monad777 | i got the hellp world sound now, but still not reading my dtmf ;) |
| 01:56.12 | monad777 | i know the dtmf is transmitting. the computer is able to record it |
| 02:16.26 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 02:16.27 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:22.15 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 02:22.20 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:31.52 | monad777 | solution is inbad |
| 02:31.53 | monad777 | inband |
| 02:33.38 | jsmith | Inband DTMF only works for uncompressed codecs like G.711 (ulaw and alaw), so I'd avoid it |
| 02:33.58 | monad777 | well, when i use inband, it works |
| 02:34.03 | monad777 | sigh |
| 02:38.41 | monad777 | "For analog lines inband is the only possible means to transmit DTMF. " |
| 02:39.04 | monad777 | does this mean that cell phones and land lines have to use inband? |
| 02:40.40 | jsmith | Yes |
| 02:40.57 | jsmith | But obviously they're not using a compressed codec like g.729 |
| 02:41.08 | monad777 | ok |
| 02:41.24 | monad777 | so, i have a unix machine running asterisk. its connected via sip to voicepulse |
| 02:41.41 | monad777 | does sip use some other kind of codec to get the audio to my unix machine |
| 02:41.57 | monad777 | why don't cellphones use a compressed codec... ? |
| 02:47.04 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 02:47.04 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:50.20 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 03:20.08 | *** join/#asterisk-dev PDani (n=pdani@catv-89-133-156-227.catv.broadband.hu) |
| 03:52.55 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 04:07.43 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 04:07.43 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:44.45 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 04:49.23 | *** join/#asterisk-dev ScribbleJ (n=sj@c-67-172-6-72.hsd1.il.comcast.net) |
| 04:59.59 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 04:59.59 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 06:12.28 | *** join/#asterisk-dev mort___ (n=mort@user-54405220.wfd76b.dsl.pol.co.uk) |
| 06:37.42 | *** join/#asterisk-dev Pazzo (n=ugelt@host156-36-static.14-79-b.business.telecomitalia.it) |
| 06:52.31 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 07:21.36 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 07:21.38 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 07:27.32 | *** part/#asterisk-dev monad777 (n=dan@70.36.138.2) |
| 07:27.33 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:29.57 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:59.02 | *** join/#asterisk-dev Nick_Lewis (n=chatzill@81.171.134.146) |
| 08:26.16 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 10:02.41 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 10:02.41 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 10:50.09 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 10:50.09 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 11:09.17 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:09.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:11.02 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:33.46 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096611947.dsl.bell.ca) |
| 11:47.33 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 11:50.04 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 12:10.39 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:29.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:11.22 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 13:11.22 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:25.20 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 13:25.20 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:30.20 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:30.21 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:47.35 | *** join/#asterisk-dev djbelieny (n=djbelien@72.48.61.165) |
| 13:47.39 | *** part/#asterisk-dev djbelieny (n=djbelien@72.48.61.165) |
| 13:56.18 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 14:09.18 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.24.187) |
| 14:16.11 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 14:18.18 | *** join/#asterisk-dev qdk (n=qdk@0x3e87f0c2.terminal.tdcmobil.dk) |
| 14:20.52 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:20.53 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:27.53 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:27.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:45.30 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:59.18 | tzafrir_laptop | sruffell, here? |
| 14:59.28 | sruffell | I am |
| 15:00.22 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:16.00 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:18.08 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:27.05 | *** join/#asterisk-dev leif[mobile] (n=leifmads@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:27.05 | *** mode/#asterisk-dev [+o leif[mobile]] by ChanServ |
| 16:01.02 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-12aad85a49462d37) |
| 16:01.07 | *** join/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 16:01.10 | *** part/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 16:07.48 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 16:17.55 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:22.50 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:22.51 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:27.34 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 16:58.03 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 16:58.03 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 17:03.03 | atis_work | Corydon76-dig: ping |
| 17:06.47 | Corydon76-dig | atis_work: pong |
| 17:08.53 | atis_work | Corydon76-dig: take a look at this: http://www.pastebin.ca/1385021 |
| 17:09.11 | atis_work | It's func_lock backported to 1.4, but i suspect it would act the same on 1.6 |
| 17:10.17 | atis_work | As I understand it creates a datastore on channel, and when channel is being destroyed, it releases lock |
| 17:20.40 | *** join/#asterisk-dev qdk (n=qdk@0x55813a0d.terminal.tdcmobil.dk) |
| 17:21.10 | Corydon76-dig | atis_work: releasing the lock on channel destruction is a failsafe, not the intended usage |
| 17:21.21 | atis_work | Corydon76-dig: also i have an addition to func_lock.. For queue call i actually want lock to be kept on parent channel, i can pass parent channel name in dialplan argument - so i create lock in child channel, but it's not destroyed when child channel is. i tested it, but it gives me similar errors |
| 17:21.41 | atis_work | hmm, the doc said it's not necessary |
| 17:22.07 | atis_work | i wonder what are the permissions for locks |
| 17:22.34 | Corydon76-dig | Yeah, it's not strictly necessary, but the idea is that it gets unlocked IF YOU FAIL to do it in the dialplan (because of a hangup) |
| 17:22.50 | Corydon76-dig | Locks are mutually exclusive |
| 17:23.40 | atis_work | i created syntax like this: TRYLOCK(<lockname>[|channel]) |
| 17:24.00 | atis_work | however i can't do unlock on parent channel - i got the same error |
| 17:24.21 | Corydon76-dig | Uh, only the same thread that locked can ever unlock |
| 17:24.28 | atis_work | ooh |
| 17:25.28 | Corydon76-dig | That's the whole point of storing it in a datastore... |
| 17:25.53 | atis_work | well, but there seems to be problem with that if using app_queue |
| 17:26.12 | Corydon76-dig | Eh? |
| 17:26.28 | Corydon76-dig | How are you using it with app_queue? |
| 17:26.47 | atis_work | the log snippets in pastebin |
| 17:27.18 | atis_work | Queue->chan_local->Dial(M(answer_macro)) ->TRYLOCK |
| 17:27.41 | atis_work | perhaps you've seen some issues on ML about that.. |
| 17:28.12 | Corydon76-dig | Ugh |
| 17:28.23 | atis_work | of course i can do UNLOCK in last line of answer macro, but then it doesn't guarantee that it will execute only once.. |
| 17:28.25 | Corydon76-dig | That won't work, because of the masquerade |
| 17:29.00 | Corydon76-dig | I'll have to patch it in some way, to deal with the masquerade |
| 17:29.27 | atis_work | well, the lock should be destroyed on masquerade, doesn't it? |
| 17:31.49 | *** join/#asterisk-dev bbryant (n=bbryant8@68.208.65.34) |
| 17:31.49 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 17:33.12 | anonymouz666 | http://svncommunity.digium.com/svn/russell/asterisk-1.4/func_devstate-1.4/ -> anyone can point me to the right URL or address to get it through SVN |
| 17:35.03 | seanbright | http://svncommunity.digium.com/community/russell/asterisk-1.4/func_devstate-1.4/ |
| 17:35.22 | anonymouz666 | seanbright: thank you |
| 17:35.26 | seanbright | nods |
| 17:48.13 | atis_work | Corydon76-dig: i'm looking into masquarade code, would it be correct to create chan_fixup function in datastore? |
| 17:54.49 | atis_work | Let's see if it works :p |
| 17:57.11 | Corydon76-dig | Working on it now |
| 17:57.28 | Corydon76-dig | It's a tricky operation |
| 17:58.16 | Corydon76-dig | SInce you can't directly inherit a lock across threads, you have to get the old thread to release the lock, the new thread to obtain the lock, and prevent any other threads from obtaining the lock in the meantime |
| 17:58.38 | Corydon76-dig | Tricky |
| 17:58.45 | atis_work | can't i just release it in chan_fixup? |
| 17:59.02 | Corydon76-dig | Nope, that's the new thread already |
| 17:59.06 | atis_work | i didn't get any errors, so i'm adding some debug right now.. |
| 18:00.53 | atis_work | oh, well.. You're right.. |
| 18:01.09 | atis_work | ok, so i can test it whenever you have ready :) |
| 18:01.16 | *** join/#asterisk-dev pmhaddad-work (n=pmhaddad@141.219.87.43) |
| 18:11.26 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) |
| 18:11.29 | Kobaz | i gots a bug |
| 18:12.18 | Juggie | go to the doctor and get checked |
| 18:12.33 | Kobaz | http://pastebin.com/m5c49d578 |
| 18:12.36 | Kobaz | heh |
| 18:12.51 | Kobaz | there's a buffer overflow in the actionid |
| 18:13.25 | Kobaz | looks like it's a fixed 70 bytes |
| 18:19.05 | putnopvut | I may be missing what you're talking about, but that doesn't look like a buffer overflow. |
| 18:19.17 | putnopvut | It looks like the Manager is just truncating the actionid. |
| 18:19.27 | Kobaz | it's overwriting the null at the end |
| 18:19.28 | putnopvut | Of course, it should leave room to print the \r\n in the OriginateResponse. |
| 18:22.39 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 18:26.10 | Juggie | putnopvut, whats AST_NAX_EXTENSION defined to |
| 18:26.15 | Juggie | so i dont have to go searching :) |
| 18:26.28 | putnopvut | Juggie: not sure. I think it's 80 though. I can check real quick. |
| 18:26.32 | putnopvut | It's probably in channel.h |
| 18:26.37 | Juggie | putnopvut, thats the max of the ActionID |
| 18:26.42 | Juggie | but i dont see a buffer overflow |
| 18:26.47 | Juggie | its just killing the null terminator |
| 18:27.07 | putnopvut | Well, that's bad. Sure it's killing the null terminator? |
| 18:28.38 | Juggie | i think so |
| 18:29.04 | Juggie | er |
| 18:29.04 | Juggie | nm |
| 18:29.07 | Juggie | not the null |
| 18:29.11 | Juggie | my bad |
| 18:29.14 | Juggie | snprintf(fast->idtext, sizeof(fast->idtext), "ActionID: %s\r\n", id); |
| 18:29.23 | Kobaz | http://bugs.digium.com/view.php?id=14847 |
| 18:29.30 | Kobaz | that's the bug, that i just put in |
| 18:29.54 | putnopvut | Ugh, I hate snprintf. |
| 18:29.55 | Juggie | fast->idext is set to AST_MAX_EXTENSION (80) so, its just getting trunecated. |
| 18:30.44 | Kobaz | k |
| 18:31.17 | Kobaz | it looked like a classic overflow on the surface.. overwrite the end of the buffer, and go to print it out and it runs into the next variable |
| 18:31.33 | Juggie | ya np, thankfully its not. |
| 18:32.10 | putnopvut | Yeah, all that needs to be changed is that the size portion of that snprintf needs to be modified so that the \r\n is guaranteed to be in the buffer. |
| 18:32.38 | Kobaz | so the entire line is limited to 80 characters then |
| 18:32.44 | Juggie | yep |
| 18:33.07 | Juggie | which is why ou were seeing 70. 'ActionID: ' = 10 |
| 18:33.13 | Kobaz | yeah |
| 18:33.52 | Juggie | putnopvut, any idea why the new line \r\n is there for just that one line and somewhere else for the rest of it, |
| 18:34.04 | Juggie | that would of at least put it on a new line even if it was cut off. |
| 18:34.35 | putnopvut | Juggie: I don't know. |
| 18:34.40 | putnopvut | Gotta run for a sec. brb. |
| 18:42.18 | *** join/#asterisk-dev qdk (n=qdk@146.63.48.86.ip.jay.net) |
| 18:51.01 | putnopvut | I'm back now. |
| 18:55.34 | *** join/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 18:55.50 | *** part/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 19:23.39 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 19:23.39 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:51.04 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 19:56.15 | *** join/#asterisk-dev asteriskmonkey (n=philip@69.77.169.14) |
| 20:12.02 | *** part/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 20:18.03 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 20:20.06 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 20:28.24 | *** part/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 20:49.54 | Qwell | putnopvut: I suspect there are a lot of places where that code is duplicated.. |
| 20:50.11 | putnopvut | Qwell: what code? |
| 20:50.19 | leifmadsen | was thinking the same thing :) |
| 20:50.21 | putnopvut | No, this is specific to the fast_originate_helper. |
| 20:50.23 | Qwell | the actionid stuff |
| 20:50.34 | putnopvut | The fast_originate_helper is limited to 80 chars. |
| 20:50.41 | putnopvut | But other places don't have that limitation. |
| 20:50.44 | Qwell | oh |
| 20:51.25 | putnopvut | I guess I can't say authoritatively that the place I just fixed is the only place that applies to, but it's not like all items with an ActionID have the same issue. |
| 20:51.48 | leifmadsen | boooo... I just found (potentially?) a bug |
| 20:51.56 | putnopvut | yuck |
| 20:51.57 | putnopvut | What? |
| 20:52.14 | leifmadsen | when using Originate() from a Local channel, it doesn't fall through on the dialplan like it should |
| 20:52.22 | leifmadsen | but it works fine when called from a SIP channel |
| 20:52.39 | leifmadsen | tried both with, and without, the trailing /n on the channel |
| 20:52.48 | leifmadsen | Local/tryCall@calendar/n |
| 20:52.57 | putnopvut | leifmadsen: Have I ever mentioned that I don't very much care for local channels? :) |
| 20:53.28 | leifmadsen | :) |
| 20:53.29 | leifmadsen | I think so |
| 20:53.31 | leifmadsen | putnopvut: http://www.pastebin.ca/1385289 |
| 20:53.31 | putnopvut | They're very useful. But man, when it comes to the code, they are always the exception to the rule. |
| 20:53.35 | leifmadsen | that's what I"m tryin got get to work |
| 20:53.45 | leifmadsen | putnopvut: I bet... but true that they are DAMN handy |
| 20:54.23 | leifmadsen | for example... the calendaring branch by twilson can call a Local channel when a busy time comes up, so I've written some dialplan that'll call all the conference participants and automatically connect them to the conference when the meeting is about to start |
| 20:54.52 | leifmadsen | (technically it can call any channel, I just told it to call a local channel so I could make it use Originate() to dial participants |
| 20:54.53 | leifmadsen | ) |
| 20:55.30 | leifmadsen | it works on the first participant, but since Originate() doesn't carry on (or because the Local channel goes away for some reason) then the loop doesn't keep going |
| 20:55.50 | putnopvut | So the calendaring app calls Local/autocall@calendar? |
| 20:55.52 | leifmadsen | it could have something to do with the say Originate() works, and it masquerades the Local channel away.... or something |
| 20:55.56 | leifmadsen | putnopvut: correct |
| 20:56.04 | leifmadsen | tryCall@calendar technically (in my case) |
| 20:56.26 | putnopvut | What happens if you use a call file to call the trycall extension? |
| 20:56.36 | putnopvut | Eh, don't do that. |
| 20:56.41 | leifmadsen | ya, and I don't know how :) |
| 20:56.41 | putnopvut | Should have the same result. |
| 20:56.52 | leifmadsen | calendar.conf only lets you specify the channel |
| 20:58.51 | putnopvut | leifmadsen: what test did you perform where things worked? |
| 21:00.25 | leifmadsen | putnopvut: calling 7654,n,Originate(...) |
| 21:00.29 | leifmadsen | from my polycom |
| 21:00.57 | putnopvut | innnnteresting. |
| 21:01.13 | leifmadsen | likes getting putnopvut interested in issues he is having :) |
| 21:01.37 | leifmadsen | the dialplan looks like it'd work if Originate() did what I expected it to do, heh |
| 21:03.42 | putnopvut | So you never see the verbose "Fall-through" on the console? |
| 21:03.47 | leifmadsen | correct |
| 21:04.03 | leifmadsen | it just stops, but my phone gets run, and connected to MeetMe() |
| 21:07.26 | putnopvut | leifmadsen: Just as a test, could you set the core debug level for channel.c to be at least 4. See if there is a message about "Actually masquerading blah blah blah" when you run your test that fails. |
| 21:07.55 | leifmadsen | ok, let me try |
| 21:11.15 | leifmadsen | putnopvut: I see nothing to do with masquerading |
| 21:11.16 | leifmadsen | [Apr 7 17:10:01] DEBUG[15306]: channel.c:1671 ast_hangup: Hanging up channel 'Local/tryCall@calendar-6586;1' |
| 21:11.18 | leifmadsen | that's it |
| 21:11.23 | leifmadsen | just hangs up the channel it seems |
| 21:12.12 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:12.13 | leifmadsen | http://pastebin.ca/1385327 <-- debug info for you |
| 21:12.19 | leifmadsen | putnopvut: that is with 'core set debug 5' |
| 21:12.34 | putnopvut | Thanks. |
| 21:12.51 | leifmadsen | np, thank you |
| 21:13.10 | putnopvut | Interesting. |
| 21:13.29 | putnopvut | A different thread is hanging up the Local channel than the Originate app is running in. |
| 21:13.35 | leifmadsen | there was some other stuff below that, but didn't feel it was relevant since it didn't mention the Local channel anymore |
| 21:14.34 | leifmadsen | [Apr 7 17:10:06] DEBUG[15308]: chan_dahdi.c:10865 dahdi_request: Using channel -2 |
| 21:14.34 | leifmadsen | [Apr 7 17:10:06] DEBUG[15308]: devicestate.c:443 devstate_event: device 'DAHDI/pseudo-1798962019' state '2' |
| 21:14.34 | leifmadsen | [Apr 7 17:10:06] DEBUG[15278]: app_queue.c:1059 handle_statechange: Device 'DAHDI/pseudo-1798962019' changed to state '2' (In use) but we don't care because they're not a member of any queue. |
| 21:14.37 | leifmadsen | something like that? |
| 21:16.11 | putnopvut | You're right about that not really having anything to do with this, I believe. |
| 21:16.23 | putnopvut | I'm kind of interested in what thread 15306 is. |
| 21:16.44 | putnopvut | That's the thread that hangs up the local channel and that's the only debug message from that thread printed on the console. |
| 21:16.52 | putnopvut | Or at least in your pastebin. |
| 21:17.03 | putnopvut | If you can grep for that number, you may see other messages from that thread as well. |
| 21:18.57 | leifmadsen | let me see if I can find anything... |
| 21:19.42 | putnopvut | The fact that it is referencing the ;1 Local channel makes me think it's the calendaring thread doing the hangup. |
| 21:20.44 | leifmadsen | weird... that's the only reference |
| 21:21.01 | leifmadsen | potentially... |
| 21:21.21 | leifmadsen | maybe we should discuss this with twilson? maybe he has an idea why that might happen |
| 21:21.38 | leifmadsen | maybe it hangs up when it thinks the call was answered? |
| 21:21.56 | leifmadsen | since I imagine he just tested with it calling SIP/1234 instead of a Local channel |
| 21:23.15 | putnopvut | oh interesting. He's using the dialing API. |
| 21:23.31 | putnopvut | So the issue may lie there. |
| 21:24.46 | putnopvut | there are only two debug messages in all of dial.c, and neither are very useful. |
| 21:26.28 | leifmadsen | coolio... I'm going off to finish writing the IMAP section of my presentation. If you need me, you might need to ping me with a direct IM since I may not check here (and I have yet to figure out why xchat doesn't notify me of my name being said) |
| 21:51.11 | mvanbaak | gheh, running /etc/init.d/heartbeat stop on your primary storage box for almost 100 vms is fun |
| 21:52.08 | *** join/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 21:52.11 | *** part/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 21:54.08 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:54.09 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:54.31 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 22:17.39 | mvanbaak | gheh |
| 22:18.05 | mvanbaak | <PROTECTED> |
| 22:21.21 | leifmadsen | ouch |
| 22:44.41 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 22:44.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 22:47.14 | mvanbaak | leifmadsen: yups :( Ah well, at least I finally found the performance problem in our network |
| 22:50.56 | mvanbaak | ok, I officially _HATE_ drbd now |
| 23:17.07 | seanbright | codefreeze-lap: you around? |
| 23:31.15 | mvanbaak | leifmadsen: you got to work on the adaptive_odbc stuff yet ? |