| 00:09.24 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 00:37.43 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 00:38.28 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 00:52.42 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 00:52.42 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 01:02.51 | *** join/#asterisk-dev moy (n=moy@189.169.208.231) |
| 02:50.48 | eliel | M13114 |
| 02:50.50 | MuffinMan | [new] [Asterisk] Core/Channels 0013114: [feature request] Cannot bind selectively to multiple IP addresses reported by zenon (Karma: neutral) http://bugs.digium.com/view.php?id=13114 |
| 02:51.51 | eliel | What is the policy for feature request's? We close this issue after 2 weeks without a contribution? |
| 02:52.25 | snuff-work | mm well there has been other bugs listed for that.. |
| 02:54.41 | eliel | and not a formal patch to fix it... you think it should be closed? |
| 02:56.00 | snuff-work | if u can find the other bugs that reference it sure.. just relate them together.. i think fleming did that with another few bugs |
| 02:57.05 | eliel | I have already done that: |
| 02:57.08 | eliel | M 11853 |
| 02:57.14 | eliel | M11853 |
| 02:57.18 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0011853: bindaddr problems reported by zenon (Karma: neutral) http://bugs.digium.com/view.php?id=11853 |
| 02:57.54 | eliel | Closed by Tilghman, but he wrote a note and for that note, the user is opening again this feature request. |
| 02:58.55 | snuff-work | mm.. if he wants it as a bounty or something u have oej's site.. asteriskideas.org i think.. |
| 03:00.53 | eliel | thnks |
| 03:01.30 | snuff-work | basically its on the 'todo' eventually as i understand it |
| 03:07.58 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:07.58 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:28.12 | Juggie | russellb, its bed time |
| 03:50.02 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 03:59.52 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 05:26.44 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:39.47 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-4396818.home.otenet.gr) |
| 05:52.22 | *** join/#asterisk-dev CunningPike_ (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 06:31.50 | *** join/#asterisk-dev dominic1 (n=dob@213.221.82.242) |
| 06:32.00 | dominic1 | hello guys |
| 06:32.58 | dominic1 | can anybody tell me which loglevels are possible? WARNING, DEBUG and NOTICE. Anything else? |
| 06:38.24 | jsmith | Sure... check logger.conf |
| 06:38.38 | jsmith | DTMF is the one that comes to mind |
| 06:39.58 | tzafrir_laptop | info, dtmf |
| 06:47.51 | jameswf-home | dtmf sounds like a fun log |
| 06:48.30 | dominic1 | I saw that the rewritten version of http://paul.voinetworks.net/func_devstate.c is showing warning everytime a devstate is set. I need this function very often in my system and wanted to rewrite the code. I think I should set the loglevel to debug. Is that right? |
| 06:51.21 | jameswf-home | i dont see dtmf in syslog_level_map |
| 06:52.08 | *** join/#asterisk-dev Dovid (n=Dovid@bzq-82-81-16-221.red.bezeqint.net) |
| 07:03.36 | *** join/#asterisk-dev grEvenX (n=even@ap39pb.ip.ssc.net) |
| 08:13.09 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 08:18.04 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.141) |
| 08:42.45 | *** join/#asterisk-dev xrg_ (n=panos@cpe-77-83-154-127-dsl.netone.gr) |
| 08:51.10 | *** join/#asterisk-dev freddyk (n=freddy@host131-140-dynamic.42-79-r.retail.telecomitalia.it) |
| 10:05.02 | *** part/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 10:06.27 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 10:46.36 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 11:53.59 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:07.20 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:16.07 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 12:16.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:37.27 | *** join/#asterisk-dev yakimbo64 (n=yakimbo6@193.251.169.129) |
| 12:37.56 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 12:37.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:38.28 | yakimbo64 | hello |
| 12:38.51 | yakimbo64 | i'm trying to dp passthrough calls with g729 |
| 12:39.50 | yakimbo64 | my softphone is in g729 >> asterisk g729 in passthrough >> destination softphone in g729 |
| 12:40.16 | yakimbo64 | so whene i place a call, my asterisk box is doing passthrough and voice quality is great |
| 12:40.48 | yakimbo64 | but whene orininating a call using AMI the call fails |
| 12:46.18 | sruffell | yakimbo64: You probably want to head over to asterisk-users to ask your question. |
| 12:46.45 | ctooley | yakimbo64, #asterisk is the place for that kind of issue. |
| 12:47.01 | sruffell | or asterisk. shows you what I know. :) |
| 12:47.34 | ctooley | yakimbo64, ignore sruffell. :) |
| 12:47.43 | yakimbo64 | ok thanks |
| 12:48.17 | yakimbo64 | so asterisk have more knowledges than devs ;) |
| 12:48.31 | ctooley | yakimbo64, hopefully |
| 12:49.18 | ctooley | sruffell, and the only thing he'll take out of either of our comments is me telling him to ignore you. :( |
| 12:49.30 | sruffell | heh |
| 13:01.13 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 13:08.20 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:08.50 | *** join/#asterisk-dev Dovid (n=Dovid@bzq-79-181-111-122.red.bezeqint.net) |
| 13:29.03 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 13:29.03 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 13:31.18 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-c039e328375eb5ca) |
| 13:50.13 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:50.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:54.28 | *** join/#asterisk-dev dbailey (n=doug@216.207.245.1) |
| 14:02.04 | ctooley | <PROTECTED> |
| 14:02.06 | ctooley | Nice |
| 14:02.42 | ctooley | I know those numbers don't mean anything, but I still like seeing them |
| 14:02.57 | eliel | oej: sip.conf.sample should be changed to remove the difference between peer/user in the configuration file, I think you know better than anyone what should be removed from that file.. just a reminder. |
| 14:03.27 | caio1982 | file: a few days ago you said in #asterisk extending the use of ATTENDED_TRANSFER_COMPLETE_SOUND to other channels would be easy... do you think is there anything plain wrong in http://caio.ueberalles.net/asterisk/atxfer_complete_sound2.diff ? |
| 14:03.39 | caio1982 | file: i was about to file a bug with it but i wanted to make sure it wasnt going to be bad |
| 14:03.43 | oej | You are right, the configuration options are the same now, eliel, but there's still a difference between a peer and a user. |
| 14:06.44 | eliel | oej: (user = friend) != peer |
| 14:07.31 | eliel | oej: onlymatchonip ?? |
| 14:07.46 | oej | yep |
| 14:10.29 | ctooley | RTP in Asterisk seems to be at least doing a little better, I've gotten to 952 channels without audio quality getting too bad. |
| 14:12.02 | eliel | oej: strange... ->onlymatchonip is never used (??) |
| 14:12.34 | oej | I mailed a question to murphy and then let it be I guess. |
| 14:12.51 | oej | I wanted to have one hash table but kept multiple for now. |
| 14:13.04 | eliel | ok |
| 14:13.11 | oej | So that variable is waiting for murphy's love and tenderness |
| 14:13.14 | oej | :-) |
| 14:14.20 | eliel | M13133 |
| 14:14.23 | MuffinMan | [new] [Asterisk] General 0013133: [patch] Some fixes to autocompletion in some commands. reported by eliel (Karma: +127.00) http://bugs.digium.com/view.php?id=13133 |
| 14:14.41 | eliel | If you have the time take a look at this patch, fixes autocompletion in 'sip prune realtime' |
| 14:21.31 | ctooley | I have a issue and I'd like some feedback. |
| 14:22.35 | *** join/#asterisk-dev xrg_ (n=panos@cpe-77-83-154-127-dsl.netone.gr) |
| 14:22.59 | ctooley | When running tests, I have a phone connected to the Asterisk server handling all of my inbound calls for the concurrent call tests and I'm using ${CHANNEL(rtpqos,audio,local_lostpackets)} to detect packet loss. |
| 14:24.39 | ctooley | However, before that number gets above 1 for any given channel, the phone I have connected starts to sound bad. At over 950 channels it doesn't sound as good (it's understandable but audio gets delayed, and there's minor cuts in the audio). |
| 14:25.07 | ctooley | Should I try to use the subject "does it sound good" or should I just rely on the packet loss counter for my test results? |
| 14:31.10 | putnopvut | ctooley: I'm by no means a benchmarking expert, but imho, it makes more sense to report the sound quality since most people will depend on that. Of course, it's a lot harder to represent in a truly scientific manner. |
| 14:31.24 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 14:31.24 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:31.47 | ctooley | putnopvut, that's my thought too, but I'm not sure how to do it in a reliable manner. |
| 14:32.10 | putnopvut | Right, sound quality is hard to represent objectively. |
| 14:37.56 | eliel | I don't know if this was discussed but it would be nice to have a 'sample of usage' in the app xmldoc, an image/sample worth a thousand words... |
| 14:42.34 | *** join/#asterisk-dev pgarcia (n=Miranda@yoda.kanatek.com) |
| 14:43.03 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:43.03 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:43.40 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:47.48 | De_Mon | putnopvut sound quality is just playing a sound, and recording what it sounds like on the other end and comparing the two isn't it? |
| 14:48.18 | De_Mon | i'm sure some coder person could make something that did that like, instantly or really fast at least. |
| 14:48.50 | putnopvut | I know there is equipment which can do that. The problem is that it's hard to interpret those sorts of results into meaningful data. |
| 14:48.51 | eliel | De_Mon: You are adding load to the system while trying to record... |
| 14:49.48 | De_Mon | I thought load tests generally required two points |
| 14:50.29 | De_Mon | voip, the merging of it and audio engineers |
| 14:55.05 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 15:21.28 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:21.28 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:50.04 | tzafrir_laptop | nice: in svn 1.5 (?) - svn diff -x -p |
| 15:50.11 | tzafrir_laptop | A nicer-looking patch |
| 15:50.41 | Qwell | nicer-looking? |
| 15:50.50 | Qwell | tzafrir_laptop: pastebin an example? :) |
| 15:52.46 | JerJer | yawns |
| 15:52.56 | tzafrir_laptop | the same as diff -u -p - (--show-c-functions) |
| 15:53.10 | Qwell | ahh |
| 15:53.14 | Qwell | neat |
| 15:53.49 | Qwell | technically, you could do that in 1.4, it's just harder |
| 15:54.58 | Qwell | ..I think |
| 15:55.17 | JerJer | it sucks getting old - i party for one long weekend (in NYC) and it has taken me two days, so far, to recover |
| 15:55.39 | Qwell | tzafrir_laptop: svn diff --extensions="-up" --diff-cmd=diff |
| 15:56.10 | tzafrir_laptop | yeah. Just longer to write. |
| 15:57.08 | Qwell | I guess really you just have to add the --diff-cmd |
| 15:57.11 | tzafrir_laptop | that --show-c-functions gives very handy context to a patch |
| 15:57.17 | Qwell | -x -up --diff-cmd=diff |
| 15:58.08 | tzafrir_laptop | Maybe it's worth recommending in the guidelines to use such patches |
| 15:58.09 | kpfleming | tzafrir_laptop: we can't use p.chan_alarms, without adding a configure script test to see if channel alarms are available in the version of zaptel we are building against |
| 15:58.19 | kpfleming | if we are going to do that, we might as well add the whole channel alarm support |
| 15:58.38 | tzafrir_laptop | kpfleming, in 1.6 there's dahdi and hence those must be available |
| 15:58.45 | kpfleming | this is not 1.6 |
| 15:58.47 | kpfleming | this is 1.4 |
| 15:58.58 | kpfleming | and 1.4 chan_dahdi can be built against zaptel, even old versions of zaptel |
| 15:59.12 | tzafrir_laptop | If you don't use channel alarms, then just give up on this issue |
| 15:59.15 | kpfleming | in 1.6 get_alarms() already calls to check for channel alarms |
| 15:59.32 | kpfleming | i've already done all that can be done for that issue, but you keep reopening it :-) |
| 15:59.33 | tzafrir_laptop | No point calling get_alarms() there, as is adds nothing |
| 15:59.43 | kpfleming | it checks for span alarms too |
| 16:00.09 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 16:00.22 | tzafrir_laptop | because the issue is not fixed. If it cannot be fixed in Asterisk it must be worked around in Zaptel |
| 16:00.30 | kpfleming | what issue? |
| 16:00.54 | kpfleming | adding support for 'dont call out on my FXO if there is no battery' is a new feature for zaptel |
| 16:00.59 | tzafrir_laptop | the InAlarm field is not set properly at startup |
| 16:00.59 | kpfleming | sorry, for asterisk 1.4 |
| 16:01.03 | kpfleming | right |
| 16:01.09 | kpfleming | because asterisk 1.4 doesn't know about channel alarms |
| 16:01.33 | kpfleming | so what does not having it set properly affect? |
| 16:03.21 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 16:04.03 | oron | kpfleming: tryin to call an unconnected FXO is a bug not a feature... |
| 16:04.26 | oron | We can (and have in the past) fix it in our own driver |
| 16:04.35 | oron | We can (and have a local fix) in zaptel. |
| 16:04.52 | kpfleming | that was not the decision that was made when we added channel alarms to zaptel |
| 16:05.02 | kpfleming | we decided that adding support for them to asterisk 1.4 would be adding a new feature |
| 16:05.49 | oron | Does having tmp->inalarm uninitialized look like a feature to you? (the fix is one-line initialization). |
| 16:05.52 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:06.06 | kpfleming | no it is not! |
| 16:06.30 | kpfleming | we cannot use the chan_alarms field of zt_params without adding configure script tests to see if it is available |
| 16:06.58 | kpfleming | yes, having inalarm not initalized when the alarm is a *channel alarm* is expected, since 1.4 does not understand or pay attention to channel alarms |
| 16:07.16 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 16:07.24 | kpfleming | if you guys want to just backport the remaining support for channel alarms to 1.4 then do so, and i'll look at how much it changes things |
| 16:07.40 | oron | kpfleming: So does having the workaround in Zaptel/Dahdi acceptable? |
| 16:07.41 | kpfleming | but you can't assume that zaptel will have them, because asterisk 1.4 could be built against zaptel 1.4 that doesn't support them |
| 16:08.14 | kpfleming | no |
| 16:08.32 | kpfleming | i don't want to have that in the drivers |
| 16:08.46 | kpfleming | if an application wants to try to use a channel that is in alarm, it should be able to do so |
| 16:09.56 | oron | kpfleming: The workaround does not prevent anything. It only notify the application *after* open so it's not lost. |
| 16:10.42 | kpfleming | just backport the channel alarm support to asterisk 1.4 and let's be done with this |
| 16:10.44 | oron | kpfleming: the only thing it prevent is poor users trying to call via unusable trunks. |
| 16:11.45 | oron | kpfleming: Sorry I didn't understand. Have the support in asterisk-1.4 or not? |
| 16:11.51 | kpfleming | yes |
| 16:12.15 | oron | OK, I'll ask Tzafrir to attach the one-liner to the ticket. |
| 16:12.22 | kpfleming | no! |
| 16:12.26 | kpfleming | you must do it properly |
| 16:12.34 | oron | kpfleming: which is? |
| 16:12.41 | kpfleming | you must add the backported *full* channel alarm support that we have in 1.6/trunk |
| 16:12.59 | kpfleming | so that the configure script test gets done to know whether zaptel can supply them |
| 16:13.14 | kpfleming | and so that we can actually call ioctls to check for them |
| 16:13.39 | oron | kpfleming: OK, that's reasonable. I'll look into it. |
| 16:13.42 | kpfleming | thank you |
| 16:14.02 | kpfleming | other than the configure script, it should be very little work |
| 16:14.12 | kpfleming | i'm just in the middle of something else or i'd do it :_) |
| 16:16.05 | tzafrir_laptop | any need for something in autoconf? or just #ifdef-s? |
| 16:16.24 | kpfleming | yes, the configure script has to test for the availability of the chan_alarms field in the structure |
| 16:16.28 | tzafrir_laptop | (if dahdi or newer ioctls) |
| 16:16.56 | kpfleming | for dahdi, you can just set HAVE_DAHDI_CHANALARMS |
| 16:17.13 | kpfleming | for zaptel, check for it, and set HAVE_DAHDI_CHANALARMS based on HAVE_ZAPTEL_CHANALARMS |
| 16:18.09 | oron | kpfleming: good. |
| 16:33.03 | *** join/#asterisk-dev padski (n=padski@93-152-9-9.vibecoms.managedbroadband.co.uk) |
| 16:36.42 | padski | Hi! I'm trying to run asterisk multi-homed, but I'm having trouble getting packets routed out the right interfaces. Seems like every app I test will set the source address on reply packets but my asterisk does not ? can asterisk remember a per-peer source address to use ? |
| 17:11.19 | *** part/#asterisk-dev padski (n=padski@93-152-9-9.vibecoms.managedbroadband.co.uk) |
| 17:15.05 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 17:39.50 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 17:42.41 | pabelanger | Afternoon, am I safe to say chan_zap has been removed from the 1.6.0 branch? |
| 17:42.54 | tzafrir_laptop | putnopvut, the definition og that si you #if-defed in chan_dahdi could be moved to inside the block |
| 17:43.13 | putnopvut | inside which block? |
| 17:44.38 | putnopvut | tzafrir_laptop: the above block is a #if 1 block, and the #ifdef HAVE_PRI block below is after assignment of variables, so I can't define a variable there and expect compilation in dev-mode to work. |
| 17:45.44 | tzafrir_laptop | it is only used in two ioctl-s inside a single block, which is already only used if we have PRI |
| 17:47.01 | putnopvut | Oh, I see what you mean now. |
| 17:47.09 | putnopvut | Okay, I'll make the change. Thanks for pointing it out to me. |
| 17:47.09 | tzafrir_laptop | is the Insects Mantis only for testing? |
| 17:47.17 | putnopvut | yes, it's a test setup. |
| 17:47.22 | putnopvut | I don't know when it's going live. |
| 17:51.37 | pabelanger | We are about to start testing chan_dahdi from the 1.6.0 branch at a customer site. We already have zaptel currently install on the system, can we install dahdi along side it or will there be conflicts? |
| 17:52.43 | kpfleming | installing dahdi will remove zaptel |
| 17:53.04 | kpfleming | well, the modules and header files, not the init script, tools, ec. |
| 17:53.38 | tzafrir_laptop | pabelanger, we build asterisk and such from custom pathes |
| 17:54.21 | tzafrir_laptop | we still have zaptel installed on the system, but we build currently dahdi from a custom directory |
| 17:55.18 | pabelanger | tzafrir_laptop: Thanks, that is what we are looking to do too. |
| 17:56.35 | tzafrir_laptop | We actually use the script in http://bugs.digium.com/11680 to get a "private" asterisk copy |
| 18:00.43 | pabelanger | Great, I was checking it out last week. I'll give it a try and see how it works. |
| 18:04.08 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:10.35 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 18:26.38 | pabelanger | tzafrir_laptop: Thanks for your script (live_ast), this is a great tool to help testing quickly setup test enviorment on a box without affecting the production install. |
| 18:26.40 | pabelanger | Thanks again. |
| 18:29.43 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 18:48.01 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:49.39 | seanbright | bbryant: i think the mime-type settings on insects need some love |
| 18:50.03 | seanbright | bbryant: specifically .diff should be text/plain or something that will open directly in the browser |
| 18:51.45 | seanbright | bbryant: actually, the content type looks correct, but it's sending the content-disposition: attachment header even if i click directly on the filename instead of the little [^] |
| 18:53.41 | bbryant | seanbright: fixed |
| 18:59.42 | seanbright | bbryant: it's about time |
| 18:59.43 | seanbright | ;-) |
| 19:02.07 | Corydon76-dig | tickles seanbright |
| 19:02.23 | *** join/#asterisk-dev Dovid (n=Dovid@tony09-121-90.inter.net.il) |
| 19:02.30 | seanbright | shhh, it's Dovid |
| 19:04.00 | seanbright | i think i might be depressed |
| 19:04.07 | seanbright | i have no desire to code |
| 19:04.47 | Corydon76-dig | seanbright: or just in the wrong occupation... |
| 19:05.02 | seanbright | i'm not good at anything else |
| 19:05.22 | Corydon76-dig | I can't imagine not having the desire to code... though sometimes I don't have an idea of WHAT to code |
| 19:05.47 | seanbright | well maybe that is more apropos for my current state of mind |
| 19:06.01 | Corydon76-dig | aka writer's block |
| 19:06.05 | seanbright | aye |
| 19:07.57 | seanbright | are there control characters that will instruct xterm to copy stuff to the clipboard? |
| 19:09.24 | seanbright | putnopvut: what is the point of snprintf'ing in the first place? why not just compare against a literal Zap/pseudo or DAHDI/pseudo? |
| 19:10.39 | putnopvut | The area of Zaptel/DAHDI eludes me, but I'm guessing that the idea is that apparently the channel could have a name like DAHDI/pseudo-3a3f31cd or something. |
| 19:10.56 | seanbright | well the snprintf doesn't take that into account... |
| 19:11.05 | seanbright | i am referring to channel_name, not this->name |
| 19:11.13 | putnopvut | oh, gotcha. |
| 19:11.30 | putnopvut | well, the reason is that it uses a variable for dahdi_chan_name |
| 19:11.42 | seanbright | ohhhh |
| 19:11.44 | seanbright | gotcha |
| 19:12.05 | putnopvut | technically, we could use some #ifdef HAVE_ZAPTEL magic to figure out what that string should be. |
| 19:12.12 | putnopvut | And then just compare against the literal string. |
| 19:12.15 | seanbright | right |
| 19:12.19 | putnopvut | That would save some stack space. |
| 19:12.34 | seanbright | not a huge optimization by any means |
| 19:12.39 | putnopvut | right. |
| 19:12.53 | seanbright | i really just felt like questioning you |
| 19:13.12 | putnopvut | Cool, glad I could answer satisfactorally. |
| 19:13.17 | seanbright | you pass |
| 19:13.32 | putnopvut | s/satisfactorally./satisfactorily./ |
| 19:14.13 | seanbright | ah, dahdi_chan_name is extern |
| 19:14.18 | seanbright | it all makes sense now |
| 19:15.53 | seanbright | but actually... since you are already doing the check for HAVE_ZAPTEL, might as well make it a #define |
| 19:17.59 | putnopvut | I'm just guessing here, but I bet the reason it was done the way it was is so that dahdi_chan_name is defined at load time instead of at compile time. The thing is, if you switch between zaptel and dahdi, you have to recompile Asterisk anyway, so I'm not sure what the benefit of that is. |
| 19:18.03 | seanbright | and really, not to harp on it... :) but dahdi_chan_name is a runtime setting while the PSEUDO_CHAN_LEN stuff is a compile time thing. not sure if you could end up mixing and matching, but i'm guessing it's possible. |
| 19:18.11 | seanbright | heh |
| 19:18.15 | seanbright | we were on the same track |
| 19:18.50 | seanbright | well they both should be runtime or they both should be compile time, no? |
| 19:21.00 | putnopvut | I agree with that. |
| 19:21.10 | putnopvut | I'll change PSEUDO_CHAN_LEN to be set a load time. |
| 19:21.32 | seanbright | cool |
| 19:21.45 | seanbright | or even better |
| 19:21.52 | seanbright | add a dahdi_chan_name_len |
| 19:21.59 | seanbright | that is set at load time |
| 19:22.21 | seanbright | then you don't have to strlen it all over the place |
| 19:22.56 | seanbright | just a thought. |
| 19:23.40 | putnopvut | hrmmm |
| 19:23.45 | *** join/#asterisk-dev jeffg (i=IjVk1oRn@pdpc/supporter/active/jeffg) |
| 19:24.58 | putnopvut | Okay then, I'll go that route. It makes sense to me. I can easily search and replace any strlen(dahdi_chan_name) too. |
| 19:25.17 | seanbright | only 1 occurence |
| 19:25.20 | seanbright | in chan_dahdi.c |
| 19:31.33 | *** join/#asterisk-dev pjezek (n=pj@193.85.164.154) |
| 19:43.52 | seanbright | i can't believe the kernel developers decided to rename an API call within a non-major release of the kernel |
| 19:44.05 | seanbright | it would have literally taken *1* line of code to allow both to work |
| 19:44.07 | seanbright | trolls |
| 19:44.20 | putnopvut | lol |
| 19:51.00 | putnopvut | With the last commit I just made, it appears as though dahdi_chan_name in 1.6.0 is hardcoded to "ZAP" with no visible means to change to DAHDI. |
| 19:51.25 | putnopvut | I should rephrase. My commit did not change this behavior. It is something I noticed as being there both before and after my commit. |
| 19:51.57 | seanbright | not to be a stickler... |
| 19:52.19 | seanbright | but why introduce the "determine_pseudo_chan_len" call at all? |
| 19:52.51 | seanbright | you could just inline 'dahdi_chan_name_len + strlen("/pseudo")' in the strncmp, no? |
| 19:53.10 | seanbright | just so it doesn't get called every time? |
| 19:53.19 | putnopvut | It's only called at module load time. |
| 19:53.22 | seanbright | gotcha |
| 19:53.50 | seanbright | you should introduce a dahdi_pseudo_chan_name_len variable... |
| 19:53.53 | seanbright | kids |
| 20:00.41 | kpfleming | umm... where is there a dahdi_chan_name in 1.6.0 at all? there is no reason to support 'Zap' channel names in 1.6.0 |
| 20:01.42 | putnopvut | kpfleming: it's in asterisk.c. Trunk also defaults to "ZAP" as dahdi_chan_name but is overridable. |
| 20:02.48 | putnopvut | In trunk, dahdichanname=yes has to be set in asterisk.conf for dahdi_chan_name to be "DAHDI" |
| 20:02.53 | eliel | ping Corydon76-dig |
| 20:03.01 | putnopvut | In fact, "yes" is required. It doesn't use ast_true(). |
| 20:06.22 | kpfleming | before you spend any more time on that, let's verify that it's supposed to be there at all |
| 20:07.19 | Corydon76-dig | eliel: pong |
| 20:07.34 | eliel | M13138 |
| 20:07.38 | MuffinMan | [ready for testing] [Asterisk] Functions/func_dialgroup 0013138: [patch] Update func_dialgroup to store in astdb reported by Corydon76 (Karma: +421.25) http://bugs.digium.com/view.php?id=13138 |
| 20:07.57 | kpfleming | ok, yeah, we did agree that it should be configurable |
| 20:07.58 | eliel | I think ast_db_gettree() -> tmp->key is getting the family/key |
| 20:08.15 | kpfleming | but it should be identical in trunk and 1.6.0 |
| 20:09.16 | putnopvut | Should the default be "ZAP" though? |
| 20:09.18 | Corydon76-dig | eliel: working on it now |
| 20:09.27 | eliel | Corydon76-dig: ok |
| 20:09.30 | kpfleming | no |
| 20:11.13 | putnopvut | Okay, so default to "DAHDI" and keep the same config option "dahdichanname" which if true will use "DAHDI" and if false will use "ZAP?" |
| 20:12.55 | kpfleming | ok, so i redid a bunch of this stuff in 1.4, but hadn't gotten to 1.6 yet, but it needs to be done |
| 20:13.11 | kpfleming | yes, that should be right |
| 20:13.31 | kpfleming | in the absence of any configuration option being set, all the channel names, app names, etc. should be DAHDI |
| 20:13.48 | kpfleming | however, if the user wants to use Zap instead, there is a boatload of stuff that needs to take that into account |
| 20:14.04 | putnopvut | kpfleming: does this mean that I should defer this work to you? |
| 20:14.06 | kpfleming | do a grep on the current 1.4 tree for dahdi_chan_mode (new variable) and you'll see what i mean |
| 20:14.12 | kpfleming | i don't know :-) |
| 20:14.19 | kpfleming | i want to get it done, but keep running out of time |
| 20:14.32 | kpfleming | but it definitely needs to be audited, so we end up with the right stuff |
| 20:14.45 | putnopvut | Okay. Did you finish the 1.4 work? |
| 20:14.58 | kpfleming | i *think* so, but it needs testing |
| 20:15.15 | kpfleming | it needs testing in all four modes... DAHDI with no config option and with, Zaptel with no config option and with |
| 20:15.34 | putnopvut | Okay, so test 1.4 to make sure stuff isn't broken, then merge similar changes to trunk and 1.6.0? |
| 20:16.05 | kpfleming | that would be awesome |
| 20:16.27 | kpfleming | for example, what i worked on yesterday was making sure that all the chan_dahdi manager actions and events had proper names depending on the channel mode |
| 20:16.52 | kpfleming | and ensuring that the actions are available under *both* Zap and DAHDI when Zap mode is on, so that users can upgrade slowly |
| 20:17.30 | seanbright | reboots |
| 20:18.03 | putnopvut | Makes sense. So the main difference between 1.4 and the other branches is that we will allow the *name* "ZAP" but not actually have a chan_zap. This is just so CLI/manager actions/manager/events etc. can report "Zap" if the user wants, correct? |
| 20:18.20 | kpfleming | not quite |
| 20:18.36 | kpfleming | the main difference between 1.4 and 1.6/trunk is that 1.4 can be *built* against zaptel, whereas 1.6/trunk cannot |
| 20:19.01 | kpfleming | but in all branches, they should be able to use Zap channel names, manager actions, etc if they wish |
| 20:19.09 | kpfleming | in 1.4, that is the default if they built against zaptel |
| 20:19.20 | kpfleming | in 1.6, it would have to be enabled via asterisk.conf |
| 20:19.23 | kpfleming | does that make sense? |
| 20:19.29 | putnopvut | Does this include Dialplan channel names? |
| 20:19.32 | putnopvut | Yes, it makes sense. |
| 20:19.45 | kpfleming | all channel names are dialplan channel names... |
| 20:19.57 | putnopvut | Allow me to rephrase. |
| 20:20.12 | putnopvut | Would we accept "Zap" names in the dialplan as well. |
| 20:20.14 | putnopvut | ? |
| 20:20.37 | kpfleming | yes, the channel type is Zap, if the incoming channel names are Zap |
| 20:20.40 | kpfleming | that is mandatory |
| 20:21.21 | putnopvut | Okay, I'll look at your work in 1.4 and make similar changes to trunk/1.6.0 |
| 20:21.29 | putnopvut | I'll set up a trunk branch and begin work on it. |
| 20:21.49 | kpfleming | thanks |
| 20:22.11 | kpfleming | jpeeler tried to do this stuff before, but it wasn't really specified well enough and he didn't quite get all the way thee |
| 20:22.16 | kpfleming | s/thee/there/ |
| 20:23.14 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 20:23.14 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 20:24.14 | jpeeler | yes, and i feel bad it was not adequate, but some of the stuff i just didn't know needed to be done |
| 20:24.34 | *** join/#asterisk-dev padski (n=padski@212.32.79.115) |
| 20:25.08 | kpfleming | putnopvut: i'm going to change your dahdi_chan_name_len stuff a bit |
| 20:25.24 | putnopvut | kpfleming: go for it. |
| 20:25.42 | putnopvut | What do you have in mind for it? |
| 20:25.46 | kpfleming | the only reason to use the _ prefix on dahdi_chan_name was so that the public pointer to it could be 'const' |
| 20:26.09 | kpfleming | so i'll do the same for dahdi_chan_name_len... the public variable will be 'const size_t *' |
| 20:26.30 | kpfleming | don't want it written to outside of asterisk.c |
| 20:27.39 | putnopvut | Okay, I get what you're driving at. |
| 20:27.45 | padski | on #asterisk it was suggested ask here: is there anything like a setting for multi-homed boxes to get * to reply to peers using the local source address of the interface they register on ? |
| 20:28.10 | putnopvut | Maybe put in a macro that will automatically deref the pointer so that there's not *'s all over the place. Just a suggestion. |
| 20:28.39 | kpfleming | naah.. there's not that many places |
| 20:30.00 | putnopvut | padski: multi-homing is something that has been problematic in Asterisk for a while, and unfortunately I do not know of a good way to successfully implement it. |
| 20:31.15 | padski | putnopvut, whatis the problem I'm not seeing. I would have thought that having per peer state for the address to send from would solve my problem nicely |
| 20:31.27 | kpfleming | there isn't any of that |
| 20:31.32 | kpfleming | that's what the problem is |
| 20:31.53 | kpfleming | well, not if you have multiple routes to the same destination network |
| 20:31.56 | padski | kpfleming, but there is per-peer state ? |
| 20:32.06 | kpfleming | do you actually mean multi-homing, or just multiple networks? |
| 20:32.21 | kpfleming | of course there is per peer state, otherwise we couldn't be a SIP registrar |
| 20:32.43 | xrg_ | padski: we are trying to implement such a thing, using the realtime database as a reference point for the multi-homed *'s .. |
| 20:32.58 | padski | kpfleming, I have a box with real IPs on two different ISPs. it is not an AS or anything. |
| 20:33.10 | kpfleming | but unless you use linux-specific APIs, you cannot know what IP address the registration request was received on |
| 20:33.12 | Juggie | putnopvut, i've heard multiple copies bound to different ip's works well. |
| 20:33.19 | seanbright | putnopvut: almost a haiku! |
| 20:33.29 | kpfleming | if you had two distinct networks, it would work fine |
| 20:33.37 | putnopvut | seanbright: heh, I hadn't even noticed that part. |
| 20:33.47 | kpfleming | but if you have multiple routes to the same network (two ISPs connected to the public internet), you will have problems |
| 20:33.48 | *** join/#asterisk-dev anthm (n=anthm@m990736d0.tmodns.net) |
| 20:34.12 | kpfleming | chan_sip does not support multiple bindings yet, so it cannot distinguish requests received on interface 1 from interface 2 |
| 20:34.15 | padski | kpfleming, apache manages it. I belive it still works on nextstep too. mind you noone knows how it workd, and everyone is too scared to touch it ;-) |
| 20:34.52 | padski | Juggie, thanks thats a handy idea! |
| 20:35.24 | kpfleming | apache is TCP, that is a world of difference |
| 20:35.27 | kpfleming | TCP != UDP |
| 20:36.08 | padski | sure, but I'm surprised that it isn't that easy to get the destination address of an incoming packet. |
| 20:36.15 | kpfleming | then be surprised |
| 20:36.20 | kpfleming | there are no POSIX APIs to do it |
| 20:36.21 | seanbright | surprise! |
| 20:36.32 | kpfleming | we can do it on linux, but not on BSD (for example) |
| 20:36.33 | padski | POSIX ! |
| 20:36.37 | padski | heh |
| 20:36.49 | kpfleming | and don't say 'packet', say 'datagram', because that is the important factor |
| 20:37.04 | seanbright | that would get interesting with broadcast dgrams |
| 20:37.12 | padski | kpfleming, ok, datagram it is. |
| 20:37.25 | Juggie | padski, i believe you could do it with say asterisk -C /etc/asterisk_ip1/asterisk.conf and having that one config, then say /etc/asterisk_ip2 as another and so on. |
| 20:37.31 | kpfleming | yes |
| 20:37.37 | Juggie | so long as each copy binds to seperate ip's it should be fine. |
| 20:37.46 | kpfleming | or some day when chan_sip supports multiple bindings like chan_iax2 does, then that would solve the problem as well |
| 20:38.01 | seanbright | speaking of which... is there an IAX analog to the sipp tool? |
| 20:38.05 | Qwell | Juggie: that's an interesting idea |
| 20:38.10 | padski | what is multiple bindings ? |
| 20:38.18 | eliel | M13114 |
| 20:38.20 | MuffinMan | [new] [Asterisk] Core/Channels 0013114: [feature request] Cannot bind selectively to multiple IP addresses reported by zenon (Karma: neutral) http://bugs.digium.com/view.php?id=13114 |
| 20:38.24 | putnopvut | seanbright: unfortunately no. |
| 20:38.48 | Juggie | padski, if chan_sip knew about multiple bindings, it would know which interface a packet arrived on and be sure to send its reply via the same interface |
| 20:38.51 | ctooley | kpfleming, That particular issue is something I'd really like to hammer out the plan for at DevCon |
| 20:38.52 | Qwell | padski: right now, chan_sip can either bind to exactly 1 address, or every address. |
| 20:38.54 | seanbright | putnopvut: well get to work. i'll wait here. |
| 20:38.55 | seanbright | :) |
| 20:39.01 | tzafrir_laptop | seanbright, asterisk |
| 20:39.03 | kpfleming | ctooley: sure, we're most of the way there already |
| 20:39.05 | ctooley | It's a seriously large problem for us. |
| 20:39.06 | seanbright | tzafrir_laptop: true |
| 20:39.14 | Juggie | currentally you can bind to 0.0.0.0 and bind to all ips, but if its multi-homed asterisk is receive via every ip but only send via the first one. |
| 20:39.30 | ctooley | kpfleming, if it's not done before then, maybe we can have a hackathon session and finish it. |
| 20:39.36 | Juggie | as far as chan_sip is concerned. |
| 20:39.53 | Juggie | Qwell, thanks ;) |
| 20:39.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 20:39.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:40.01 | padski | would a patch for that ( teach chan_sip about multiple bindings) be welcome ? how hard would it be ? |
| 20:40.22 | Juggie | send oej 10,000 rubles |
| 20:40.28 | padski | hehe |
| 20:40.29 | kpfleming | yes it would be welcome, and yes it will be a lot of work |
| 20:40.36 | putnopvut | why rubles? |
| 20:40.39 | kpfleming | but some of it has been done already in preparation for TCP/TLS support |
| 20:40.45 | Juggie | putnopvut, no reason just seemed funny. |
| 20:40.49 | putnopvut | :) |
| 20:40.59 | seanbright | i only transact with rupies |
| 20:41.04 | Qwell | Juggie: Russian rubles? |
| 20:41.11 | Juggie | Qwell: exactally |
| 20:41.12 | Qwell | That's like $500 |
| 20:41.13 | putnopvut | seanbright: are you Link? |
| 20:41.25 | seanbright | putnopvut: no, Zelda. |
| 20:41.28 | padski | 250 quid then |
| 20:41.29 | seanbright | ~seanbright |
| 20:41.29 | jbot | you are probably a girl with standards |
| 20:41.51 | seanbright | says you! |
| 20:42.17 | putnopvut | I just messaged jbot to see what he says about me. I had completely forgotten... |
| 20:42.26 | Qwell | ~putnopvut |
| 20:42.27 | jbot | methinks putnopvut is a german shepard that lost his rear left leg fighting the war against cheap dog food |
| 20:42.51 | seanbright | thinks it's just a really difficult name to pronounce |
| 20:42.56 | padski | thanks to all, you've been really helpful |
| 20:43.30 | *** part/#asterisk-dev padski (n=padski@212.32.79.115) |
| 20:43.31 | kpfleming | putnopvut: r133266 in 1.4... if we don't rip out the zap name stuff from trunk, the equivalent changes will be needed there |
| 20:44.02 | putnopvut | kpfleming: roger |
| 20:44.14 | seanbright | over, under. |
| 20:44.19 | Juggie | inside out. |
| 20:44.29 | seanbright | what's your vector, victor? |
| 20:44.33 | Juggie | thats what asterisk-dev is all about |
| 20:48.04 | seanbright | if someone sitting next to you spent all day on the phone with customers and kept saying "flustrated" |
| 20:48.14 | seanbright | what is the appropriate response? |
| 20:48.35 | kpfleming | water cannon? |
| 20:48.53 | seanbright | s/water//? |
| 20:49.11 | seanbright | it's full-contact customer support |
| 20:49.14 | Juggie | well i guess they are both, fustrated and flustered |
| 20:49.14 | ctooley | Juggie, BTW we handle multiple Asterisk instances slightly differently: http://www.simplified.org/trac/wiki/QuadAsteriskInstallation |
| 20:50.01 | Juggie | ctooley, you have a different reason though. |
| 20:50.05 | seanbright | Juggie: that doesn't make it a word though :) |
| 20:50.14 | Juggie | you is for scale, this guy wanted multi-homed. |
| 20:50.17 | kpfleming | if you can type it, it's a word |
| 20:50.30 | seanbright | s/word/English word/ |
| 20:50.39 | seanbright | :P |
| 20:50.39 | ctooley | Juggie, Not really different though |
| 20:50.44 | Juggie | seanbright, tell them your flabbergasted |
| 20:50.55 | seanbright | Juggie: or frabbergasted |
| 20:51.08 | seanbright | ohh gabberflasted |
| 20:51.09 | ctooley | Separate runs are still simpler with completely separate installations. You run into all kinds of issues otherwise. |
| 20:51.11 | seanbright | i like that one |
| 20:52.00 | Juggie | ctooley, if you configure it rigth i dont see how |
| 20:52.29 | Juggie | common sense tells you, you might need seperate logging directories per instance, etc. |
| 20:52.51 | Juggie | but for example, why not share modules, what harm could that do |
| 20:52.58 | ctooley | logging, socket paths, port configurations, etc. |
| 20:53.28 | ctooley | Because sharing the modules simply saves you a few meg of disk space whereas the rest of the setup is the more difficult part. |
| 20:53.44 | Juggie | well in our scenario, there would be no port configs to worry about, if chan_sip is bound to 1.1.1.1 in one install and 2.2.2.2 in another |
| 20:53.50 | ctooley | By just separating everything out, you end up with a cleaner environment. |
| 20:54.04 | seanbright | plus removing an instance is a hell of a lot easier |
| 20:54.18 | seanbright | rm -rf /opt/asterisk-1-foo/ |
| 20:54.25 | ctooley | Management is far easier when they're completely separated |
| 20:55.02 | Qwell | vmware-create asterisk-1 && ... |
| 20:55.03 | Qwell | :D |
| 20:55.23 | Juggie | its possible to do this exact setup without 4 copies of the binaries/module |
| 20:55.44 | ctooley | Juggie, Yeah, we did that at first, |
| 20:55.45 | seanbright | well, to each their own |
| 20:56.21 | ctooley | Requires remembering where everything is "supposed" to be. Burning a little extra disk space saves burning a lot of extra mental cycles in a crisis. |
| 20:56.26 | Juggie | well, you could still use /opt even, could do your configure quite similar, except you would let the binaries go default and then force the config etc into opt. |
| 20:58.01 | Juggie | ./configure --prefix=/opt/asterisk-${i}-$VERSION --sysconfdir=/opt/asterisk-${i}-${VERSION}/etc --localstatedir=/opt/asterisk-${i}-${VERSSION}/var |
| 20:58.13 | seanbright | cd /tmp;cd ..;rm -rf . |
| 20:58.22 | Juggie | woudn't simply removing the --prefix from that give you binaries in default places and then the config and all that in /opt ? |
| 20:59.41 | ctooley | Juggie, yes, but now you have to remember (based on what you're trying to do) which "-C" to pass when you want to start each instance. |
| 20:59.57 | ctooley | Which, in the heat of an outage, _will_ bite someone. |
| 21:00.41 | ctooley | At least it has bitten each member of our Ops team at least once. |
| 21:01.15 | Qwell | write an ncurses menu to select the instance :D |
| 21:01.32 | seanbright | oh snap |
| 21:01.36 | seanbright | newt! |
| 21:01.37 | seanbright | heh |
| 21:01.42 | ctooley | Qwell, trust me, I've done plenty of ncursing at asterisk for various things. :) |
| 21:02.30 | Juggie | ctooley, personal preference i guess, but i dont see how /opt/asterisk-1-1.4.21.1/sbin/asterisk differs from asterisk -C /opt/asterisk-1/asterisk.conf in complexity |
| 21:03.21 | ctooley | Mental separation and tab completion |
| 21:03.25 | Juggie | in each you decide your instance and the rest is fluff |
| 21:03.49 | Juggie | if that confuses you how do you configure cisco switches on the fly? :) |
| 21:04.35 | ctooley | Me? I call up IP Network Services, tell them to get it done, and call back every 5 minutes until they get off their asses and do it. |
| 21:04.41 | ctooley | :) |
| 21:05.21 | ctooley | Juggie, another personal preference issue though, I can't stand Crisco. |
| 21:05.55 | snuff-home | thinks i can live with crisco routers/switches but dont make me sit and config a PIX |
| 21:06.01 | Juggie | heh, i have a 3750-PoE24 as my desk switch |
| 21:06.32 | snuff-home | borrowed from work Juggie ? ;) |
| 21:06.33 | ctooley | prefers Foundry |
| 21:06.50 | Juggie | we are all cisco so far as i know |
| 21:08.00 | ctooley | There was a decision that we were going to move to an all Cisco shop a while back too. Now we're moving back to Juniper and Foundry. |
| 21:08.07 | ctooley | Cisco couldn't keep up. |
| 21:08.55 | Juggie | ok well you win, but i win sometimes :) |
| 21:10.30 | ctooley | hehe, I wasn't going to argue that one, I don't do "networking" stuff for our Network group very much. All I know is 192 Gig-E ports on a switch with a 96 Gigabit backplane causes problems for a telecommunications company. |
| 21:10.55 | kpfleming | ctooley: needs more cowbell, clearly |
| 21:11.05 | Juggie | <3 cowbell |
| 21:11.10 | seanbright | i got a fever.. |
| 21:11.15 | Qwell | kpfleming: Did you see my commit yesterday? :p |
| 21:11.27 | ctooley | kpfleming, probably |
| 21:11.35 | kpfleming | Qwell: yep |
| 21:12.00 | Qwell | or, whenever day that was.. |
| 21:12.11 | Qwell | whatever day.. geez |
| 21:15.30 | MikeJ | Qwell: !! |
| 21:15.34 | Qwell | ? |
| 21:15.38 | MikeJ | hi |
| 21:15.41 | Qwell | hey |
| 21:15.58 | seanbright | if i'm getting an error about inbandrelease in chan_dahdi from the asterisk 1.4 branch, what do i need to upgrade? zaptel? dahdi? |
| 21:16.02 | seanbright | it's all so confusing. |
| 21:16.12 | Qwell | seanbright: whichever is installed |
| 21:16.28 | kpfleming | just upgrade both |
| 21:16.29 | seanbright | Qwell: don't use that tone with me |
| 21:16.30 | seanbright | heh |
| 21:17.34 | seanbright | kpfleming: can you even have them both installed at the same time? |
| 21:17.39 | kpfleming | no |
| 21:17.48 | Qwell | but the latest versions will uninstall the other though, right? |
| 21:17.49 | kpfleming | you need to upgrade libpri and chan_dahdi |
| 21:18.17 | seanbright | i've upgraded to latest releases of libpri and zaptel |
| 21:18.23 | seanbright | i need svn though |
| 21:18.44 | Juggie | did you recompile asterisk after upgrading libpri/zaptel |
| 21:18.52 | kpfleming | that's correct |
| 21:18.58 | xrg_ | seanbright: what distro? |
| 21:19.03 | seanbright | i was in the process of recompiling when i got said error :) |
| 21:19.35 | Juggie | oh, i intrepreted it as a console error not a compile the way you described it |
| 21:21.01 | eliel | Is there a reason why format_png is not implemented? |
| 21:22.01 | pabelanger | bbryant: Thanks again for all your help with issue 0011843. |
| 21:22.21 | bbryant | glad it works |
| 21:22.54 | pabelanger | me too :) |
| 21:28.52 | snuff-home | mm putnopvut M13142 might be worth considering adding to ur imap consistancy branch.. |
| 21:29.09 | putnopvut | M13142 |
| 21:29.11 | MuffinMan | [new] [Asterisk] Applications/app_voicemail/IMAP 0013142: [patch] Save to alternate folder throws errors due to incorrect IMAP mailbox specification in Cyrus IMAP reported by jaroth (Karma: +18.75) http://bugs.digium.com/view.php?id=13142 |
| 21:29.20 | putnopvut | Ah, that. |
| 21:29.57 | putnopvut | I haven't looked too closely at that one just yet. |
| 21:30.24 | snuff-home | me either just seen 'imap' and remembered ur branch ;) |
| 21:31.00 | putnopvut | Thanks for pointing it out. Cyrus seems weird... |
| 21:32.01 | putnopvut | Really, it seems odd to me that we're trying to save to INBOX/<whatever>. It may just be a bug in the code and not need to be configured differently for Cyrus. I need to try with Dovecot. |
| 21:32.03 | snuff-home | never had to use imap.. the idea of using Google imap for voicemail was interesting discussion on dev |
| 21:32.28 | putnopvut | snuff-home: yes, definitely, but that was weird to see how it failed on simple searches for custom headers. |
| 21:32.46 | snuff-home | its google.. they always have 'something' special |
| 21:33.26 | putnopvut | "special" is a nice way of putting it. |
| 21:33.36 | putnopvut | I need to read the Mark Crispin article that was linked to on -dev. |
| 21:37.28 | snuff-home | mm.. bout time i started moving for work.. feel soo lazy getting in at 9 instead of 8-830 |
| 21:37.55 | seanbright | eliel: is PNG used for video streaming? |
| 21:38.23 | eliel | seanbright: it could be useful for sending images |
| 21:38.52 | seanbright | do any devices exist that utilize it? |
| 21:39.08 | seanbright | or are you just looking for something to work on? :) |
| 21:41.17 | eliel | don't know, I am modifying a softphone to receive images, and then I realize that I only could test it with jpeg, and HO! I have something to work on :-) |
| 21:41.40 | seanbright | heh |
| 21:42.25 | seanbright | i guess my thought is that it couldn't hurt to build it, but it might not be incredibly useful |
| 21:42.54 | seanbright | of course i know little about video/image transmission in terms of telephony |
| 21:43.02 | seanbright | so i could be talking out of my ass. |
| 21:45.09 | Qwell | seanbright: did you end up fixing that inbandrelease thing? |
| 21:45.23 | seanbright | Qwell: no sir |
| 21:45.39 | seanbright | didn't bother since it was just on a dev box |
| 21:45.55 | seanbright | and i can wait for the next release of... whichever |
| 21:46.50 | seanbright | or are you saying it is a code problem that needs fixin'? |
| 21:46.54 | Qwell | yeah, that's a big |
| 21:46.56 | Qwell | bug* |
| 21:47.00 | Qwell | think so anyways |
| 21:47.00 | seanbright | ohh |
| 21:47.03 | putnopvut | heh, this talk of image formats got me looking at format_jpeg. No way you can use that with LOW_MEMORY :) |
| 21:47.18 | putnopvut | char buf[65536]; |
| 21:47.22 | seanbright | heh |
| 21:47.23 | seanbright | yikes |
| 21:47.32 | Qwell | putnopvut: bonus points if it's global |
| 21:47.38 | putnopvut | nope, it's local. |
| 21:47.42 | tzanger | it's only 64k, what's wrong, you running on a commodore 64 or something? |
| 21:47.54 | seanbright | apple II |
| 21:47.57 | putnopvut | tzanger: LOW_MEMORY limits stack size to like 48K. |
| 21:48.12 | tzanger | pfft |
| 21:48.41 | kpfleming | putnopvut: only for background threads |
| 21:48.49 | kpfleming | i think regular (channel) threads are 256K |
| 21:49.07 | Qwell | kpfleming: does asterisk r133295 look correct? |
| 21:49.11 | Qwell | if so - seanbright : fixed |
| 21:49.34 | kpfleming | yes |
| 21:49.42 | seanbright | Qwell: nice |
| 21:50.05 | seanbright | who can i blame for breaking it? |
| 21:50.12 | seanbright | :) |
| 21:51.31 | seanbright | Qwell: works. danke. |
| 21:52.58 | seanbright | gah... app_rpt is a mess |
| 21:54.04 | kpfleming | it's me who broke it |
| 21:54.12 | kpfleming | and yes... app_rpt + chan_usbradio are both messes |
| 21:54.50 | seanbright | all appears peachy now |
| 21:55.28 | seanbright | should app_rpt in 1.4 build with zaptel? if so, i'll play around getting it to compile |
| 21:56.04 | kpfleming | it's a mess |
| 21:56.27 | seanbright | right, but it probably should comile :) |
| 21:56.35 | seanbright | s/comile/compile/ |
| 22:02.55 | Qwell | So, I'm wondering why the build bot didn't catch that |
| 22:03.12 | Qwell | I guess libpri changes didn't trigger a new configure in Asterisk, so that wasn't defined |
| 22:03.46 | Qwell | I assume that was a fairly new configure check |
| 22:04.28 | snuff-home | i thought buildbot still hadn't been updated to deal with dahdi |
| 22:04.46 | Qwell | snuff-home: it wasn't a dahdi thing - just libpri |
| 22:06.18 | Qwell | umm, does anybody here speak spanish? |
| 22:06.18 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) [NETSPLIT VICTIM] |
| 22:06.18 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) [NETSPLIT VICTIM] |
| 22:06.18 | *** join/#asterisk-dev jgoddess (n=monkey@phrank.aus.us.siteprotect.com) [NETSPLIT VICTIM] |
| 22:06.18 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) [NETSPLIT VICTIM] |
| 22:06.19 | *** join/#asterisk-dev Corydon76-dig (i=silver@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 22:06.19 | *** mode/#asterisk-dev [+ooo citats file Corydon76-dig] by irc.freenode.net |
| 22:06.19 | Qwell | M13146 |
| 22:06.56 | MuffinMan | [new] [Asterisk] Sounds 0013146: NUEVAS VOCES DE ASTERISK EN ESPAÃOL CON ACENTO NEUTRO!!!!!! reported by asteriskco (Karma: neutral) http://bugs.digium.com/view.php?id=13146 |
| 22:06.57 | tzafrir_laptop | can you read "inbanddisconnect"? any chance for some extra underscores in future names? |
| 22:07.10 | Dovid | lol |
| 22:07.41 | seanbright | i do not speak spanish |
| 22:07.42 | seanbright | but |
| 22:07.54 | seanbright | i would guess "new voices of asterisk in spanish with neutral accents"? |
| 22:08.05 | Qwell | You babelfished. |
| 22:08.09 | seanbright | i did not |
| 22:08.21 | Qwell | I did. That's what it says. |
| 22:08.21 | seanbright | i took spanish 1... 14 years ago |
| 22:08.42 | tzafrir_laptop | it's so close to English. At least those words |
| 22:08.45 | Qwell | The company Colombiana Net Security solutions I release to the K-rem voices⦠complete kit of sounds for asterisk in format gsm, estan very complete! they are but of 1200 voices with a smooth, clear and pleasant voice. If you want but information it visits |
| 22:08.48 | Qwell | SO...he's offering nothing. |
| 22:08.50 | Qwell | Closing. |
| 22:08.59 | seanbright | wait |
| 22:09.14 | seanbright | your comment should be "No, gracias" |
| 22:09.19 | seanbright | heh |
| 22:13.04 | Corydon76-dig | To whomever asked whether libiax is vulnerable to the issues published yesterday, the answer is no. |
| 22:13.26 | Corydon76-dig | It's too old to contain either of those two commands |
| 22:41.02 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 22:41.02 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:52.17 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 23:05.24 | *** join/#asterisk-dev explidous (n=explidou@mail.in-florida.net) |
| 23:21.40 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 23:39.00 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 23:39.00 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 23:41.41 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 23:41.41 | *** mode/#asterisk-dev [+o file] by ChanServ |