| 00:19.33 | *** join/#asterisk-dev drumkilla (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 00:19.33 | *** mode/#asterisk-dev [+o drumkilla] by ChanServ |
| 00:23.14 | *** join/#asterisk-dev eliel (n=mobile@151-202-114-200.fibertel.com.ar) |
| 00:23.14 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 01:01.45 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 01:01.45 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 01:32.55 | *** join/#asterisk-dev drumkilla (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 01:32.55 | *** mode/#asterisk-dev [+o drumkilla] by ChanServ |
| 02:25.01 | *** join/#asterisk-dev Dag[Away] (n=aguirre@unaffiliated/dagmoller) |
| 02:25.01 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 02:25.01 | *** join/#asterisk-dev wedhorn (n=nnnnnnnn@123-243-209-34.static.tpgi.com.au) [NETSPLIT VICTIM] |
| 02:29.46 | *** join/#asterisk-dev Dag[Away] (n=aguirre@unaffiliated/dagmoller) |
| 02:29.46 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 02:29.46 | *** join/#asterisk-dev wedhorn (n=nnnnnnnn@123-243-209-34.static.tpgi.com.au) [NETSPLIT VICTIM] |
| 02:37.03 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 02:37.03 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 03:06.42 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:06.42 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 03:46.28 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 05:08.41 | *** join/#asterisk-dev jameswf-home (n=james@ip72-200-94-120.tc.ph.cox.net) |
| 06:06.27 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:50.44 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 07:22.06 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.3.70) |
| 07:23.23 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 07:23.23 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 07:24.50 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 07:36.38 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:36.38 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:38.49 | sergee | anybody awake? |
| 07:39.57 | sergee | there is a structure struct ast_region, i suppose this structure created each time then i malloc some memory, (if malloc debug enabled) - is this correct? |
| 07:48.04 | *** join/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 08:39.26 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 08:41.37 | *** join/#asterisk-dev oej (n=olle@193.136.47.146) |
| 08:41.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:42.28 | oej | Morning |
| 08:53.17 | tzafrir_laptop | good morning, even :-) |
| 09:05.02 | oej | :-) |
| 09:05.35 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.3.70) |
| 09:45.48 | atis_work | good morning :) |
| 09:46.08 | atis_work | oej: could you please take a look at patch for 13626 |
| 09:46.29 | atis_work | oej: it was the cancel-before-trying thing i mentioned you some time ago |
| 09:47.31 | atis_work | oej: just to make sure it doesn't break anything :) |
| 09:47.31 | oej | Doing training, will try to get some time later... |
| 09:47.35 | oej | M13626 |
| 09:47.37 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/General 0013626: CANCEL before Trying reported by atis (Karma: +15.50) http://bugs.digium.com/view.php?id=13626 |
| 09:48.36 | atis_work | oej: sure :) |
| 09:51.43 | *** part/#asterisk-dev sivadnz (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 10:25.38 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 10:25.38 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:11.23 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:13.06 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.188) |
| 11:39.55 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.static.dsl.tele.dk) |
| 11:40.44 | *** join/#asterisk-dev drumkilla (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 11:40.44 | *** mode/#asterisk-dev [+o drumkilla] by ChanServ |
| 12:14.02 | sergee | drumkilla: thank you for your speed :) |
| 12:16.21 | seanbright | they do call him the minute man... |
| 12:17.25 | drumkilla | seanbright: zing |
| 12:17.30 | seanbright | bows |
| 12:17.40 | drumkilla | sergee: you're welcome. Nice catch(es) |
| 12:18.11 | drumkilla | grumbles yet again about how much it sucks that we have to deal with ref counts in the first place ... especially as an afterthought |
| 12:18.13 | drumkilla | </rant> |
| 12:18.52 | sergee | drumkilla: sorry for bad patch for trunk, didn't know about AO2.. |
| 12:19.19 | sergee | drumkilla: just copied code from 1.6.0 |
| 12:24.27 | seanbright | man... perl is awesome |
| 12:24.35 | seanbright | can we rewrite asterisk in perl? |
| 12:24.45 | seanbright | we could probably make it a one-liner |
| 12:25.41 | sergee | asterisk(); |
| 12:26.44 | seanbright | perl -e 'answer_calls() if $calls; make_calls() while $calls;' |
| 12:26.50 | drumkilla | sergee: i completely understand, that's what review is for :) |
| 12:27.13 | drumkilla | perl is for noobs |
| 12:27.25 | seanbright | stabs drumkilla |
| 12:27.33 | seanbright | with a #! |
| 12:28.48 | drumkilla | dies |
| 12:30.31 | seanbright | it's just easy to do everything in perl |
| 12:30.42 | seanbright | i have fallen in love with it, all over again. |
| 12:30.44 | seanbright | but moving on. |
| 12:31.10 | drumkilla | C, perl, same thing |
| 12:31.28 | seanbright | no, C is for building applications |
| 12:31.31 | seanbright | perl is for getting stuff done |
| 12:31.47 | drumkilla | getting stuff done == half baked hacks? |
| 12:32.28 | seanbright | rapid development |
| 12:33.20 | seanbright | this thing i am writing doesn't have to perform or handle concurrency or any of that crap |
| 12:33.52 | seanbright | we've talked about the lack of decent data structures in C before. with perl i get a hash out of the box, baby. |
| 12:33.58 | seanbright | done and done. |
| 12:34.48 | seanbright | don't get me wrong... C <3 |
| 12:34.59 | drumkilla | heh, you can get decent data structures if you use a decent library that provides them |
| 12:35.13 | seanbright | ok, let me ask you this |
| 12:35.22 | drumkilla | let me ignore the question |
| 12:35.23 | drumkilla | :-p |
| 12:35.31 | seanbright | hmm. |
| 12:35.44 | drumkilla | i _totally_ understand the usefulness of perl/python/php/p-whatever, i'm just trolling |
| 12:35.48 | seanbright | ohhh |
| 12:35.52 | seanbright | you're fired. |
| 12:35.55 | drumkilla | ha |
| 12:35.58 | seanbright | and immediately re-hired. |
| 12:36.00 | seanbright | welcome back. |
| 12:36.03 | drumkilla | yay!!! |
| 12:36.08 | drumkilla | <3 python, though |
| 12:36.38 | seanbright | haven't really had a chance to play with it |
| 12:36.46 | seanbright | python & ruby seem too trendy to me |
| 12:36.50 | seanbright | perl and C are the mainstays |
| 12:36.50 | sergee | python = basic for linux :) |
| 12:37.01 | drumkilla | heh, i spun the wheel of languages and chose python |
| 12:37.02 | drumkilla | shrugs |
| 12:37.22 | seanbright | looooooooong story short |
| 12:37.22 | drumkilla | docs.python.org made it easy, too. |
| 12:37.24 | seanbright | perl <3 |
| 12:37.30 | drumkilla | :-D |
| 12:37.33 | drumkilla | coding <3 ! |
| 12:37.38 | seanbright | even better |
| 12:37.46 | seanbright | one of these days i'll get back to asterisk |
| 12:37.51 | drumkilla | it's all good |
| 12:38.04 | seanbright | working on lib_sb_sip right now |
| 12:38.08 | seanbright | almost ready for inclusion |
| 12:38.09 | seanbright | heh |
| 12:38.15 | seanbright | (kidding) |
| 12:38.19 | drumkilla | oic |
| 12:44.38 | tzafrir_laptop | seanbright, you have already Dahdi-perl . Feel free to extend it |
| 12:44.59 | tzanger | heh |
| 12:45.27 | tzafrir_laptop | BTW, there's also openpbx (the original one) |
| 12:45.34 | tzanger | one of my 200G drives failed under warranty; they're shipping me a 250G. Now I'm going to have to rebuild the array and somehow break the other while it's under warranty so I can increase my array size 12.5% :-) |
| 12:45.39 | tzafrir_laptop | which is a PBX written in perl, IIRC |
| 12:46.01 | drumkilla | tzanger: i suggest a hammer |
| 12:46.29 | tzanger | drumkilla: I think you missed the part where I said I was trying to get it replaced under warranty :-) |
| 12:46.40 | drumkilla | oh! |
| 12:47.59 | tzafrir_laptop | tzanger, creative use of hdparm -C ? |
| 12:48.19 | tzanger | tzafrir_laptop: it'd be interesting to try and fail it that way |
| 12:48.40 | tzanger | I think I'd be better off with one of those static guns that you use on old vinyl records and careful targeting of certain ICs on the control board :-) |
| 13:19.21 | *** join/#asterisk-dev L-info (n=L-info@80.169.133.251) |
| 13:22.19 | *** join/#asterisk-dev dbailey (n=doug@nat/digium/x-0ff71528f4a2515a) |
| 13:28.48 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:38.36 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 13:42.19 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:42.19 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:43.26 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 13:43.26 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 13:49.34 | *** join/#asterisk-dev _Krieger_ (n=krieger@ip-193.39.118.158.dukenet.odessa.ua) |
| 13:55.00 | _Krieger_ | i have an opinion that this change http://pastebin.ca/1234679 should be applied because current state makes us unable to detach 'manipulating' audiohooks in a way we do for other audiohooks. sorry that i post it here, i`m too lazy to post an issue to tracker. |
| 13:56.43 | lmadsen | _Krieger_: too lazy? I'm too lazy to click on a link |
| 13:56.57 | lmadsen | plus, we can't look at code that isn't on the bug tracker and disclaimed properly |
| 13:57.02 | jsmith | _Krieger_: If you post here... it'll probably get lost in the shuffle. If you post to the bug tracker, it won't get lost |
| 13:57.03 | lmadsen | so regardless, that link won't get clicked |
| 13:57.48 | bweschke | checks himself to see if he is disclaimed properly |
| 14:08.45 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-b0cae38f9b7e7934) |
| 14:08.45 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:20.14 | codefreeze-lap | file: I just posted attempt #3 at 13640. |
| 14:21.22 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:21.24 | codefreeze-lap | It doesn't erase the hangup in the parking manager; and it doesn't crash |
| 14:22.12 | codefreeze-lap | and no hanging channels |
| 14:23.50 | russellb | M13640 |
| 14:23.52 | MuffinMan | [assigned] [Asterisk] CDR/General 0013640: Crash in cdr code in specific one-touch parking scenario reported by mdu113 (Karma: +4.75) http://bugs.digium.com/view.php?id=13640 |
| 14:24.50 | codefreeze-lap | BTW, it'd crash even if you blindtransfered to the parking exten. |
| 14:25.53 | russellb | hmm ... you know, I really don't like any of this KEEPALIVE related stuff |
| 14:26.06 | russellb | I think if a channel gets parked, then it needs to get masq'd away... |
| 14:26.18 | russellb | just thinking out loud |
| 14:29.54 | russellb | I'm looking at this AST_PBX_NO_HANGUP_PEER_PARKED return code ... |
| 14:30.06 | russellb | In my mind, this shouldn't need to exist, there should not have to be any special handling for this case |
| 14:30.25 | russellb | Any time anything wants to take over the channel and own it (and potentially destroy it), it needs to masquerade the channel |
| 14:30.39 | russellb | that is the proper way to handle that type of thing in asterisk ... |
| 14:30.52 | russellb | so if it's not doing that, it's a bug in how parking works IMO |
| 14:32.36 | russellb | There may be other things that use that return value (the keepalive, nohangup, whatever), but i have decided that I hate it :) |
| 14:33.17 | file | <PROTECTED> |
| 14:33.19 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-8e3498103023ea1d) |
| 14:33.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:33.27 | *** join/#asterisk-dev SirWhit (n=sirjames@blk-222-38-6.eastlink.ca) |
| 14:33.31 | russellb | right, that's what has me so bothered |
| 14:33.51 | russellb | the fact that there is magic "please don't touch this because it might disappear" thing is just really ... bothersome |
| 14:35.54 | codefreeze-lap | russellb: pardon me for being incredibly and unforgiveably ignorant, but I'm not seeing how masquerading accomplishes this... ? |
| 14:36.34 | russellb | Well, that's the exact purpose of a masquerade. |
| 14:36.49 | russellb | You allocate a new ast_channel, and you masq an existing channel you have into the one you just allocated |
| 14:36.53 | russellb | what this does for you is ... |
| 14:37.28 | russellb | now you have a new channel, and you can control who has references to it, and what thread owns it |
| 14:37.46 | russellb | and the old ast_channel structure is still completely valid, memory wise, and it will just go away and treated like a normal hangup |
| 14:38.38 | russellb | if you look at all of the uses of masquerading, that's the general purpose. it's for changing ownership of a channel |
| 14:38.49 | russellb | (thread ownership) |
| 14:39.44 | codefreeze-lap | Hmmm. So, if channel refcounting were done, masquerading would not have been necc? |
| 14:40.05 | russellb | channel ref counting doesn't get rid of the need for masquerades |
| 14:40.46 | russellb | because in asterisk, you still have to have a single thread that owns a channel, and that is in charge of when to hang it up (signaling wise, not just memory freeing) |
| 14:40.53 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:42.08 | russellb | it's complicated, heh |
| 14:46.25 | russellb | Anyway, since those nohangup codes already existed, I'm not saying you need to go re-write all of it ... |
| 14:46.55 | codefreeze-lap | russellb: are you implying that I should go to "plan d" for 13640, and move to masquerading parked calls, and get rid of all the return codes.... (sigh of relief) OK... |
| 14:47.07 | russellb | :) |
| 14:47.09 | russellb | However, ... |
| 14:47.20 | russellb | you're assuming that in the parked case, the channel may disappear |
| 14:47.32 | russellb | but the truth is, anytime KEEPALIVE, or NO_HANGUP is used at all, that could be the case |
| 14:48.46 | russellb | so, i just ask that you change the code to make sure that you do not touch the chan if it's keepalive, or the peer if it is nohanguppeer |
| 14:48.59 | russellb | and then you can just remove the new special PARKED code, because really, it's not a special case |
| 14:51.19 | codefreeze-lap | Hmmm. Haven't followed the KEEPALIVE case. No code conditionalizes an ast_hangup() based on KEEPALIVE, afaict. At least, where they've been using NO_HANGUP. In the code I wrote, I do need to differentiate between parks, in which I am not interested, and transfers, in which I am, to reduce the chances of calling the channel_find code. |
| 14:53.01 | russellb | ok, so, you have 2 channels in this part of the code. the "chan" and the "peer" |
| 14:53.05 | russellb | the "chan" is running the pbx. |
| 14:53.39 | codefreeze-lap | Ah, **chan** KEEPALIVE, **peer** NOHANGUP, I gotcha. |
| 14:53.46 | russellb | exactly |
| 14:54.03 | russellb | in each case, the associated code means that another thread has assumed ownership of the chan or peer |
| 14:54.14 | russellb | code == return code |
| 14:54.26 | russellb | and thus, once you see that, you can _not_ touch that ast_channel at all |
| 14:55.30 | codefreeze-lap | I'll review the KEEPALIVE case... |
| 14:56.25 | russellb | ok |
| 14:58.46 | codefreeze-lap | ponders the consequences of KEEPALIVE on CDR's... this will effectively null out CDR's of parked channels... to some sort of extent... hmmmm |
| 15:00.07 | seanbright | ponders another cup of coffee and a cigarette... |
| 15:00.39 | russellb | ponders taking up smoking ... |
| 15:00.44 | codefreeze-lap | slurps up the last remnants of his hot chocolate drink... |
| 15:00.55 | seanbright | russellb: all the cool kids are doing it. |
| 15:01.22 | seanbright | lung cancer is in, now. |
| 15:02.13 | russellb | :-p |
| 15:02.18 | codefreeze-lap | and hauling a cylinder of oxygen everywhere you go, is cool too. (remem, I'm LDS, so I'm biased) |
| 15:04.00 | codefreeze-lap | And the snap-on prosthetics for the chewers who lost jawbone, etc, are really cool too! |
| 15:07.54 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 15:08.25 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-b47bb1b533af9788) |
| 15:08.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:08.47 | jmls | mm. why is the topic "Asterisk trunk: res_telepathy release tomorrow" ? |
| 15:08.56 | jmls | surely we all should know that already ? |
| 15:08.58 | jmls | ;) |
| 15:10.12 | codefreeze-lap | jmls: personallly, I think chan_telepathy will be the first implementation; there has to be some sort of interface... |
| 15:13.25 | mog | why would we add that huge dependency to asterisk.... http://telepathy.freedesktop.org/wiki/ |
| 15:15.37 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:23.08 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:25.30 | *** part/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 15:25.53 | codefreeze-lap | mog: Very interesting... |
| 15:26.18 | jsmith | sighs |
| 15:26.22 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:26.22 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:31.38 | oej | pats jsmith on the back. |
| 15:31.49 | oej | Students can be evil... |
| 15:32.17 | jsmith | My students aren't evil |
| 15:32.23 | oej | app_telepathy - places calls before you know that you need it. |
| 15:32.37 | jsmith | I'm just in a foul mood today |
| 15:32.38 | oej | res_telepathy - answers call with a prompt that fits the mood of the caller |
| 15:32.48 | Qwell | jsmith: it's a foul day |
| 15:33.02 | oej | jsmith: The sun is up in the sky here in Portugal. And the food is awsome |
| 15:33.11 | jsmith | Qwell: And it started out so good, too |
| 15:33.18 | Qwell | jsmith: indeed it did |
| 15:35.42 | russellb | oej: don't forget to update the CHANGES file for the new feature |
| 15:36.54 | oej | ...and I was happy to remember the doc file... Sorry. |
| 15:37.00 | russellb | no problem :) |
| 15:37.14 | russellb | I'm impressed you remembered the doc/ file, I always forget those ... |
| 15:37.24 | Qwell | we have a doc/ dir? |
| 15:37.35 | codefreeze-lap | lol |
| 15:38.33 | oej | Something many forget to update is the man page... |
| 15:38.53 | russellb | indeed. though we don't add command line options too often |
| 15:38.59 | russellb | which may be why we forget to update the man page, heh |
| 15:41.35 | SirWhit | hey folks.. has anyone else had any isses with SIP channel locks in the 1.4 branch? |
| 15:41.43 | codefreeze-lap | russellb: need an idea here... I need a scenario where KEEPALIVE is returned, and "chan" is gone/disappears... my brain is like fudge right now. |
| 15:44.21 | russellb | when the chan gets parked |
| 15:51.05 | jeev | does asterisk open a socket? |
| 15:51.10 | russellb | lol |
| 15:51.13 | russellb | jeev: seriously? |
| 15:51.20 | jeev | lol |
| 15:51.21 | jeev | nevermind |
| 15:51.23 | jeev | russellb |
| 15:51.24 | russellb | jeev: yes, it opens a number of them |
| 15:51.28 | jeev | dont seriously me |
| 15:51.29 | jeev | poke your eyes out |
| 15:51.31 | jeev | uh |
| 15:51.38 | jeev | how often is the polling to determine if qualify fails? |
| 15:51.42 | jeev | if qualify=yes |
| 15:52.01 | russellb | jeev: being banned from #asterisk doesn't get you the right to ask in here instead :) |
| 15:52.09 | jeev | oh |
| 15:52.12 | jeev | isn't it a developer question |
| 15:52.14 | jeev | i'm not banned |
| 15:52.15 | jeev | i'm in there |
| 15:52.23 | jsmith | Then ask these questions in there, please |
| 15:52.27 | *** join/#asterisk-dev otherwiseguy (n=otherwis@72.128.38.41) |
| 15:52.28 | jeev | oh ok |
| 15:52.39 | jpeeler | codefreeze-lap: aren't you working on that exact scenario right now? |
| 15:59.05 | codefreeze-lap | Ha, got it. hmmm. on the second try. OK, got the crasher I needed |
| 15:59.37 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 16:01.08 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 16:01.08 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 16:01.08 | *** join/#asterisk-dev jeffspeff (n=jeff@c-69-245-31-86.hsd1.ky.comcast.net) |
| 16:01.08 | *** mode/#asterisk-dev [+o russellb] by irc.freenode.net |
| 16:24.54 | tzanger | anyone here familiar with dahdi/zaptel *internals* regarding span sync src? |
| 16:34.24 | tzanger | guess not |
| 16:35.00 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 16:35.00 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 16:49.54 | jsmith | tzanger: Naw... that's totally voodoo to me... |
| 16:50.03 | tzanger | heh |
| 16:50.15 | tzanger | I'm trying to understand the .sync and .psync fields |
| 16:50.24 | tzanger | they get initialized to the same value, and the value is not what you would expect |
| 16:50.29 | tzanger | i.e. if I have a quadspan card |
| 16:50.37 | tzanger | and I say span 1 sync=2 |
| 16:50.41 | tzanger | (ie. secondary sync) |
| 16:50.57 | tzanger | then span 2 (?) gets sync/psync = 1 |
| 16:51.14 | tzanger | oh wait |
| 16:51.16 | jsmith | Here's what I know: |
| 16:51.17 | tzanger | fuck me, I'm stupid |
| 16:51.24 | jsmith | no thanks |
| 16:52.05 | tzanger | no, I'm not stupid |
| 16:52.07 | tzanger | it's still not right |
| 16:52.31 | tzanger | I configured span 1/2/3/4 for sync of 3/2/0/4 |
| 16:52.45 | tzanger | and sync/psync get set to 0/2/1/4 |
| 16:53.13 | tzanger | or |
| 16:53.38 | tzanger | if I set 1/2/3/4 to 3/2/0/1, sync/psync = 4/2/1/0 |
| 16:53.44 | tzanger | does not compute |
| 16:53.57 | tzanger | I set span 4 to be primary sync, yet its sync/psync value is 0 |
| 16:54.15 | tzanger | yet span 3, which I said "do not use as sync source", has sync/psync of 1 |
| 16:55.57 | eliel | russellb: I have a patch that moves: AST_RWLIST to ao2_container, but the future problem is still not fixed, just the same code but with ao2 |
| 16:57.39 | russellb | hmm .. |
| 16:57.41 | eliel | russellb: I have read your review request response, sorry, I will save my patch for the future |
| 16:57.41 | russellb | i'd have to look |
| 16:57.45 | russellb | ok |
| 16:57.55 | russellb | you're going to open up a big can of worms if you commit that :) |
| 16:58.13 | eliel | nono, I was not going to commit it, he |
| 16:58.15 | russellb | i can review it, but it's up to you whether you want to work through all of the details to get that right or not |
| 16:59.11 | eliel | We can work on this later, I will put it in my todo list with a lower priority for now |
| 16:59.26 | russellb | k |
| 17:04.10 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:04.27 | codefreeze-lap | Someimes, when I pick up a dahdi phone, I get modem tones and "chan_dahdi.c:8154 (in trunk): do_monitor: Read failed with -1: Unknown error 500.... I think it was when I pick up too quickly after hanging up. |
| 17:04.56 | codefreeze-lap | that'd be on a 24-port card. |
| 17:05.48 | russellb | yeah, picking up quickly after a hangup has always been a bit wonky |
| 17:06.30 | codefreeze-lap | The channel doesn't respond, no sound; you have to hang up and pick up again to get back to normal. |
| 17:09.21 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:19.09 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 17:19.57 | seanbright | putnopvut: is your ao2 container type branch defunct? or just too busy with actual work recently? |
| 17:20.10 | putnopvut | seanbright: just too busy with actual work. |
| 17:20.18 | seanbright | suck |
| 17:20.30 | putnopvut | I'm also stuck right now trying to figure out how to make an iterator work for the skiplist and be thread-safe. |
| 17:21.29 | seanbright | what's special about a skip list that makes that difficult? |
| 17:22.35 | putnopvut | Well, here's the deal. Within each of the other container types, each object has a "version" field which tells, essentially, how new the object is. |
| 17:23.21 | putnopvut | When iterating over other container types, if the container changes between calls to ao2_iterator_next, we can pick up where we left off by finding the first item we come to with a larger "version" than the last object we had looked at. |
| 17:24.15 | putnopvut | With a skiplist, this same technique does not work because the items are sorted in the container, and so when it was added does not accurately convey where it lies in the list. |
| 17:24.27 | seanbright | aha |
| 17:24.30 | putnopvut | Thus a new mechanism must be worked out to allow for an iterator to pick up. |
| 17:25.11 | seanbright | singly linked list between nodes based on when the node was added? |
| 17:25.21 | seanbright | a hybrid, as it were. |
| 17:25.27 | putnopvut | I see what you're saying. |
| 17:25.28 | seanbright | were it as. |
| 17:25.34 | codefreeze-lap | russellb: OK, certain things are not able to be done in app_dial, then, to avoid crashes, and will need to be either not at all, or to be done in the parking manager thread... Namely, running the hangup exten; and setting ANSWEREDTIME / DIALEDTIME on the channel.... I am yours to command.... |
| 17:25.45 | seanbright | putnopvut: not a fantastic idea. just throwing it out there. |
| 17:26.02 | putnopvut | seanbright: I think that idea could work. Performance isn't really a factor for iterators, considering the idea is to visit each one. |
| 17:26.15 | putnopvut | s/one/item in the container/ |
| 17:26.19 | putnopvut | that makes it a bit more clear. |
| 17:27.16 | seanbright | but you still want to iterate in a sorted manner, right? |
| 17:27.24 | putnopvut | Correct. |
| 17:27.56 | seanbright | interesting. |
| 17:27.58 | seanbright | hrmmm. |
| 17:34.41 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:34.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 17:35.07 | lmadsen | hello from FSOSS! |
| 17:40.00 | *** join/#asterisk-dev TedC (n=cabeen@milli.chem.ucsb.edu) |
| 17:40.02 | seanbright | goodbye from bal'more! |
| 17:40.04 | hardwire | lucky |
| 17:40.08 | *** part/#asterisk-dev TedC (n=cabeen@milli.chem.ucsb.edu) |
| 17:41.03 | *** join/#asterisk-dev bbryant (n=brett@68.208.65.50) |
| 17:41.03 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 17:43.59 | seanbright | russellb: lol @ 'does get_header() in chan_sip returns a null-terminated buffer?' |
| 17:44.31 | tzanger | seanbright: :-) |
| 17:44.35 | tzanger | yeah it was funny |
| 17:47.41 | oej | russellb: Was my explanation of "kill-the-user" anything that anyone would understand? |
| 17:47.41 | *** join/#asterisk-dev neolynx (n=u@32-123-204-62-pool.dsl.fcom.ch) |
| 17:47.49 | neolynx | hello |
| 17:48.06 | neolynx | I have a question regarding an asterisk app |
| 17:48.31 | Qwell | oej: I didn't understand it too much... |
| 17:48.35 | Qwell | friend == user? |
| 17:48.43 | oej | yes |
| 17:48.46 | oej | then you did understand |
| 17:48.48 | neolynx | I like the pbx to continue the priorities in the extension after a hangup |
| 17:48.48 | oej | ;-) |
| 17:48.56 | Qwell | but, friend == peer+user |
| 17:49.03 | oej | Not any more |
| 17:49.05 | seanbright | neolynx: have you asked in #asterisk? |
| 17:49.07 | oej | Relearn |
| 17:49.11 | Qwell | but then doesn't that lose backward compat? |
| 17:49.28 | neolynx | seanbright: well, since it's a development question i thought to ask here |
| 17:49.34 | seanbright | neolynx: ok, fire away. |
| 17:49.34 | Qwell | friend used to try to match both ways, right? |
| 17:49.44 | neolynx | seanbright: do they know how to code asterisk apps in #asterisk ? |
| 17:50.10 | Qwell | neolynx: there's a keepalive thing you can return |
| 17:50.14 | oej | Qwell: Not really |
| 17:50.22 | Qwell | AST_PBX_KEEPALIVE I think? |
| 17:50.27 | neolynx | the Dial application has a g option, but I don't really see what the app does to let the pbx cotinue after a hangup |
| 17:50.44 | neolynx | Qwell: thanks |
| 17:50.54 | neolynx | Qwell: I tried this, but it didn't really work |
| 17:50.57 | Qwell | search for PBX_KEEPALIVE, and you should be able to see how it works |
| 17:51.01 | neolynx | Qwell: maybe my fault, i'll retry |
| 17:51.07 | oej | Qwell: Since we had a user, we only matched on the user name for incoming calls |
| 17:51.16 | file | neolynx: what are the apps going to with a hung up channel? |
| 17:51.25 | oej | And we used the peer for outbound calls |
| 17:51.27 | file | neolynx: or are you talking about having the other channel continue |
| 17:51.32 | Qwell | oej: I see |
| 17:51.34 | neolynx | file: Fax, send it per email |
| 17:51.47 | neolynx | file: after hangup |
| 17:51.50 | file | neolynx: people use the h extension for that |
| 17:52.02 | neolynx | file: people are smart :) |
| 17:52.10 | neolynx | file: thanks ! |
| 17:52.17 | Qwell | neolynx: you have too much faith in humanity :p |
| 17:52.58 | neolynx | Qwell: seems so, and too much faith in technology, patching here and there... |
| 18:03.35 | neolynx | file: great, works :) I have app_rxfax with spandsp-0.0.6 working |
| 18:03.49 | neolynx | file: result is awsome |
| 18:07.36 | russellb | I hope oej didn't think I was ignoring him |
| 18:07.38 | russellb | I was out to lunch |
| 18:14.40 | *** join/#asterisk-dev wolfelectronic (n=wolfelec@91.112.227.150) |
| 18:15.11 | *** part/#asterisk-dev wolfelectronic (n=wolfelec@91.112.227.150) |
| 18:20.12 | codefreeze-lap | russellb: plus, I asked a question at 11:25 my time, prob 12:25 yours |
| 18:22.48 | russellb | oh, ok, thanks, I see it now ... |
| 18:22.52 | russellb | hm, geez, this is tough |
| 18:23.24 | russellb | But yeah, that's the truth, it's just plain not safe to do _any_ of that in the case of KEEPALIVE |
| 18:23.42 | russellb | because if this is due to parking, the parking thread now assumes it owns that channel, and that it can hang up on it at any point |
| 18:23.58 | russellb | this is why KEEPALIVE and NO_HANGUP_PEER are really dangerous ... |
| 18:24.20 | codefreeze-lap | But if I do those ops in the parking manager func.... |
| 18:25.37 | russellb | um, maybe? I don't really know what you mean :) |
| 18:25.44 | russellb | you mean in the code right before the channel gets parked? |
| 18:25.50 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.199.65) |
| 18:26.25 | codefreeze-lap | no, where the ast_hangup occurs for the parked call... look for "tired" in the source |
| 18:26.44 | russellb | oh, well ... maybe ... but ... |
| 18:26.51 | russellb | there are a lot of code paths that end up with a channel being parked |
| 18:26.58 | russellb | not all of which make sense to do those things probably |
| 18:28.04 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 18:39.25 | codefreeze-lap | russellb: right now, parking isn't covered at all by CDR's... and probably, since no-one has filed crash reports on parking early-hangups, no-one's noticed that they get no h-exten dialplan execution, either. So, I'm all for saying, that when you park a call, all bets are off, and CDRng will cover those situations and more. |
| 18:45.47 | russellb | whatever you say, boss |
| 18:45.54 | russellb | my brain is consumed elsewhere at the moment ... |
| 18:45.55 | russellb | :) |
| 18:46.15 | russellb | i just wanted to point out the dangers of what happens when keepalive/nohangup stuff is in play |
| 18:46.17 | russellb | the rest is up to you :) |
| 18:49.09 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 18:52.10 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 18:52.10 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 18:58.48 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 19:03.45 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:03.45 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 19:04.05 | lmadsen | presentation complete! |
| 19:04.32 | ctooley | lmadsen, congrats |
| 19:04.51 | lmadsen | thanks! I think it went pretty well... taught people some asterisk dialplan :) |
| 19:05.11 | ctooley | :) cool |
| 19:06.11 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:07.49 | putnopvut | lmadsen: where and what is FSOSS, if you don't mind my asking? |
| 19:08.26 | lmadsen | putnopvut: I don't mind at all! |
| 19:08.36 | lmadsen | http://fsoss.senecac.on.ca/2008/ |
| 19:08.52 | lmadsen | my presentation was recorded, so hopefully I didn't suck too much :) |
| 19:09.12 | lmadsen | this presentation after mine is much more full, lol |
| 19:09.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:25.02 | jsmith-teaching | lmadsen: w00t! You gonna send me your slide deck? |
| 19:25.12 | lmadsen | jsmith-teaching: I can do that! |
| 19:25.25 | lmadsen | I made a couple of typo fixes (I think like... 2), and added a couple of new slides |
| 19:26.07 | lmadsen | it's an intro to dialplan, that builds upon things and gets a bit complex, and just as people are about to cry, it finishes :) |
| 19:26.34 | lmadsen | I have one thing to fix first, then will send it over. Was also recorded, so hope to see the video soon |
| 19:37.43 | *** join/#asterisk-dev wolfelectronic (n=wolfelec@91.112.227.150) |
| 19:42.05 | jsmith-teaching | lmadsen: Did you meet Chris? Paul? Anybody else cool? |
| 19:42.26 | lmadsen | not yet... but the social gathering is fairly soon |
| 19:42.33 | lmadsen | then the speakers dinner is tonight |
| 19:54.09 | lmadsen | jsmith-teaching: oh, I did meet a bunch of guys from Mozilla last night |
| 19:54.28 | Qwell | lmadsen: were they swapping? |
| 19:54.34 | lmadsen | eh? |
| 19:54.37 | Qwell | nothing |
| 19:54.42 | Qwell | I'm trolling |
| 19:54.53 | caio1982 | haha |
| 19:55.01 | Qwell | see, caio1982 gets it |
| 19:56.30 | lmadsen | jsmith-teaching: aha... I see who Paul is now :) |
| 19:57.05 | lmadsen | jsmith-teaching: btw -- which Chris were you talking about? I did meet Chris... Tyler I believe |
| 19:58.00 | lmadsen | ugh... bugs are closing in on 400 again. |
| 19:59.26 | putnopvut | dammit |
| 20:09.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:19.44 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 20:19.44 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 20:39.45 | seanbright | i think i am giving myself an ulcer because of road rage |
| 20:41.13 | putnopvut | seanbright: not surprising considering where you live. |
| 20:41.25 | putnopvut | Does your daily commute involve any tunnel travel? |
| 20:41.30 | seanbright | no, thankfully. |
| 20:41.41 | seanbright | just inner loop between 83 and white marsh |
| 20:41.42 | putnopvut | Yes, that is definitely a good thing. |
| 20:42.03 | seanbright | the longest 10 miles... EVER |
| 20:43.09 | seanbright | it might even be less than 10 miles. but it's painful. |
| 20:47.10 | putnopvut | That sucks :/ |
| 20:47.15 | seanbright | i'll live |
| 20:47.18 | seanbright | i think. |
| 20:47.19 | De_Mon | seanbright didn't stay on topic very long at all... |
| 20:47.26 | seanbright | De_Mon: shut it |
| 20:47.32 | seanbright | heh |
| 20:48.17 | De_Mon | I was wrong about the 15min prediction, so I have to make up for it ;) |
| 20:48.46 | De_Mon | but seriously, are you ircing while contemplating road rage? |
| 20:49.52 | seanbright | no, i am coming down from said road rage. |
| 20:49.59 | seanbright | took 1 hour to drive 14 miles |
| 20:51.18 | putnopvut | Sounds like the few times I've been in Atlanta. |
| 20:51.23 | putnopvut | during rush hour. |
| 20:51.48 | De_Mon | I tend to either leave work early, or very late when the snow birds are in town |
| 20:54.40 | codefreeze-lap | russellb: trivia: I'm getting an error in 1.4 on park; ast_channel_free: PBX may not have been terminated properly on "DAHDI/1-1" -- I previously got DAHDI/1-1 got tired of being parked, then "Hungup 'DAHDI/1-1'... what else has be done??? |
| 20:56.41 | jpeeler | codefreeze-lap: the hangup is beating the termination of the PBX thread probably |
| 20:58.21 | russellb | i don't have time to look at it right now |
| 20:58.49 | Qwell | <random>I wonder if Asterisk could be run halted/diskless</random> |
| 21:01.16 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 21:01.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:02.21 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 21:02.21 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:06.22 | *** join/#asterisk-dev eliel-iphone (n=mobile@190.177.202.167) |
| 21:06.51 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 21:08.28 | codefreeze-lap | jpeeler: hmmm. well, I *am* in valgrind, maybe that slows down one thread vs another... |
| 21:08.56 | seanbright | bkruse: seanbright++? |
| 21:09.10 | jpeeler | codefreeze-lap: true, but you'll want to somehow guarantee that the PBX thread has terminated... somehow |
| 21:09.39 | jpeeler | this was the same problem i was up against |
| 21:09.46 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:10.32 | bkruse | seanbright: Yes, karma for the patch |
| 21:10.33 | bkruse | :) |
| 21:10.37 | seanbright | bkruse: ah :) |
| 21:10.46 | seanbright | well, expect more :) |
| 21:14.58 | *** join/#asterisk-dev radiofree (n=radiofre@75.150.198.1) |
| 21:18.24 | jameswf-home | IAX is also not an industry standard and there are no major brand devices that support it. |
| 21:18.37 | jameswf-home | ~kerryg |
| 21:18.47 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 21:19.28 | russellb | ~gpllaw |
| 21:19.58 | jameswf-home | that was a reply to iax support for hud3 |
| 21:20.10 | codefreeze-lap | jpeeler: I've just posted the planc3 patch set for 13640; run thru all the scenarios, plus valgrind... |
| 21:21.37 | jpeeler | codefreeze-lap: i will give it a go before i leave today |
| 21:32.48 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:58.02 | Qwell | bkruse: I don't know if he can commit that |
| 22:00.24 | Qwell | tzafrir_laptop: I think I'm going to go ahead and close 13427 |
| 22:01.02 | Qwell | thoughts? |
| 22:02.52 | tzafrir_laptop | looks ok |
| 22:03.00 | tzafrir_laptop | hmm |
| 22:03.21 | Qwell | I know #2 is fixed. It looked like #1 was fixed too |
| 22:03.27 | tzafrir_laptop | is it a regression that we don't build sethdlc on some places? |
| 22:03.36 | Qwell | WELL |
| 22:03.38 | Qwell | yes and no |
| 22:03.40 | tzafrir_laptop | I don't suppose it ever managed to build there |
| 22:04.10 | Qwell | it's enabled in menuselect by default now, where it wasn't in Zaptel |
| 22:04.22 | bkruse | Qwell: No, the patch for *#? |
| 22:04.26 | Qwell | (the fix was to disable it if it couldn't build) |
| 22:04.33 | bkruse | I already talked to Pari, we are at least not going to do it now |
| 22:04.49 | Qwell | bkruse: oh |
| 22:04.57 | tzafrir_laptop | Qwell, gret. so yeah, it should be closed |
| 22:05.31 | bkruse | Qwell: Ty though :) |
| 22:06.06 | Qwell | bkruse: is it the wrong way to do it, or? |
| 22:06.39 | bkruse | Qwell: Well, it's one of those things that will eventually be merged into BE/AA50, and we just want to check with other people (malcolm mainly) to get his 2 cents |
| 22:06.46 | Qwell | ahh |
| 22:07.18 | Qwell | if not, I would say that the function is still useful to have (for other places) |
| 22:07.39 | Qwell | always helps to have other matching options |
| 22:08.21 | Qwell | M13716 |
| 22:08.24 | MuffinMan | [new] [Asterisk] Channels/chan_dahdi 0013716: [patch] Prevent false answer of channel when going off-hook reported by alecdavis (Karma: +4.00) http://bugs.digium.com/view.php?id=13716 |
| 22:08.25 | bkruse | Qwell: Right, and pari just kind of said, our goal was to make the GUI easy enough to edit so that users could do things like that. But I do want to merge it |
| 22:08.33 | Qwell | false answer? then why are you going off-hook? O.o |
| 22:09.28 | seanbright | so asterisk-gui is more strict as far as what it accepts? |
| 22:09.28 | Qwell | ahh, nm |
| 22:11.11 | seanbright | yes? no? |
| 22:11.13 | seanbright | maybe so? |
| 22:11.19 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 22:12.08 | seanbright | ok, good talk. |
| 22:14.49 | tzafrir_laptop | I recall that there was something fishy there |
| 22:15.16 | tzafrir_laptop | (there: in the code, not in the patch) |
| 22:15.41 | tzafrir_laptop | but I'm not exactly sure what it is |
| 22:15.52 | wolfelectronic | putnopvut? |
| 22:16.02 | putnopvut | wolfelectronic: hello |
| 22:16.27 | wolfelectronic | hello, i am just preparing a patch for the hint problem, and would have one question |
| 22:16.39 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 22:16.39 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 22:17.19 | putnopvut | wolfelectronic: oh great! What's your question? |
| 22:17.39 | wolfelectronic | i do not understand why the ast_flag SIP_INC_COUNT is checked for decrementing but not for incrementing |
| 22:17.49 | wolfelectronic | the inuse counter |
| 22:18.37 | putnopvut | The flag indicates that this dialog had increased the inuse count. |
| 22:18.50 | seanbright | bkruse: what goes into the asterisk-gui is driven by ABE? |
| 22:19.07 | putnopvut | So it gets set when we increase the count, and then before we decrease the count, we check the flag to see if we had previously increased the count. |
| 22:19.20 | bkruse | seanbright: A lot more than people realize. |
| 22:19.25 | seanbright | :-/ |
| 22:19.27 | bkruse | Most of it, actually |
| 22:19.36 | seanbright | well then i retract my offer of more patches :) |
| 22:21.26 | wolfelectronic | sorry, but as an newbe i do not understand what you mean with dialog. and why is the flag checked for incrementing the inringing but not for incrementing the inuse? |
| 22:22.04 | wolfelectronic | or is dialog == call? |
| 22:25.44 | wolfelectronic | if i understand you right the flags should prevent an increment by more than one per call? |
| 22:27.22 | putnopvut | a dialog in SIP terms is a call leg. In other words, it represents the "call" between Asterisk and an endpoint. |
| 22:27.44 | wolfelectronic | aha |
| 22:28.05 | putnopvut | The flags prevent the count from being decremented by a dialog which did not previously increment the count. |
| 22:28.39 | bkruse | seanbright: I do not blame you one bit |
| 22:30.28 | wolfelectronic | ok, i understand. but perhaps i am too tired (0:30 am) why is the SIP_INC_RINGING flag checked to be clear before incrementing inringing but not the SIP_INC_COUNT before incrementing the inuse? |
| 22:32.20 | putnopvut | wolfelectronic: I'm not sure. It may be there to prevent the same dialog from increasing the count more than once. |
| 22:33.05 | wolfelectronic | so it would better in respect to murphys law to do the same check for the inuse counter? |
| 22:34.39 | putnopvut | Unfortunately, I don't really know that section of code well enough to know if that check would be valid there. It seems to make sense, though, considering that the SIP_INC_COUNT flag is cleared when the inuse counter is decreased. |
| 22:35.46 | wolfelectronic | ok, i will add this check, and hope that some one will check the patch before committing it to svn |
| 22:36.40 | snuff-work | wolfelectronic: generally all patches are reviewed by someone and don't just 'go in' |
| 22:36.45 | snuff-work | so u should be safe :) |
| 22:37.51 | wolfelectronic | thats fine. so i will finish now. after sleeping some hours i will test my patch on the customer site and if successfull willl upload it to bugtracker |
| 22:38.41 | wolfelectronic | putnopvut: have a nice day, bye |
| 22:57.36 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-8e3498103023ea1d) |
| 23:02.28 | putnopvut | wolfelectronic: thank you very much :) |
| 23:04.21 | wolfelectronic | ypur wellcome. but after thinking a bit i wonder if correct locking will fix the problem. are there really two tasks calling the func with the same fup pointer? this is the only case where locking will help |
| 23:06.35 | wolfelectronic | i am afraif the real problem is somewhere else, but testing will show ... |
| 23:39.29 | *** part/#asterisk-dev wolfelectronic (n=wolfelec@91.112.227.150) |