| 00:09.39 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 00:12.54 | *** join/#asterisk-dev tzanger (n=tzanger@208.68.91.47) |
| 00:33.49 | *** join/#asterisk-dev ricko73 (n=dhartman@wilug/newlug/ricko73) |
| 00:35.31 | ricko73 | I've been looking at IMAP storage with app_voicemail. Is it possible to build two versions of app_voicemail.so; call one app_voicemail-imap.so and actually have it work? I'm guessing it's more complicated than that |
| 00:37.10 | Corydon76-dig | They'd have to have different names and one of them should not register callbacks to the VMI system |
| 00:37.31 | Corydon76-dig | err, MWI system |
| 00:37.47 | Corydon76-dig | different application names, that is |
| 00:38.35 | Corydon76-dig | It's complicated enough that it would not be as simple as just loading 2 modules, no |
| 00:40.02 | ricko73 | Corydon76-dig: I don't think you're completely following me. The end user would need to decide which one of the two to use (and noload the other) |
| 00:40.10 | ricko73 | I'm not proposing loading both at the same time |
| 00:40.43 | ricko73 | I'm just trying to find a way to include this without having to have two separate images |
| 00:40.46 | Corydon76-dig | That's the same way that is done now, except the choice is made at compile time |
| 00:41.44 | ricko73 | I would like an end user to be able to make the choice after downloading and installing our distro though and not have to compile it to make the choice |
| 00:42.37 | Corydon76-dig | Sure, you can do that. A similar method is available to users of ABE |
| 00:43.06 | ricko73 | I'm not sure I'm following |
| 00:44.08 | Corydon76-dig | Build one, set it aside, build the other, set it aside |
| 00:44.35 | ricko73 | ok. Do the modules both have to have the same app_voicemail.so name? |
| 00:44.53 | Corydon76-dig | No, there's nothing special about the filename itself |
| 00:45.22 | ricko73 | Oh ok. Cool. Then what I was thinking probably would work. I'll give it a shot. |
| 00:45.25 | ricko73 | Thanks |
| 01:05.21 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 01:23.45 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 01:23.45 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:35.32 | *** join/#asterisk-dev jtodd (i=fo4jhefn@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 01:35.32 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 01:41.44 | *** join/#asterisk-dev jploh (n=chatzill@210.213.254.83) |
| 03:32.31 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 03:32.31 | *** join/#asterisk-dev jploh (n=chatzill@210.213.254.83) |
| 03:32.31 | *** join/#asterisk-dev ricko73 (n=dhartman@wilug/newlug/ricko73) |
| 03:32.31 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 03:32.31 | *** join/#asterisk-dev jeffg (n=jeffg@71-22-212-195.gar.clearwire-wmx.net) [NETSPLIT VICTIM] |
| 03:32.31 | *** join/#asterisk-dev ecrane (n=ecrane@o1-69-19-166-10.static.o1.com) |
| 03:32.31 | *** join/#asterisk-dev jmworx (n=jeval@mail.octasic.com) |
| 03:32.31 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) [NETSPLIT VICTIM] |
| 03:32.31 | *** join/#asterisk-dev Amorsen (n=Amorsen@94.127.50.7) |
| 03:32.31 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 03:32.31 | *** join/#asterisk-dev TheDavidFactor (n=chatzill@fw1.safedataisp.net) |
| 03:32.32 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-7cd3bc2740d6255c) [NETSPLIT VICTIM] |
| 03:32.32 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 03:32.32 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 03:32.32 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 03:32.32 | *** mode/#asterisk-dev [+o Deeewayne] by irc.freenode.net |
| 03:32.36 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 03:32.36 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 03:32.56 | *** join/#asterisk-dev jtodd (i=fo4jhefn@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev tzanger (n=tzanger@208.68.91.47) |
| 03:32.56 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-d082ebe19291af7f) |
| 03:32.56 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev Mw3 (i=mw3@mw3.hu) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev denon (n=denon@synapse.subneural.net) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev jsmith-away (n=jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 03:32.56 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 03:32.56 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) [NETSPLIT VICTIM] |
| 03:32.56 | *** mode/#asterisk-dev [+oooo jtodd mog jsmith-away malcolmd] by irc.freenode.net |
| 03:32.56 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 03:32.56 | *** join/#asterisk-dev wedhorn (n=nnnnnnnn@123-243-209-34.static.tpgi.com.au) [NETSPLIT VICTIM] |
| 03:38.50 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 03:45.52 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 06:22.04 | *** join/#asterisk-dev gardo (n=gardo@110.55.234.101) |
| 06:57.18 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 07:59.35 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 07:59.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:00.23 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 08:19.13 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 08:19.13 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 09:30.06 | *** join/#asterisk-dev sgimeno (n=sgimeno@226.Red-80-33-64.staticIP.rima-tde.net) |
| 10:32.23 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 10:32.23 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:05.28 | *** join/#asterisk-dev msetim (n=setim@189.4.48.141) |
| 11:16.40 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:38.14 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 12:16.02 | *** join/#asterisk-dev jeffg (n=jeffg@71-22-212-195.gar.clearwire-wmx.net) |
| 12:21.42 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:21.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:39.59 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:40.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:57.52 | *** join/#asterisk-dev Omorika (n=omorika@89.201.165.226) |
| 12:58.01 | Omorika | hi |
| 13:05.44 | TheDavidFactor | Hello |
| 13:19.24 | *** join/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 13:23.36 | *** join/#asterisk-dev Daviey_ (n=Daviey@ubuntu/member/pdpc.gold.Daviey) |
| 13:40.38 | TheDavidFactor | are there any bug marshals on here? |
| 13:41.41 | TheDavidFactor | or anyone else that could answer a procedural question for me? |
| 13:46.03 | kpfleming | instead of asking questions about questions, just ask the question |
| 13:48.28 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:48.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:50.23 | atis_work | ok, i have a working patch for my t38 reinvite issue. i wonder if anybody finds some problems with that |
| 13:50.25 | atis_work | 16186 |
| 13:50.39 | TheDavidFactor | My company uses the application ExternalIVR. Because we use it so much we've started running in to bugs with it. I have been fixing the bugs and submitting patches for them to the issue tracker. However it's gotten to the point where one patch depends on another patch and so on. Would it be better to create a single large patch with all known issues resolved that supercedes all previous... |
| 13:50.41 | TheDavidFactor | ...patches or continue doing it via small incremental patches? |
| 13:51.08 | *** join/#asterisk-dev jeffg (n=jeffg@71-22-212-195.gar.clearwire-wmx.net) |
| 13:51.21 | kpfleming | if they are separate problems, separate patches are better |
| 13:51.39 | kpfleming | if they are related problems, then a single issue with a single patch is better, for you and the reviewers |
| 13:52.09 | TheDavidFactor | ok, thank you |
| 13:56.18 | atis_work | There is indeed delay with patches being accepted and merged |
| 13:57.16 | atis_work | I could suggest for You to keep patches depending back a while, or at least mention that in the issue saying that it "depends on issue NNN" |
| 13:57.23 | leifmadsen | TheDavidFactor: if you tell me all the issues, then I can mark certain patches as children to their parents, which enforces that a certain issue isn't resolved until the children are |
| 13:57.33 | atis_work | you will probably need to create them again when they will be ready to merge |
| 13:57.42 | leifmadsen | TheDavidFactor: just tell me what is required for what, and I'll put in all the markers |
| 13:58.36 | kpfleming | you could also consider becoming the maintainer of app_externalivr, and just handling them yourself |
| 13:59.36 | atis_work | can a non-digium person become maintainer? |
| 13:59.40 | kpfleming | yes |
| 13:59.49 | atis_work | oh, cool |
| 14:01.38 | TheDavidFactor | leifmadsen, thanks. However looking back at it I think they all stand alone, it's just that when I set up a new development box, it gets hard to apply four patches because they affect different parts of the code and change line positions which affects the offsets of the other patches. |
| 14:02.07 | leifmadsen | TheDavidFactor: oh nice |
| 14:02.09 | atis_work | TheDavidFactor: i also keep bunch of patches in one big file for me |
| 14:02.11 | leifmadsen | agrees with kpfleming |
| 14:02.31 | leifmadsen | maintaining ExternalIVR on your own since you use it so much, and have the ability to fix issues, would simplify this process |
| 14:02.39 | atis_work | TheDavidFactor: it helps if you're using svn version of asterisk, so you can do "svn diff" and get all patches currently applied |
| 14:03.30 | atis_work | so, when moving to new machine, you just do clean checkout and apply one big patch |
| 14:03.37 | TheDavidFactor | That's also part of it, I'm new to doing this and I started using SVN about half way through my patch creation the earlier ones are based on 1.6.1.6 |
| 14:04.48 | leifmadsen | TheDavidFactor: the amount of change in ExternalIVR between 1.6.1.6 and trunk I would *think* would be minimal |
| 14:05.02 | leifmadsen | it's not a heavily developed application |
| 14:05.11 | TheDavidFactor | I've discovered ;-) |
| 14:06.13 | leifmadsen | but now it can be with you maintaining it! :D |
| 14:06.19 | TheDavidFactor | oh that beings up a new point I wanted to ask, when making a svn diff, where should they be made reletive to? trunk root? |
| 14:07.08 | leifmadsen | TheDavidFactor: yes, that would be ideal |
| 14:07.15 | TheDavidFactor | I am willing to accept the responsibility of maintaining it, what is required? |
| 14:07.26 | leifmadsen | so the path in the patch would be somethign like: apps/app_externalivr.c |
| 14:07.35 | TheDavidFactor | yes |
| 14:07.44 | TheDavidFactor | on the patches, I've submitted so far |
| 14:08.03 | leifmadsen | I suppose we just need to notify russellb so he can determine what all is needed |
| 14:08.04 | TheDavidFactor | it's all over the map, I didn't realized how it worked until I had created a few |
| 14:08.44 | leifmadsen | TheDavidFactor: worst case scenario is that when you run 'patch' it has to ask you which file to actually patch. It just makes it easier when it's relative to SVN room |
| 14:08.46 | leifmadsen | root |
| 14:10.43 | *** join/#asterisk-dev jeffg (n=jeffg@71-22-212-195.gar.clearwire-wmx.net) |
| 14:19.00 | leifmadsen | jsmith: !!! |
| 14:19.08 | leifmadsen | jeffg: no cloak :( |
| 14:19.22 | jsmith | Hey leifmadsen... |
| 14:19.36 | leifmadsen | M16182 |
| 14:19.38 | MuffinMan | [feedback] [Asterisk] Applications/app_dial 0016182: Dial Option D() does not execute in parallel witb option A() reported by falves11 (Karma: -1.5) https://issues.asterisk.org/view.php?id=16182 |
| 14:19.40 | leifmadsen | feels like a feature request to me |
| 14:19.57 | leifmadsen | perhaps I don't understand, but it feels like doing those at the same time isn't possible |
| 14:21.28 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:23.43 | jeffg | leifmadsen, yeah... guess it's not instantaneous. don't need to look at my hostname to peg me as an american ;) |
| 14:23.58 | leifmadsen | ;) |
| 14:24.43 | TheDavidFactor | leifmadsen, is there anywhere in the documentation that says Dial options are supposed to work like that? If not, I would agree (for what it's worth) that it's a feature request not a bug. |
| 14:24.55 | TheDavidFactor | I don't think there is |
| 14:25.08 | leifmadsen | there is nothing that states any options should work in parallel |
| 14:25.13 | leifmadsen | to my knowledge |
| 14:26.52 | jsmith | I concur |
| 14:28.19 | TheDavidFactor | The A option plays a file and the D sends DTMF, if DTMF is inband, and on some channel types this would require audio mixing, which would seem to be a major modification to me |
| 14:28.26 | leifmadsen | I'm closing it then, 2 people stating that is good enough for me |
| 14:30.47 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:30.47 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:39.05 | atis_work | i guess it could be implemented with G and F and Playback/SendDTMF inside |
| 14:39.29 | atis_work | actually there's really no point in A and D options, as gosub provides much more flexibility |
| 14:39.49 | atis_work | i wonder if those could be made deprecated |
| 14:40.23 | atis_work | or we'll run out of available letters :D |
| 15:04.38 | *** join/#asterisk-dev xpot-mobile (n=xpot@173.8.94.1) |
| 15:28.23 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:28.23 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:29.10 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:29.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:36.31 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:36.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:46.39 | *** join/#asterisk-dev moy (n=moy@74.12.130.190) |
| 15:48.22 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 15:48.22 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:52.42 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 15:53.10 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:53.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:55.08 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:55.08 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:07.21 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:26.43 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:42.16 | atis_work | i wonder what was the reason behind failing if #include config_file doesn't exist |
| 16:42.30 | kpfleming | because it's pretty serious |
| 16:42.43 | kpfleming | if you want that config file to be optional, use #exec cat config_file instead |
| 16:43.03 | atis_work | aah, exec doesn't check anything? |
| 16:43.22 | atis_work | it's pretty annoying if i want to have localized changes on some machines :) |
| 16:45.08 | kpfleming | #exec cat should do what you need then |
| 16:46.53 | atis_work | yeah, i'm trying that now, but it doesn't seem to work.. and yes, i enabled execincludes=yes |
| 16:47.03 | atis_work | debug on :) |
| 16:51.41 | atis_work | aah, all i needed was full path. thanks for the user support :) |
| 16:52.08 | kpfleming | i'd say you owe me a beer, but i don't drink beer :-) |
| 16:52.29 | atis_work | some riga black balsam perhaps? |
| 16:52.36 | kpfleming | heavens no |
| 16:52.50 | atis_work | oej liked it |
| 16:54.38 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 16:56.52 | *** join/#asterisk-dev ctooley (n=ctooley@c-76-22-246-7.hsd1.tn.comcast.net) |
| 16:56.53 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 17:26.05 | *** join/#asterisk-dev errotan (n=errotan@a1744.adsl.pool.eol.hu) |
| 17:38.55 | *** join/#asterisk-dev Praise (n=Fat@unaffiliated/praise) |
| 17:45.47 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:45.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:06.39 | *** join/#asterisk-dev xpot-mobile (n=xpot@173.8.94.1) |
| 18:33.12 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:55.31 | TheDavidFactor | do the names on the issues translate to IRC? Basically mnick left a question on an patch I submitted and I wanted to discuss it. |
| 18:56.13 | TheDavidFactor | if he's on here |
| 18:56.26 | atis_work | did you mean mnicholson? |
| 18:56.47 | atis_work | sometimes they translate, sometimes you just have to know |
| 18:58.30 | TheDavidFactor | I don't know, I was hoping someone on here would know |
| 18:58.34 | atis_work | however, unless it's really realtime discussion, it's better to answe it on the issue tracker |
| 18:59.49 | atis_work | TheDavidFactor: which name and issue are you refering to? |
| 19:00.18 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 19:00.44 | kpfleming | i don't believe mnick is here |
| 19:02.11 | TheDavidFactor | if I look at the issue the comment's not there, but I got an email with the comment; however looking at the issue history I see that the comment was added then deleted so I guess it doesn't matter. :-) thanks for the help |
| 19:02.47 | TheDavidFactor | I missed the note deleted the first time I looked at it |
| 19:11.01 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 19:11.01 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:11.12 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 19:16.06 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:18.07 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 19:25.27 | mnicholson | atis_work, TheDavidFactor, mnick is a different person than me. The names are the same sometimes but not always. |
| 19:27.17 | TheDavidFactor | k :-) |
| 19:28.15 | TheDavidFactor | I was confused because I got an email with the note, but it wasn't there when I went to look at the issue. I didn't know notes could be deleted so I didn't think to check the history until after I had already opened my big mouth in here :-) |
| 19:28.41 | *** join/#asterisk-dev work|philipp64 (n=chatzill@63.224.43.239) |
| 19:56.29 | *** join/#asterisk-dev moy (n=moy@74.12.130.190) |
| 20:01.46 | mvanbaak | magguh |
| 20:04.40 | leifmadsen | mvanbaak: ! |
| 20:05.01 | mvanbaak | leifmadsen: ?!?!?!?!?!? |
| 20:05.15 | leifmadsen | hi! :) |
| 20:05.25 | mvanbaak | hey man, howz things ? |
| 20:05.36 | mvanbaak | all 3 houses ok ? |
| 20:05.50 | leifmadsen | haha, yes, still all good thus far :) |
| 20:06.02 | mvanbaak | lol |
| 20:16.38 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:00.22 | work|philipp64 | anyone know if kpfleming might be back? my understanding is that he might be on the road or about to be on the road. |
| 21:03.28 | kpfleming | i am here, but quite busy, and leaving tomorrow morning |
| 21:05.30 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 21:05.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:05.55 | work|philipp64 | if you have a jiff, can you look at 15759? I'd like to make some progress, now that I'm caught up (and closed out) on 4 other bugs. thx. |
| 21:06.15 | kpfleming | i do not have time right now |
| 21:06.49 | work|philipp64 | ok... well, maybe Corydon76-dig can throw an eyeball on it... |
| 21:09.59 | Corydon76-dig | That issue is a feature request without a patch. |
| 21:10.29 | Corydon76-dig | As such, it falls well below most other issues |
| 21:11.29 | Corydon76-dig | In fact, it should probably be closed as feature requests without patches should go on the Wiki, not on the issue tracker |
| 21:18.20 | work|philipp64 | ok... so what is the correct way to build out-of-tree modules? can someone document that please? |
| 21:18.40 | tzafrir | I'm looking for a somewhat small and self-contained "introductory" coding task: |
| 21:18.59 | Corydon76-dig | work|philipp64: add it to the tree and build |
| 21:19.00 | work|philipp64 | I had been using your Makefile.module attachment and it worked fine. |
| 21:19.12 | work|philipp64 | Can we make it a permanent part of the tree? |
| 21:19.35 | work|philipp64 | (I mean the Makefile.module file...) |
| 21:20.00 | work|philipp64 | we have reasons for not wanting to do in-tree builds. |
| 21:20.06 | Corydon76-dig | While you're certainly welcome to continue using it, it really doesn't belong in the mainline tree |
| 21:20.13 | tzafrir | I'm in touch with a local college to have CS students do a semesterial project that's supposed to be "working with industry" with a large enough free software project |
| 21:20.24 | tzafrir | and Asterisk seems to fit the bill |
| 21:20.24 | Corydon76-dig | I have reasons for wanting a million dollars |
| 21:20.42 | work|philipp64 | why doesn't it belong in the tree? |
| 21:21.26 | kpfleming | if it's in the tree, you might as well fix the current Makefiles to be usable, instead of duplicating stuff |
| 21:21.48 | work|philipp64 | ok, then let's do that. |
| 21:22.03 | kpfleming | which will be done when someone has time to do it |
| 21:22.19 | tzafrir | Projects are intended for a pair of students for a semester. Only one I could think of is (optionally) replacing the internal editline with libedit |
| 21:22.32 | tzafrir | and fixing CLI odities |
| 21:22.44 | Corydon76-dig | tzafrir: is libedit BSD-licensed? |
| 21:22.55 | work|philipp64 | how about adding libipq support for NAT-helpering in Asterisk? |
| 21:22.56 | tzafrir | yes. It is used by, e.g. openssh |
| 21:23.07 | leifmadsen | tzafrir: what CLI oddities? |
| 21:23.23 | tzafrir | try using backspace in the wrong place |
| 21:23.42 | leifmadsen | ah |
| 21:24.25 | tzafrir | work|philipp64, what can you do with libipq? |
| 21:24.35 | tzafrir | Does it require asterisk running as root? |
| 21:27.17 | work|philipp64 | tzafrir: if your Asterisk running on the box that's also your NATting border router, then it can do the header rewriting of your SIP and SDP streams. |
| 21:27.17 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:27.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:27.55 | work|philipp64 | this is usually the scenario in Astlinux (which uses a single solution-in-a-box internet application device). |
| 21:28.10 | work|philipp64 | it's potentially the case in a lot of SOHO scenarios. |
| 21:28.40 | work|philipp64 | you want it there, so that your traffic gets shaped properly. |
| 21:28.49 | work|philipp64 | (and your QoS doesn't suffer.) |
| 21:29.35 | tzafrir | does it require asterisk running as root? |
| 21:30.02 | work|philipp64 | Corydon76-dig: how about putting Makefile.module into a subdirectory as an "example", and allowing someone to link to it from $(TOPDIR) ? |
| 21:30.40 | work|philipp64 | tzafrir: not sure. you might have to start out as root and then setuid() as something else once you've CAPped yourself. |
| 21:31.48 | Corydon76-dig | work|philipp64: While I appreciate that this is something you'd like to have done, you need to appreciate that I have other, higher priorities than debating this issue with you. |
| 21:32.25 | tzafrir | libipq? libnetfilter? |
| 21:34.11 | work|philipp64 | Corydon76-dig: I don't doubt that. I was just thinking that since the file is written, and extensively tested... that's 97% of the work right there. |
| 21:34.28 | work|philipp64 | be a shame to not have that effort be used more widely. |
| 21:34.53 | work|philipp64 | maybe leif would do the honors and commit it... :-) |
| 21:35.05 | work|philipp64 | tzafrir: yes. |
| 21:35.26 | leifmadsen | I didn't hear nuthin' |
| 21:35.48 | work|philipp64 | see my posting of 11/6/2008 -- Adding netfilter NATting/ALG support to chan_rtp |
| 21:35.57 | leifmadsen | is busy working on other things |
| 21:36.40 | tzafrir | chan_rtp? |
| 21:37.34 | TheDavidFactor | I'm creating a AST LIST and I'm emptying it using a while loop and AST_LIST_REMOVE_HEAD, is there a better way to do that? |
| 21:38.00 | Corydon76-dig | TheDavidFactor: nope |
| 21:38.44 | TheDavidFactor | ok, thanks; just wanted to make sure. I thought there might be an AST_LIST_EMPTY function or something, but I didn't see any |
| 21:39.15 | Corydon76-dig | There is, but it doesn't do that. It's a boolean function, to check if the list is empty or not |
| 21:39.30 | TheDavidFactor | yea, I found that one, not quite what I needed :-) |
| 21:39.31 | work|philipp64 | tzafrir: no? |
| 21:40.30 | work|philipp64 | hopes that might leifmadsen might think of bug 15759 when he finds himself sitting idly with nothing to do (and pigs start flying). |
| 21:41.48 | work|philipp64 | tzafrir: forget that there's already bug 13833 ... |
| 21:42.40 | tzafrir | work|philipp64, I'm not really sure what would be the simple task here |
| 21:43.38 | work|philipp64 | well, the way that oej and jsmith discuss it in the asterisk-dev thread is pretty heavy duty... and much, much broader in scope. |
| 21:44.49 | work|philipp64 | what I think would be handy (since NAT seems to plague a lot of people that can't set it up correct, and a lot of handsets and ATA's don't handle it properly in all cases) would be to just have Asterisk poke into the netfilter (via libipq) and tell it about the NAT associates and how to remap them. |
| 21:45.39 | work|philipp64 | I'm guessing it's 500 lines or less. the bear is testing it and documenting it so that people don't get any more confused than they are already. |
| 21:47.00 | work|philipp64 | also, would it be added to chan_sip/chan_rtp as additional shared functionality, or done as a completely separate (but cooperating) module, say a func_nat.so ? |
| 21:50.56 | work|philipp64 | MuffinMan: you slacking off? :-) |
| 21:51.26 | work|philipp64 | <PROTECTED> |
| 21:52.35 | leifmadsen | you mean M13833 |
| 21:52.50 | *** join/#asterisk-dev gardo (n=gardo@110.55.242.67) |
| 21:53.51 | tzafrir | M13833 |
| 21:53.53 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/NewFeature 0013833: Add netfilter functionality to asterisk to plumb NAT holes for RTP when running on NATting router reported by pprindeville (Karma: +5.00) https://issues.asterisk.org/view.php?id=13833 |
| 21:53.56 | work|philipp64 | leifmadsen: yes, but that doesn't seem to be working either... |
| 21:54.06 | work|philipp64 | ah, ding... must have fallen asleep. :-) |
| 21:54.20 | leifmadsen | work|philipp64: it does when it's at the beginning of a line |
| 21:55.00 | work|philipp64 | I've reopened it, and will do the work myself as time and competence allows. |
| 21:55.13 | tzafrir | it's not a (dialplan) function. |
| 21:55.25 | work|philipp64 | I'll have to get an additional DID and association from my ILEC, since I don't want to take down my production service. |
| 21:55.35 | work|philipp64 | they're nimrods, though... so it might take a while. |
| 22:04.45 | russellb | Corydon76-dig: rmudgett pointed out that right above what you changed in app_meetme for MEETME_INFO() has the same problem |
| 22:08.45 | Corydon76-dig | Mmm |
| 22:09.09 | russellb | silly coder alert! |
| 22:09.15 | russellb | s/coder/code/ |
| 22:09.17 | russellb | maybe coder, too |
| 22:11.36 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 22:11.37 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 22:13.08 | russellb | thanks Corydon76-dig |
| 22:24.16 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 22:24.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:25.36 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 22:25.37 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:46.32 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 22:46.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:48.05 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 22:48.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:59.59 | leifmadsen | hmmm, am I missing something that would cause the GOSUB_RETVAL to be empty? GoSub() doesn't seem to work for me in 1.6.2 latest |
| 23:13.30 | putnopvut | I have a crash occurring right now, and the reason is not particularly clear. I have a SIP phone placing a call through a local channel to another SIp phone. The callee side queues an AST_CONTROL_CC frame. The function which queues the frame allocates the payload of the frame on the heap. I point the frame->data.ptr to the allocated data and set frame->datalen to be the size of the allocation. |
| 23:14.09 | kpfleming | where does the frame header live? |
| 23:14.28 | putnopvut | I don't understand the question. |
| 23:14.39 | kpfleming | the struct ast_frame is on the stack? |
| 23:14.46 | putnopvut | Yes. |
| 23:15.16 | kpfleming | did you set ->mallocd in the frame? |
| 23:15.25 | putnopvut | Yes, I set it to AST_MALLOCD_DATA. |
| 23:15.32 | putnopvut | (I was getting to that) |
| 23:15.38 | kpfleming | ok |
| 23:16.37 | putnopvut | The data is indicated to the local channel, which then queues the frame to the other side. When the frame is then read on the first leg of the call, the data I get is not what is expected. |
| 23:16.42 | putnopvut | Attempting to read it causes a crash. |
| 23:16.57 | putnopvut | What I'm wondering is if I am making improper assumptions about how frame data is treated. |
| 23:17.32 | putnopvut | I'll pastebin the valgrind output, but it might not be helpful if you haven't looked at the CCSS source much. |
| 23:17.56 | kpfleming | well, someone else will have to dive in that deeply... i'm too deep in this fax stuff |
| 23:18.03 | putnopvut | http://pastebin.ca/1658882 |
| 23:18.19 | putnopvut | gotcha. I was hoping someone in the channel might be able to shed some light on the problem. |
| 23:18.47 | kpfleming | what argument can i pass to asterisk to have it stop making my console be gray text on a gray background? i don't know when this got changed, but it's incredibly annoying |
| 23:19.06 | jpeeler | W |
| 23:19.07 | putnopvut | gray text on a gray background? That's weird. |
| 23:19.30 | kpfleming | it won't accept W or w |
| 23:19.35 | kpfleming | this is 1.6.0, maybe it's been changed |
| 23:19.43 | jpeeler | oh, no that doesn't exist there |
| 23:20.33 | putnopvut | In 1.6.0 it probably uses the scheme of dark gray background and white text like in earlier versions. |
| 23:20.40 | kpfleming | yeah |
| 23:20.43 | kpfleming | it's awful |
| 23:20.47 | putnopvut | It's not until recently that the ability to use your configured background color was added. |
| 23:20.58 | kpfleming | i don't remember it being this way, but maybe i had my konsole session set differently |
| 23:21.11 | *** join/#asterisk-dev TheDavidFactor-H (n=chatzill@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 23:21.25 | putnopvut | Oh well, I'll keep hacking away at this frame problem. |
| 23:23.58 | russellb | putnopvut: I looked at the valgrind and such, but I don't know what to say without diving into the code with you |
| 23:24.15 | putnopvut | russellb: you're certainly invited to come over here if you want to take a closer look. |
| 23:24.18 | russellb | putnopvut: is this code that is committed? |
| 23:24.22 | putnopvut | Yes. |
| 23:24.30 | russellb | k, i'm lazy, i'll look from here for now |
| 23:24.58 | putnopvut | russellb: sure. The key areas to look in are ast_queue_cc_frame in channel.c and ast_handle_cc_control_frame in ccss.c |
| 23:25.14 | russellb | k! |
| 23:25.38 | putnopvut | russellb: I'm looking at the frame-handling code to be sure I am not making improper assumptions. |
| 23:28.19 | russellb | how long is this call running? |
| 23:28.27 | russellb | you have a memory leak here, btw |
| 23:28.41 | putnopvut | How long is what call running? |
| 23:28.48 | russellb | nevermind that question |
| 23:28.55 | putnopvut | Where's the leak? |
| 23:28.58 | russellb | mem leak: you calloc() this payload, but ast_queue_frame() doesn't keep that |
| 23:29.14 | russellb | ast_queue_frame() mallocs a whole new frame with a big enough allocation to hold your payload, too |
| 23:29.37 | russellb | by calling ast_frdup() |
| 23:29.46 | russellb | so that payload you allocated is leaked |
| 23:29.55 | putnopvut | But shouldn't my marking the frame's mallocd field mean that it is freed properly when the frame is freed? |
| 23:30.11 | russellb | it doesn't free your frame |
| 23:30.16 | russellb | that's the job of your code |
| 23:30.28 | putnopvut | ast_queue_frame doesn't free the frame passed in? |
| 23:30.33 | russellb | it does not |
| 23:30.55 | kpfleming | no, very few API calls consume frames |
| 23:31.27 | putnopvut | Ah, so the the AST_MALLOCD_DATA flag just tells ast_frdup to create a large enough frame and copy the data into it. |
| 23:31.35 | putnopvut | It doesn't ensure the destruction of the malloced data. |
| 23:31.36 | Corydon76-dig | ast_queue_frame actually copies the frame passed in |
| 23:31.45 | putnopvut | In that case, there's no reason to malloc it in the first place then. |
| 23:31.48 | kpfleming | no, ast_frdup doesn't even pay attention to that flag |
| 23:31.49 | russellb | putnopvut: right |
| 23:31.51 | putnopvut | (in my case that is) |
| 23:32.00 | russellb | putnopvut: yes, you should just stackify it here |
| 23:32.23 | putnopvut | So what does that flag do exactly? |
| 23:32.34 | *** join/#asterisk-dev jetsnoc (n=jetsnoc@72.22.242.66) |
| 23:32.43 | russellb | if ast_frame_free() gets called with a frame set up that way, it will ast_free() the frame->data |
| 23:32.44 | putnopvut | Ah, it causes ast_frame_free to free the frame->data |
| 23:32.59 | russellb | but in practice, I'm not sure if that ever happens ... |
| 23:34.15 | putnopvut | ugh, I wish there were a way to specify a frame data copy callback. |
| 23:34.52 | putnopvut | crap. In a matter of a couple of hours, this code has gone from "almost done" to "total disaster" |
| 23:37.16 | russellb | :-/ |
| 23:37.40 | kpfleming | why would you want a frame data copy callback? |
| 23:37.47 | russellb | do you have an idea about the crash now or do you want me to keep looking? |
| 23:38.19 | putnopvut | russellb: not yet. |
| 23:39.04 | putnopvut | kpfleming: conceivably to execute a deeper copy of frame data if it makes sense to do so. |
| 23:39.04 | kpfleming | frames should never contain embedded pointers |
| 23:39.24 | putnopvut | And I was supposed to know this how? |
| 23:39.34 | kpfleming | i don't know... it seems logical to me. |
| 23:39.43 | kpfleming | if you think about frames being sent across IAX2, for example. |
| 23:39.50 | kpfleming | frames are not RPC, they are messages. |
| 23:39.57 | kpfleming | each message stands on its own. |
| 23:41.05 | putnopvut | Okay, but here's the problem. Part of the data that I need to send across is an opaque structure. I can only have a pointer to it, at least not the way I've done it so far. |
| 23:41.23 | putnopvut | Now my sentences don't make sense either. |
| 23:42.56 | Corydon76-dig | Can the opaque structure be encoded into the frame buffer somehow? Or is the point to modify the original structure from across the bridge? |
| 23:43.42 | putnopvut | Corydon76-dig: Well one thing I could do is to move the ast_queue_cc_frame definition from channel.c into ccss.c, where the opaque structure would no longer be opaque. That way, I could actually just embed the structure within the frame. |
| 23:44.14 | putnopvut | I suppose I'll try that first and see if the crash gets resolved. |
| 23:44.17 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@212.179.75.202) |
| 23:44.17 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 23:49.34 | Corydon76-dig | file: ping |
| 23:49.43 | file | pong |
| 23:49.53 | Corydon76-dig | I have an audiohook question for you |
| 23:49.55 | russellb | hides file from Corydon76-dig |
| 23:50.17 | file | questions asked may get answered. |
| 23:51.00 | Corydon76-dig | In 1.4, in ast_write (channel.c:2894), what happens with the old_frame between AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END is different. |
| 23:51.10 | Corydon76-dig | Is this a typo or is this intentional? |
| 23:52.09 | Corydon76-dig | It looks like a frame memory leak to me, but I could be mistaken |
| 23:52.21 | file | do you mean what happens if? |
| 23:52.28 | Corydon76-dig | Right |
| 23:52.49 | file | it gets freed at the bottom of the function |
| 23:53.15 | putnopvut | Yay! I fixed the crash! Thanks everyone! |
| 23:53.26 | putnopvut | Now I have a different one to take care of :( |
| 23:53.56 | Corydon76-dig | file: okay. There's still the question of why it's different. |
| 23:54.29 | file | dunno, was probably just copied |