| 00:35.23 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 00:35.23 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:35.44 | *** join/#asterisk-dev jtodd (n=jtodd@253.sub-75-254-237.myvzw.com) |
| 01:35.44 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 03:06.31 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:06.31 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:25.23 | *** join/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 03:26.58 | *** join/#asterisk-dev jmworx___ (n=jeval@mail.octasic.com) |
| 04:22.50 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 04:29.06 | *** join/#asterisk-dev jtodd (n=jtodd@253.sub-75-254-237.myvzw.com) |
| 04:29.06 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 04:56.11 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 05:06.47 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 06:01.12 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:02.24 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:02.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:25.40 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 06:39.17 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:39.17 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:41.29 | *** join/#asterisk-dev jeffspeff (n=jeffspef@c-98-240-118-231.hsd1.ky.comcast.net) |
| 09:01.35 | *** join/#asterisk-dev Mw3 (i=mw3@2a01:270:dd00:300:0:0:0:42) |
| 09:09.20 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 09:44.18 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 09:44.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 09:47.42 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:04.58 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 11:10.28 | tzanger | hmm the asterisk website needs to be updated. http://svn.digium.com/svn/libpri/trunk doesn't exist anymore |
| 11:11.16 | kaii | the SVN viewer is down for some time |
| 11:11.41 | tzanger | I don't want the viewer, I want to svn co code :-) |
| 11:51.51 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:51.51 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:52.54 | mvanbaak | mornin eliel |
| 11:53.03 | eliel | good morning! |
| 11:55.13 | wedhorn | mvanbaak: saw your note on skinny subs, so it at least made a call on a 79xx? |
| 11:55.24 | mvanbaak | not yet |
| 11:56.00 | mvanbaak | sh /usr/local/sbin/safe_asterisk && post_note 14997 '<my note on mantis>' |
| 11:56.01 | wedhorn | ok, best of luck, hope you don't upset the missus too much ;) |
| 11:56.26 | mvanbaak | today is not the day to do much testing |
| 11:56.47 | mvanbaak | it's national holiday and the weather is freaking nice so we are going to town to sit on terras and drink beers |
| 11:57.11 | wedhorn | does sound better than testing |
| 11:57.24 | mvanbaak | yup ! |
| 11:57.46 | mvanbaak | ok, 1 testcall to remote vm |
| 11:58.29 | wedhorn | ok, I'll wait till next week and then point it out to pj |
| 11:58.42 | wedhorn | see if it helps him with his crashes |
| 11:59.27 | wedhorn | too slow, he's already found it |
| 11:59.45 | mvanbaak | gheh, lots of funny stuff happening |
| 12:01.20 | mvanbaak | my device is beeping |
| 12:01.46 | mvanbaak | woot, it coredumped |
| 12:01.49 | wedhorn | ah yeah, no more autohangup |
| 12:01.49 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:02.19 | wedhorn | um, ok. That was fairly quick ... |
| 12:02.31 | mvanbaak | yup |
| 12:02.56 | mvanbaak | I did: 1233<dial> |
| 12:03.50 | wedhorn | yeah, I don't have a <dial> button, so not a lot of testing there. |
| 12:03.52 | mvanbaak | speakerphone mode listening to a voicemail message, hit # to hangup, part of a hangup happened but device kept beeping, powercycled phone, phone still beeping, go to CLI and type 'skinny show lines verbose' |
| 12:04.07 | mvanbaak | coredump |
| 12:04.46 | wedhorn | actually, I vaguely remember an issue along those lines, thought I'd fixed it |
| 12:05.35 | mvanbaak | I'll have to look into it later, going to take a shower and go to town |
| 12:05.40 | mvanbaak | latero |
| 12:07.09 | wedhorn | ok, I got a core dump too. Just a question when you get a minute, why the hell did you power cycle and not just put the phone onhook? |
| 12:08.29 | wedhorn | Looks like the issue is that the session cleanup (caused by the power cycle) doesn't seem to kill extra threads that have been created. Shouldn't be too hard to fix. |
| 12:45.15 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.118.128) |
| 13:05.19 | tzafrir_laptop | Is there a good reason the Zaptel / DAHDI makefile passes ARCH=$(ARCH) to the kernel build system? |
| 13:05.43 | tzafrir_laptop | It breaks building on my arm system |
| 13:44.57 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:05.20 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 14:05.31 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 14:06.45 | *** join/#asterisk-dev moy (n=moy@74.12.124.89) |
| 14:38.00 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 14:39.38 | jmls | has ditched vista, after the 3rd crash wiped out the hdd |
| 14:39.54 | jmls | is now a ubuntu-noob as well as a c noob :) |
| 14:48.26 | Corydon76-dig | jmls: yay |
| 14:48.43 | Corydon76-dig | What about Perl? |
| 14:51.40 | JunK-Y | <PROTECTED> |
| 14:51.55 | JunK-Y | and ive declared my hp static |
| 14:52.01 | JunK-Y | oop, its &hp |
| 14:53.07 | JunK-Y | its after calling gethostbyname_r |
| 14:53.08 | Corydon76-dig | Uh, why've you hp static within a function? or static globally within the file? |
| 14:53.17 | Corydon76-dig | Either way, it's wrong. |
| 14:53.41 | Corydon76-dig | Making that variable static means there's one value for the whole process, which means it's NOT thread-safe |
| 14:54.10 | Corydon76-dig | which defeats the whole purpose of the function |
| 14:54.20 | JunK-Y | even with non-static its the same behavior |
| 14:56.08 | Corydon76-dig | Dunno |
| 14:56.20 | JunK-Y | ==28081== Process terminating with default action of signal 11 (SIGSEGV): dumping core |
| 14:56.23 | JunK-Y | ==28081== Bad permissions for mapped region at address 0x93B5BF8 |
| 14:56.25 | JunK-Y | in valgrind |
| 14:56.28 | JunK-Y | ==28081== at 0x33F680E079: __ns_samename (in /lib64/libresolv-2.5.so) |
| 14:56.30 | JunK-Y | ==28081== by 0x93B70CF: ??? |
| 14:56.33 | JunK-Y | ==28081== by 0x68090C00805100FF: ??? |
| 14:57.17 | JunK-Y | this is call few frame after ast_gethostbyname() |
| 14:57.45 | JunK-Y | http://pastebin.ca/1408505 |
| 15:00.20 | Corydon76-dig | JunK-Y: install the debug version of libc |
| 15:00.51 | Corydon76-dig | without those symbols showing up, it's darn near impossible to figure out why. |
| 15:01.17 | Corydon76-dig | Oh, and it'll probably be easier to figure out in gdb, not valgrind, since it's unlikely that you're dealing with memory corruption |
| 15:01.43 | Corydon76-dig | (that is, unless you declared hp static, in which case, it could very well be memory corruption) |
| 15:13.17 | JunK-Y | will have to read more about debugging libc, never did this before. |
| 15:19.33 | Corydon76-dig | JunK-Y: it's probably something silly like something being 32-bit, when it should have been 64-bit |
| 15:19.52 | Corydon76-dig | We may do a workaround to fix it |
| 15:20.07 | JunK-Y | its working fine on 32 bits yeah, but on this 64 bits |
| 15:20.12 | Corydon76-dig | Right |
| 15:20.42 | JunK-Y | i wonder why others ast_gethostbyname() are working fine on 64 bits. |
| 15:21.57 | Corydon76-dig | Just a thought... is that lookup name returning multiple results? |
| 15:22.57 | JunK-Y | no, just one |
| 15:22.57 | JunK-Y | cti.aheeva.inc canonical name = ha-cti-01.aheeva.inc. |
| 15:22.57 | JunK-Y | Name: ha-cti-01.aheeva.inc |
| 15:22.57 | JunK-Y | Address: 10.255.3.130 |
| 15:23.01 | Corydon76-dig | Could grab the source of bind and see if it's doing anything differently |
| 15:23.17 | Corydon76-dig | Ah, it's a CNAME |
| 15:23.33 | JunK-Y | yeah |
| 15:23.49 | Corydon76-dig | Shouldn't make a difference, though it might |
| 15:24.02 | JunK-Y | what could be the work-around? |
| 15:24.21 | Corydon76-dig | If you change it to use the actual DNS name and not the cname, does it crash? |
| 15:24.59 | Corydon76-dig | If it does, then you've narrowed it down to that issue |
| 15:25.22 | Corydon76-dig | Err, if it doesn't, rather |
| 15:26.10 | JunK-Y | yes, the name is still crashing |
| 15:26.24 | Corydon76-dig | Okay, so that's not the issue |
| 15:26.47 | JunK-Y | eee, wait |
| 15:27.14 | Corydon76-dig | Changed the wrong location? ;-) |
| 15:27.46 | JunK-Y | pt_host = ast_gethostbyname( "cti.aheeva.inc", &hp ); i had harcoded it :) |
| 15:28.05 | Corydon76-dig | Ah, heh |
| 15:28.06 | JunK-Y | yeah, still crashing |
| 15:28.58 | JunK-Y | #0 0x00000033f18e13b1 in __res_vinit () from /lib64/libc.so.6 |
| 15:28.59 | JunK-Y | #1 0x00000033f18e4331 in __nss_hostname_digits_dots () from /lib64/libc.so.6 |
| 15:29.02 | JunK-Y | #2 0x00000033f18e93f2 in gethostbyname_r@@GLIBC_2.2.5 () from /lib64/libc.so.6 |
| 15:29.05 | JunK-Y | #3 0x00000000004e3104 in ast_gethostbyname (host=0x2aaaaf05c060 "ha-cti-01.aheeva.inc", hp=0x404e1160) at utils.c:223 |
| 15:29.08 | JunK-Y | #4 0x00002aaaaee53ef2 in connectCtiServerSocket () at app_ahEventsProxy.c:4096 |
| 15:29.11 | JunK-Y | same trace |
| 15:29.23 | file | and hp is defined as ast_hostent? |
| 15:29.50 | JunK-Y | file: yes |
| 15:29.50 | JunK-Y | file: yes struct ast_hostent hp; |
| 15:29.50 | JunK-Y | <PROTECTED> |
| 15:30.45 | Corydon76-dig | JunK-Y: looked like a different trace to me |
| 15:31.15 | Corydon76-dig | but I'd still go with the debug-symbols of glibc, just so you can get more information |
| 15:31.45 | JunK-Y | Corydon76-dig: that ast_getbyhostname is called in a separate thread. |
| 15:32.00 | JunK-Y | the pthread_create happened in the loading module |
| 15:33.19 | Corydon76-dig | JunK-Y: you're telling me things that I'm not sure are relevant to the problem |
| 15:34.34 | JunK-Y | maybe, im giving the much infos i can. |
| 15:36.29 | Corydon76-dig | The debug version of glibc will definitely give us more relevant information |
| 15:36.40 | Corydon76-dig | It should be a standard package |
| 15:36.58 | Corydon76-dig | like glibc-dbg |
| 15:37.10 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 15:37.47 | JunK-Y | not in CentOS 5.3 |
| 15:38.11 | *** join/#asterisk-dev ariel_ (i=3fd6eca9@gateway/web/ajax/mibbit.com/x-cf6b61a777c11e51) |
| 15:41.12 | jsmith | JunK-Y: You should be able to run "debuginfo-install" to insdtall it, if you've got yum-utils installe |
| 15:41.20 | jsmith | breaks his keyboard |
| 15:41.23 | Corydon76-dig | JunK-Y: http://bugs.centos.org/view.php?id=3596 |
| 15:41.26 | jsmith | JunK-Y: You should be able to run "debuginfo-install" to install it, if you've got yum-utils installed |
| 15:41.43 | Corydon76-dig | (filed yesterday) |
| 15:42.05 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:42.28 | jsmith | Ah... that stinks |
| 15:44.04 | tzafrir_laptop | finally got an Astribank running with a SheevaPlug |
| 15:51.44 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:51.44 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:42.26 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 16:42.26 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 16:58.37 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 17:06.51 | Qwell | tzafrir_laptop: neat |
| 17:32.42 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 17:32.42 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk European Developer Meet-Up in Rostock DE May 2&3 http://bit.ly/3AspKM -=- ViewVC for SVN is currently down for the forseeable future -=- Happy Birthday people born on `date +%m-%d`! |
| 17:47.12 | *** join/#asterisk-dev schmooze_tony (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 17:50.13 | *** join/#asterisk-dev securevoip (n=securevo@173.15.197.73) |
| 17:52.51 | *** join/#asterisk-dev jetsnoc (n=brian@root.pmt.org) |
| 17:55.19 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:02.23 | mvanbaak | leifmadsen: twitter != irc ;) |
| 18:23.22 | *** join/#asterisk-dev jtodd (n=jtodd@131.sub-75-218-106.myvzw.com) |
| 18:23.23 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 18:33.34 | Juggie | woot. |
| 18:54.09 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 18:54.09 | *** mode/#asterisk-dev [+o tzafrir_home] by ChanServ |
| 18:56.41 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:56.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:56.48 | russellb | ohai kpfleming |
| 18:56.58 | kpfleming | ohai 2u |
| 19:09.40 | JunK-Y | wie heinSen sie? |
| 19:10.25 | mvanbaak | ich heise mvanbaak, wie heist bist du ? |
| 19:13.00 | kpfleming | stop with the dutch/german |
| 19:15.53 | russellb | only if you stop with the English, first |
| 19:17.03 | dwayne | printf("hello |
| 19:17.10 | dwayne | "); |
| 19:17.37 | russellb | these power outlets by us are a big tease :-( |
| 19:18.38 | tzanger | tease? |
| 19:19.15 | russellb | they don't work. |
| 19:19.38 | file | harsh |
| 19:19.41 | russellb | airport power outlets are a hot commodity, so I have to keep telling someone every 5 to 10 minutes that they don't work |
| 19:21.52 | tzanger | russellb: that sucks |
| 19:31.08 | mvanbaak | wedhorn: asterisk is also dumping core while being totally idle |
| 19:31.29 | mvanbaak | wedhorn: trunk does not do that, but your skinny-sub branch does |
| 19:34.41 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 19:58.11 | *** join/#asterisk-dev Brixius (n=Brixius@PDN-VBA.OnvoyInc.fw.onvoy.net) |
| 20:02.40 | kpfleming | russellb: there is an empty seat over there, eh? |
| 20:03.20 | russellb | kpfleming: yes sir! |
| 20:03.28 | kpfleming | may have to move then |
| 20:03.49 | kpfleming | my battery will last 4.5-5 hours, but don't want to kill it before the flight |
| 20:04.09 | russellb | righty right |
| 20:05.21 | tzafrir_home | when will you be in Rostock? |
| 20:05.28 | kpfleming | 15:30 on friday |
| 20:05.44 | Brixius | I have a question on something I think might be a bug, but wanted to see what others think first. I am using app_addon_sql_mysql to query data for each call that comes in. After a while the connid appears to not increment nor recycle and calls fail. It looks like there is no provision in the app_addon_sql_mysql source code to recycle connections. |
| 20:05.47 | russellb | basically, never |
| 20:06.24 | russellb | Brixius: you should migrate to using func_odbc |
| 20:07.07 | Brixius | I will have to look into that. |
| 20:09.26 | russellb | kpfleming: seat no longer available :-( |
| 20:09.58 | kpfleming | oh well |
| 20:10.19 | dbrooks | russellb: tell those around you that you have swine flu |
| 20:10.27 | dbrooks | that should make some room for kpfleming |
| 20:11.04 | russellb | heh, it might also get in the way of my travel plans :-) |
| 20:11.22 | Corydon76-dig | Brixius: correct, it's not designed in that way |
| 20:12.00 | dbrooks | russellb: a miraculous recovery right before the plane boards :P |
| 20:13.50 | Corydon76-dig | I've heard that a loud and violent sneeze panics people right about now |
| 20:14.28 | Brixius | bummer, I guess I just have to restart more often then until I can switch to func_odbc |
| 20:15.03 | Corydon76-dig | Brixius: have you considered using the 'h' extension to shut down connections and handles when the call is ending? |
| 20:16.01 | tzafrir_home | Tell them you're from Mexico. But later on recall the second part: http://en.wikipedia.org/wiki/Mexico,_Kentucky |
| 20:16.12 | Brixius | will that discard unused mysql connections and allow the reuse of connid #'s |
| 20:16.40 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 20:16.43 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 20:17.29 | Corydon76-dig | Brixius: that assumes one connection per call and shuts down the connection when the call ends |
| 20:18.52 | snuff-home | russellb: with that fix for ast_channel_unref.. you kept it a macro (yes i still have to get back to tell u if it was happy after that) |
| 20:19.24 | snuff-home | then if that works.. why is the tzone a static function.. |
| 20:20.47 | snuff-home | bbl.. |
| 20:22.19 | russellb | snuff-home: dunno |
| 20:22.37 | russellb | kpfleming: seat available once again |
| 20:22.41 | kpfleming | ok |
| 20:26.29 | *** join/#asterisk-dev flujan (n=flujan@189.111.254.251) |
| 20:30.03 | kpfleming | seat has been taken... by me! |
| 20:31.08 | russellb | yay |
| 20:35.48 | Brixius | Thanks for the info, I will look into func_odbc, I appreciate the help. |
| 20:35.56 | *** part/#asterisk-dev Brixius (n=Brixius@PDN-VBA.OnvoyInc.fw.onvoy.net) |
| 20:47.46 | *** join/#asterisk-dev telecos (n=sergio@42.166.219.87.dynamic.jazztel.es) |
| 20:50.14 | Juggie | anyone know if its possible to have d-channel congestion if you have alot of short calls (so alot of call setup and tear downs) |
| 20:50.28 | kpfleming | yes |
| 20:50.31 | kpfleming | it's called glage |
| 20:50.34 | kpfleming | oops... glare |
| 20:50.48 | Juggie | any suggestion on a good way to diagnose it? |
| 20:51.05 | Corydon76-dig | Juggie: what do you mean by D-channel congestion? |
| 20:51.08 | Juggie | i think we may be seeing it on a nfas setup (4t1's 1d + backupd. |
| 20:51.34 | Juggie | Corydon76-dig, too many call messages which would be saturating it. i was asking if it is possible. |
| 20:51.38 | Corydon76-dig | More data to flow than you have bandwidth? |
| 20:52.03 | Juggie | yes, if you have 94 channels on one d-channel doing a significant amount of setup/tear downs |
| 20:52.10 | Juggie | was currious if it was a possible scenario. |
| 20:52.25 | Corydon76-dig | On a T3 with a single D channel (671 channels), if all channels came up at the same time, it would take 1 second of time to transmit all those call setups on the D-channel |
| 20:52.27 | tzanger | Juggie: yes, it is a real scenario |
| 20:52.36 | tzanger | I spent the better part of a decade doing dialup interweb |
| 20:52.52 | tzanger | NFAS let you aggregate tons of calls to a single dchan, thus giving you more bearer channels for calls |
| 20:53.11 | tzanger | but during particuarly nasty times you could exceed the bandwidth of your D channel and get slowdowns for call acceptance, etc |
| 20:53.14 | Corydon76-dig | tzanger: yeah, but glare is something different altogether |
| 20:53.37 | tzanger | this was dialup, so all one-way generated calls (all incoming) |
| 20:54.04 | Juggie | asterisk is doing great for us today at CRA (we are running a 100calls all the time for the last 8 hours) doing network overflow. But we are just seeing some busy_nets (rather then busy_cpe) so were just diagnosing trying to figure out if its possible the dchannel is overloaded or if we are dealing with some sort of carrier limitation |
| 20:54.17 | Juggie | (today is the last day to file taxes in canada, so busy day for us) |
| 20:54.21 | tzanger | CRA? Canada Revenue Agency?? |
| 20:54.24 | Juggie | yep. |
| 20:54.31 | tzanger | you're kidding |
| 20:54.33 | tzanger | that's awesome |
| 20:54.49 | Juggie | atm were using it for network overflow from 1-800 network for a specific number. |
| 20:54.51 | tzanger | my tax dollars at (real) work |
| 20:55.06 | Juggie | so the traffic is split up across eg 5 sites by % |
| 20:55.12 | Juggie | and if the site is busy its overflowing to our DS3 |
| 20:55.31 | Juggie | tzanger, where in canada are you |
| 20:55.34 | tzanger | ontario |
| 20:55.38 | Juggie | city? |
| 20:55.44 | tzanger | an hr west of toronto (waterloo) |
| 20:55.48 | Juggie | ah nice. |
| 20:55.57 | Juggie | if we have an opening i'll let you know |
| 20:56.03 | Corydon76-dig | Juggie: I suspect it's more likely that your provider is jammed up with calls than you saturating the bandwidth of a D-channel |
| 20:56.04 | Juggie | the feds can pay people to work w/ * :) |
| 20:56.08 | tzanger | heh awesome. |
| 20:56.22 | Juggie | Corydon76-dig, thats possible too i was just wondering if d-channel congestion was possible |
| 20:56.30 | Juggie | the scenario is we haev alot of very short calls |
| 20:56.32 | tzanger | Juggie: what kind of equipment are you terminating that DS3 to |
| 20:56.41 | Juggie | because people over flow to a message tellnig them we are busy |
| 20:56.49 | Juggie | and they ar ejust hanging up and calling back to try and get a real person |
| 20:56.55 | Juggie | tzafrir, adtran |
| 20:57.02 | tzanger | when I did dialup we first terminated t1s directly but then when we got our first DS3 it went to an M13, but later we ended upwith something like 16 or 17 DS3s terminating to MaxTNTs |
| 20:57.06 | Juggie | one ds3->adtran->7 * servers. |
| 20:57.14 | tzanger | ok so you're running the M13 as well then |
| 20:57.21 | Juggie | no idea |
| 20:57.22 | tzanger | (DS3 mux) |
| 20:57.24 | Juggie | i dont work on the * side anymore |
| 20:57.25 | Juggie | ya |
| 20:57.27 | Corydon76-dig | Juggie: nice setup |
| 20:57.33 | Juggie | i'm in network ops now |
| 20:57.49 | tzanger | gotcha |
| 20:57.49 | Juggie | Corydon76-dig, glad you like it, we have 2 of them :) |
| 20:58.12 | Juggie | we've actually in the past crashed dms-100 switches belonging to bell |
| 20:58.16 | Juggie | because of sheer volume |
| 20:58.21 | Juggie | so much so we took down 911 once. |
| 20:58.55 | Juggie | so now our call centers never send busy |
| 20:58.55 | Juggie | we have dedicated out busy numbers |
| 20:58.55 | Juggie | and we overflow to those. |
| 20:59.00 | Juggie | *busy out |
| 20:59.28 | tzanger | wow that is a lot of call volume |
| 20:59.36 | tzanger | what kind of setups/sec are you seeing? |
| 20:59.37 | Juggie | ya its crazy |
| 20:59.47 | Juggie | not sure, were not handeling our entire call load on * |
| 20:59.55 | Juggie | atm this is our first tax season w/ asterisk running prod |
| 21:00.05 | tzanger | right, but what's the overflow doing |
| 21:00.23 | Juggie | not sure on call setups but its running at 90-105ish calls consitantally. |
| 21:00.40 | tzanger | this is where res_snmp comes in handy |
| 21:00.44 | Juggie | ya for sure. |
| 21:00.47 | tzanger | throw all that shit into an RRD and get pretty graphs |
| 21:00.57 | Juggie | there is some monitoring, but not enough. |
| 21:01.12 | Juggie | i think cacti is running somewhere. |
| 21:01.20 | tzanger | actually the M13 would have SNMP reporting |
| 21:01.48 | tzanger | although I am not sure if the M13 can break out the Dchan traffic to tell you what's happenning |
| 21:02.05 | Juggie | ya, i'll leave it be |
| 21:02.12 | Juggie | i dont want to c hance messing anything up :) |
| 21:02.14 | tzanger | is digging deeeper into libpri; got a contract coming up (hopefully) that means I'll be adding a LOT of shit to it |
| 21:02.22 | tzanger | mostly for aeronautics, ARINC 7-something-something |
| 21:02.31 | tzanger | ARINC 746 |
| 21:02.38 | Juggie | i sent someone to go call our provider |
| 21:02.44 | Juggie | to see if they are seeing any congestion on there end. |
| 21:04.00 | Juggie | were seeing a weird problem w/ the 1-800 network not being able to redirect the call quicly enough |
| 21:04.07 | Juggie | that goes away if we disable overflowing. |
| 21:04.38 | tzanger | if you disable overflow though is it not going to busy? |
| 21:04.44 | tzanger | Juggie: how many D channels are you running? |
| 21:05.04 | tzanger | DS3 -> 7xDS2... is that 1 dchan, 7, 14, 28? |
| 21:05.14 | Juggie | tzanger, each * box has 4 pris in nfas w/ 1dchan and 1backup |
| 21:05.22 | tzanger | okay so 7 dchans + 7 backup |
| 21:05.28 | Juggie | right |
| 21:05.28 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 21:05.38 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 21:05.46 | tzanger | I'd be really surprised if you're running into bandwidth issues on the dchan |
| 21:05.54 | Juggie | but i think someone made the dumb mistake of having the provider set the hunt to first avail channel |
| 21:05.58 | Juggie | rather then round robin |
| 21:06.13 | tzanger | ah |
| 21:06.17 | Juggie | but i have not been able to confirm as someone is on vacation (perfect time to go) |
| 21:06.24 | tzanger | yeah no need for that :-) |
| 21:06.41 | tzanger | you should be able to tell by looking at the channels that pick up, but it'd be tricky on a busy system |
| 21:06.56 | Juggie | so if we are running 90 calls and the load is being sent to first avail channel were going to end up w/ all the calls going to mostly one box |
| 21:07.01 | Juggie | which would not be the prefered setup |
| 21:07.09 | tzanger | for sure |
| 21:07.11 | Juggie | i'll have to follow up on that later. |
| 21:07.32 | Juggie | because now one d chan is doing way way more setups and tear downs then it should be. |
| 21:07.56 | Juggie | think in that situation, if you had say even just 4 t1 in nfas (forget the 6 other boxes) and your running calls 30sec or less |
| 21:08.03 | Juggie | there is a possible problem there? |
| 21:08.17 | Juggie | or should i be looking more up the network |
| 21:08.29 | tzanger | you really need to look at the Erlang calculations for your particular situation |
| 21:08.44 | Corydon76-dig | I think as long as the calls are at least 3 seconds long, you should have no problem |
| 21:08.50 | Juggie | Corydon76-dig, ok. |
| 21:09.11 | tzanger | I'm thinking that too, actually |
| 21:09.35 | Juggie | ya |
| 21:09.42 | Juggie | just looked @ the stats |
| 21:09.49 | Juggie | avg duration is 50sec |
| 21:09.53 | Juggie | so it should not be that then |
| 21:09.57 | Juggie | ok i'll blame the provider |
| 21:10.08 | Juggie | thanks. |
| 21:10.22 | Corydon76-dig | I'm sure the provider is crossing their fingers already |
| 21:10.27 | Juggie | hehe |
| 21:10.32 | Juggie | when we first got the ds3 |
| 21:10.35 | Juggie | (its not bell canada) |
| 21:10.37 | Corydon76-dig | Hoping they don't go down druing this onslaught |
| 21:10.39 | Juggie | we tried to fill all the channels |
| 21:10.43 | Juggie | and we got to about 1/3 |
| 21:10.46 | Juggie | and coudnt get any more |
| 21:10.54 | Juggie | they had to go increase their peering agreement w/ bell. |
| 21:10.55 | tzanger | Juggie: they can generally change the channel assignment on the fly as well |
| 21:11.16 | Juggie | tzanger, k though thats prob not the issue in this case since avg call duration is 50sec |
| 21:11.17 | tzanger | it has ntohing to do with your end at all |
| 21:11.30 | Corydon76-dig | Juggie: they're probably again at their local limit |
| 21:11.31 | Juggie | it would have to be <3 to see a prob as you said |
| 21:11.46 | Juggie | Corydon76-dig, thats what i was suspecting but i just wanted to ask as it was brought up as a possibility. |
| 21:11.49 | tzanger | heh |
| 21:11.57 | tzanger | I was reading that "it would have to be heart to see a prob as you said" |
| 21:12.02 | Corydon76-dig | Juggie: try calling their local office on your cell and see if you get a busy |
| 21:12.22 | Juggie | :) |
| 21:12.24 | tzanger | it'd be kind of cool to get HDLC output data rates from the framer |
| 21:12.39 | Juggie | tzanger, write the patch, dchannel data rates :) |
| 21:12.51 | tzanger | Juggie: :-) |
| 21:12.56 | tzanger | I've a half a mind to |
| 21:13.58 | tzanger | your'e running hardhdlc? |
| 21:14.43 | Juggie | tzanger, i'd have to check again, i got out of the * stuff here at work so i'm not sure what the guys are running now |
| 21:14.52 | Juggie | we have a mix of zaptel cards and sangoma stuff. |
| 21:14.59 | tzanger | both support hardhdlc |
| 21:15.37 | Juggie | my calc puts us at a call setup every 0.4seconds |
| 21:15.56 | Juggie | dividing our calls over the day / 8hours / 60min / 60 sec |
| 21:18.07 | Juggie | tzanger, you figure that should be no problem? |
| 21:19.03 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 21:19.03 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 21:20.31 | tzanger | that is maybe a little close from my "touchy feely" gut feeling |
| 21:20.50 | tzanger | it doesn't take anywhere near 400ms to set up a call, but also you're doing a "flat" distribution and it doesn't work quite like that |
| 21:20.57 | tzanger | so I bet you're getting batches of calls |
| 21:32.00 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:36.36 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 21:45.52 | wedhorn | mvanbaak: skinny-subs - fixed 'skinny show lines verbose' and started fixing the power cycle issue (committed to wedhorn) |
| 22:03.31 | *** join/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 22:24.41 | Juggie | tzanger, we talked to the provider and they dont see any prob on our end, also when we call the did direct (bypassing 1-800) we get a answer automatically |
| 22:24.58 | Juggie | so we are assuming its the provider at this point, they raised the ticket and were waiting to hear back |
| 22:25.12 | Juggie | though i do agree, roundrobin t1 would be 100x better. |
| 22:25.55 | Juggie | looking at the recent stats (for a smaller picture) we've done 440calls in the last 15min |
| 22:26.48 | Juggie | looking @ the cpm's we are seeing 1-2 call setups per second |
| 22:26.49 | Juggie | no more. |
| 22:27.24 | Juggie | and from time to time we are skipping 1-2 seconds before the next c all |
| 22:27.35 | Juggie | so it should not be getting bunches so far as i can see |
| 23:10.16 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 23:10.21 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-39-242.dyn.grandenetworks.net) |
| 23:26.41 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.126) |
| 23:54.57 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 23:54.57 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 23:54.59 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) [NETSPLIT VICTIM] |
| 23:54.59 | *** join/#asterisk-dev ltd (n=z@pat.transact.net.au) [NETSPLIT VICTIM] |
| 23:54.59 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |