| 00:02.59 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 00:12.49 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 00:24.04 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) |
| 00:42.04 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 00:44.56 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 01:04.41 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 01:49.57 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 01:49.57 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:07.19 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 02:07.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 03:22.32 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 04:10.52 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 04:46.27 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.86) |
| 04:56.47 | philipp64 | russellb: one other reason I need zaptel... wanpipe compiles against it. |
| 05:30.58 | *** join/#asterisk-dev Chris-NB (n=chris@85-126-61-10.work.xdsl-line.inode.at) |
| 05:49.45 | *** join/#asterisk-dev mythicalbox (n=mythical@98.67.167.10) |
| 05:50.03 | *** part/#asterisk-dev mythicalbox (n=mythical@98.67.167.10) |
| 06:47.30 | philipp64 | tzafrir_laptop: you around? |
| 06:56.50 | *** join/#asterisk-dev DarkRift (n=dark@65.92.165.116) |
| 06:59.03 | *** join/#asterisk-dev lmsteffan (n=laurent@202.22.147.157) |
| 07:04.35 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 07:12.49 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:29.28 | mvanbaak | hhmm, include/asterisk/rtp.h is no more ? |
| 07:30.20 | snuff-work | nope |
| 07:30.32 | snuff-work | died when rtp_engine came |
| 07:30.58 | snuff-work | there is a res/res_rtp_asterisk.c |
| 07:31.06 | snuff-work | i think that's the name.. |
| 07:31.22 | mvanbaak | yeah |
| 07:31.39 | mvanbaak | addons/chan_ooh323.h still includes asterisk/rtp.h |
| 07:31.55 | snuff-work | yes... but now there is a new ooh323 in channels.. |
| 07:32.02 | snuff-work | correct me if i'm wrong.. |
| 07:32.38 | mvanbaak | nope |
| 07:32.54 | snuff-work | aka i know the addons one doesn't work.. but i think a putback recently added chan_ooh323.c into normal channels/ |
| 07:33.26 | mvanbaak | URL: http://svn.digium.com/svn/asterisk/trunk |
| 07:33.32 | mvanbaak | Revision: 205531 |
| 07:33.43 | mvanbaak | there's no chan_ooh323.c in channels/ |
| 07:33.47 | mvanbaak | only in addons/ |
| 07:33.55 | snuff-work | mmm.. |
| 07:34.12 | snuff-work | double checks his bad memory |
| 07:34.15 | mvanbaak | I think you are referring to the devbranch oh323_work |
| 07:35.39 | snuff-work | ah yes.. |
| 07:35.57 | snuff-work | when that gets merged it should then work i guess ;) |
| 07:36.06 | mvanbaak | lol |
| 07:36.27 | snuff-work | otherwise for a 'bad hack' i guess u could always just 'include res/res_rtp_asterisk.c' |
| 07:36.39 | mvanbaak | keeping the obsd port updated is giving me some headaches the last couple of weeks |
| 07:36.42 | mvanbaak | lol |
| 07:38.10 | snuff-work | well i hated the daily automerge breaks in the past 2 weeks.. :) |
| 07:38.30 | snuff-work | i fixed it one night.. within 24 hrs was broken again :( |
| 07:39.48 | mvanbaak | yeah |
| 07:39.55 | mvanbaak | cel isn't compiling neither |
| 07:40.04 | mvanbaak | cel.c:92: warning: duplicate `const' |
| 07:40.05 | mvanbaak | cel.c:124: warning: duplicate `const' |
| 07:40.18 | snuff-work | mm cel isn't? haven't compiled lately i guess |
| 07:40.26 | mvanbaak | static const char const *cel_event_types[CEL_MAX_EVENT_IDS] = { |
| 07:40.31 | snuff-work | heh |
| 07:40.42 | mvanbaak | wtf ??? |
| 07:40.43 | snuff-work | someone went a 'const' too far |
| 07:41.13 | mvanbaak | ok, I have never seen that |
| 07:41.24 | mvanbaak | static const <type> const <name> ???? |
| 07:41.32 | mvanbaak | what's that second const for ? |
| 07:45.25 | snuff-work | mm i just put into google got some results.. |
| 07:46.00 | snuff-work | i think... |
| 07:46.10 | snuff-work | static const char* const cel_event_types[CEL_MAX_EVENT_IDS] |
| 07:46.19 | snuff-work | that 'may' fix it |
| 07:48.14 | mvanbaak | snuff-work: yup ! |
| 07:50.22 | mvanbaak | why the second const to begin with ? |
| 07:50.39 | mvanbaak | gcc will know *cel_event_types is const anyway |
| 07:54.21 | snuff-work | i have no idea.. |
| 07:54.52 | snuff-work | making doubly sure? |
| 07:56.15 | snuff-work | ask russ or kp when they are in.. maybe they can enlighten us on the finer points of static const char* const blah |
| 07:57.32 | mvanbaak | I will |
| 07:59.59 | mvanbaak | beams russell into an .eu timezone |
| 08:10.01 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:10.01 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:20.02 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) |
| 08:25.18 | mvanbaak | oh joy |
| 08:25.24 | mvanbaak | it's a mess at the moment |
| 08:25.36 | mvanbaak | ssl.c: In function `ssl_threadid': |
| 08:25.36 | mvanbaak | ssl.c:48: warning: return makes integer from pointer without a cast |
| 08:28.38 | mvanbaak | fixed |
| 08:59.14 | *** join/#asterisk-dev micols (n=mio@81.161.188.225) |
| 09:06.25 | *** join/#asterisk-dev degrade (n=degrade@unaffiliated/degrade) |
| 10:06.02 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 10:14.59 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) [NETSPLIT VICTIM] |
| 10:14.59 | *** join/#asterisk-dev micols (n=mio@81.161.188.225) [NETSPLIT VICTIM] |
| 10:15.00 | *** join/#asterisk-dev Mw3 (i=mw3@mw3.hu) [NETSPLIT VICTIM] |
| 10:15.00 | *** join/#asterisk-dev jmspeex (n=jmspeex@modemcable112.109-81-70.mc.videotron.ca) [NETSPLIT VICTIM] |
| 10:15.00 | *** join/#asterisk-dev jmworx (n=jeval@mail.octasic.com) [NETSPLIT VICTIM] |
| 10:15.00 | *** join/#asterisk-dev xpot (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 10:15.00 | *** mode/#asterisk-dev [+o Deeewayne] by irc.freenode.net |
| 10:15.33 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev degrade (n=degrade@unaffiliated/degrade) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev DarkRift (n=dark@65.92.165.116) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.86) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev sumasuma (n=root@64.92.218.196) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev Jacke (i=jacke@valhalla.bofh.org) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-238-9.dhcp.embarqhsd.net) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-27fe6636ae7c3469) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev rue_mohr (n=rue@h24-207-90-17.cst.dccnet.com) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev Praise (n=Fat@unaffiliated/praise) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev dwayne (n=dwayne@76.29.245.9) [NETSPLIT VICTIM] |
| 10:15.33 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) [NETSPLIT VICTIM] |
| 10:15.33 | *** mode/#asterisk-dev [+oooo tzafrir_laptop codefreeze-lap malcolmd mvanbaak] by irc.freenode.net |
| 10:15.33 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) [NETSPLIT VICTIM] |
| 10:15.34 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-7f5e8449999e8403) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev jsmith-away (n=njsmith@asterisk/training-and-documentation-guru/jsmith) |
| 10:15.35 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev destructure (n=mu@couchdb/user/destructure) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 10:15.35 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 10:15.35 | *** mode/#asterisk-dev [+oooo snuff-work jsmith-away russellb file] by irc.freenode.net |
| 10:16.05 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 10:16.05 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev lmsteffan (n=laurent@202.22.147.157) |
| 10:16.05 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 10:16.05 | *** join/#asterisk-dev jetsnoc (i=brian@207-150-160-180.static.sagonet.net) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-4c5c4e7262976659) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) [NETSPLIT VICTIM] |
| 10:16.05 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 10:16.05 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 10:16.05 | *** mode/#asterisk-dev [+ooo The_Boy_Wonder Qwell ChanServ] by irc.freenode.net |
| 10:16.33 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 10:29.52 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 10:29.52 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev _ys (n=ys@91.151.196.67) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev lmsteffan (n=laurent@202.22.147.157) |
| 10:29.52 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 10:29.52 | *** join/#asterisk-dev jetsnoc (i=brian@207-150-160-180.static.sagonet.net) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-4c5c4e7262976659) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) [NETSPLIT VICTIM] |
| 10:29.52 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 10:29.53 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 10:29.53 | *** mode/#asterisk-dev [+ooo The_Boy_Wonder Qwell ChanServ] by irc.freenode.net |
| 10:36.48 | *** join/#asterisk-dev viraptor (n=viraptor@80.175.164.6) |
| 10:38.09 | viraptor | hi, could someone tell me what's the asterisk sip/rtp threading model in 1.4? i.e. can a slow io write from monitoring cause a delay in sip, or rtp processing on the same, or a different channel? |
| 11:03.09 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 11:09.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:17.05 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:28.11 | *** join/#asterisk-dev viraptor (n=viraptor@80.175.164.6) |
| 12:32.31 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:12.35 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 13:12.35 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:18.23 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:25.01 | *** join/#asterisk-dev Dovid (n=annon@tony09-118-62.inter.net.il) |
| 13:45.06 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733615.dsl.bell.ca) |
| 13:45.14 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 13:59.57 | russellb | M15474 |
| 13:59.59 | MuffinMan | [assigned] [Asterisk] CDR/NewFeature 0015474: Race condition in cdr_syslog.c (SVN Revision 205561) reported by praise (Karma: neutral) https://issues.asterisk.org/view.php?id=15474 |
| 14:00.09 | russellb | seanbright: i assigned that to you to take a look at when you have time |
| 14:03.51 | mvanbaak | russell !!!!!!!!!!!!! |
| 14:04.08 | russellb | ohai mvanbaak |
| 14:04.14 | mvanbaak | I need your brain |
| 14:04.15 | russellb | thanks for fixing ssl.c :-) |
| 14:04.23 | russellb | i'm sorry, but my brain is attached |
| 14:04.23 | mvanbaak | no problem :) |
| 14:04.38 | mvanbaak | ok, then share some knowledge out of it please |
| 14:04.52 | mvanbaak | 09:40 <@ mvanbaak> static const char const *cel_event_types[CEL_MAX_EVENT_IDS] = { |
| 14:04.59 | mvanbaak | 09:41 <@ mvanbaak> what's that second const for ? |
| 14:05.20 | russellb | it's actually redundant |
| 14:05.24 | russellb | it's in the wrong place |
| 14:05.26 | mvanbaak | yeah |
| 14:05.32 | russellb | the 2nd one is supposed to be after the '*' |
| 14:05.36 | mvanbaak | and it makes main/cel.c noncompiling |
| 14:05.47 | russellb | move it after the * and try |
| 14:05.54 | russellb | and if so, that's probably my typo |
| 14:05.55 | russellb | sorry |
| 14:06.07 | mvanbaak | this works: static const char* const cell_event_types |
| 14:06.22 | russellb | yep, commit (except add a space before the *) |
| 14:06.32 | mvanbaak | \o/ |
| 14:06.40 | mvanbaak | thank you snuff-work for the tip |
| 14:07.05 | mvanbaak | and you probably already know, but addons/chan_ooh323 is not compiling |
| 14:07.12 | russellb | yep, it's very broken |
| 14:07.22 | mvanbaak | addons/chan_ooh323.h still has #include <asterisk/rtp.h> |
| 14:07.33 | russellb | right, it hasn't been converted to the rtp_engine |
| 14:07.39 | mvanbaak | indeed |
| 14:07.45 | russellb | it should mostly be an easy conversion ... |
| 14:07.48 | russellb | just nobody has done it :-) |
| 14:08.00 | mvanbaak | and I dont feel like doing it. specially now there's a oh323_work devbranch |
| 14:08.02 | russellb | we'll have to take care of it before 1.6.3 sometime |
| 14:08.13 | russellb | don't know if that'll make it in before 1.6.3, though |
| 14:08.26 | mvanbaak | then we'll have to fix it :) |
| 14:09.42 | russellb | yep |
| 14:10.16 | russellb | hopefully he'll get his chan_ooh323 code on reviewboard, and i'll work with him on getting it in shape for trunk |
| 14:12.31 | mvanbaak | yay, we have a working asterisk-trunk compiled with --enable-dev-mode on OpenBSD again \o/ |
| 14:16.07 | seanbright | russellb: yeah, saw that this morning. not sure what the right way to address it is yet. |
| 14:16.39 | russellb | i haven't looked at it closely .. just saw cdr_syslog mostly :-) |
| 14:17.13 | seanbright | primary issue: openlog/syslog/closelog are per-process and not per-thread. |
| 14:17.22 | seanbright | so... blech |
| 14:17.30 | russellb | global syslog mutex? |
| 14:17.31 | russellb | heh |
| 14:17.53 | seanbright | well, i know that logger.c calls openlog once and closelog once. |
| 14:17.56 | russellb | or create a wrapper for those 3 API calls that serializes usage |
| 14:17.59 | seanbright | so that might be problematic. |
| 14:18.07 | seanbright | i'll figure it out. |
| 14:18.12 | russellb | k!!!!!!! |
| 14:18.14 | seanbright | just might take 6 or 7 months |
| 14:18.17 | seanbright | heh |
| 14:19.14 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:19.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:19.48 | seanbright | well yeah... but he totally broke chan_sip. even though it was temporary i would still fire his ass. |
| 14:19.54 | seanbright | ohai putnopvut! |
| 14:20.04 | putnopvut | lol |
| 14:20.14 | putnopvut | seanbright: talking to yourself again? |
| 14:20.21 | seanbright | putnopvut: mayhaps. |
| 14:20.25 | russellb | that's why I use an IRC proxy, I'm always watching! |
| 14:20.37 | putnopvut | russellb: stalker |
| 14:20.42 | russellb | yeah. |
| 14:20.45 | russellb | wanders off |
| 14:21.53 | tzafrir_laptop | <PROTECTED> |
| 14:22.05 | seanbright | he knows i was just messing with him |
| 14:28.12 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:28.12 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:28.39 | viraptor | could someone tell me about the threading model in asterisk? i.e. can a monitor write cause chan_sip to delay processing a sip or rtp packet? |
| 14:28.49 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:28.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:29.26 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:29.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:31.52 | kpfleming | viraptor: that's not really under the control of asterisk |
| 14:35.08 | viraptor | kpfleming: I'm not sure I understand your answer... :) let me rephrase it to 2 questions: 1. does asterisk use a pool of threads for handling traffic, or is there a fixed connection<->thread mapping |
| 14:35.40 | kpfleming | it's fixed |
| 14:35.47 | viraptor | kpfleming: 2. does Monitor run a write() in the same thread that received rtp, or is there a specific buffer for it? |
| 14:36.08 | kpfleming | monitor does not use separate threads, but mixmonitor does (sort of) |
| 14:36.13 | russellb | it's an fwrite(), so it's buffered in that sense |
| 14:36.56 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 14:36.56 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 14:37.38 | viraptor | hmm... I'm having a strange issue where asterisk just stops passing traffic for ~5 seconds and then everything goes back to normal - I'm just looking for some probable causes :/ there are no cpu usage spikes, no call floods... everything seems normal |
| 14:57.11 | *** join/#asterisk-dev thansen (n=thansen@76.27.110.194) |
| 14:59.02 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:59.02 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:03.41 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 15:04.05 | *** join/#asterisk-dev ms110 (n=Shehzad@122.170.114.229) |
| 15:04.19 | *** part/#asterisk-dev ms110 (n=Shehzad@122.170.114.229) |
| 15:33.33 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 15:40.28 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:43.02 | *** join/#asterisk-dev errotan (n=errotan@5403E62B.catv.pool.telekom.hu) |
| 15:49.40 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 15:50.16 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 15:50.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 16:08.09 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 16:28.59 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 16:28.59 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 16:29.10 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) |
| 16:29.10 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:45.25 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 17:29.39 | philipp64 | russellb: https://issues.asterisk.org/view.php?id=15477 |
| 17:30.03 | philipp64 | tzafrir_laptop: you around? |
| 17:30.36 | tzafrir_laptop | philipp64, yes |
| 17:30.57 | philipp64 | had a question for you about dahdi-tools related to the above... do you own that, or russell? |
| 17:34.14 | tzafrir_laptop | philipp64, xpp/Makefile includes makeopts |
| 17:35.04 | philipp64 | Ok... so I'm unclear why it's not picking up CFLAGS... |
| 17:36.00 | tzafrir_laptop | but it uses -lusb rather than USB_LIB |
| 17:36.26 | tzafrir_laptop | what do you have in USB_LIB= in makeopts when you run that cross-build? |
| 17:36.54 | philipp64 | ah... it seems it clobbers CFLAGS by setting it directly. Oops. |
| 17:38.39 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 17:38.40 | philipp64 | PBX_USB=1 |
| 17:38.41 | philipp64 | USB_LIB=-L/home/philipp/kernel/build_i586/staging_dir/usr/lib -lusb |
| 17:38.43 | philipp64 | USB_INCLUDE=-I/home/philipp/kernel/build_i586/staging_dir/usr/include |
| 17:39.43 | philipp64 | and all of our handy code-generation directives got dropped... |
| 17:39.45 | philipp64 | CFLAGS=-Os -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels |
| 17:40.19 | philipp64 | CFLAGS = -g -Wall $(EXTRA_CFLAGS) |
| 17:40.21 | philipp64 | should be: |
| 17:40.26 | philipp64 | CFLAGS ?= -g -Wall $(EXTRA_CFLAGS) |
| 17:40.28 | philipp64 | or else: |
| 17:40.31 | tzafrir_laptop | could you please try the patch I uploaded? |
| 17:40.36 | philipp64 | CFLAGS = -g -Wall $(CFLAGS) |
| 17:40.47 | tzafrir_laptop | s/-lusb/$(USB_LIB)/ |
| 17:46.13 | *** join/#asterisk-dev xpot-mobile (n=james@144.35.25.21) |
| 17:46.13 | philipp64 | http://www.pastebin.ca/1489879 |
| 17:48.38 | philipp64 | bugger... wait 2. |
| 17:50.18 | philipp64 | the problem isn't the link... it's the compile. your patch doesn't address passing the right -I include flags... |
| 17:50.20 | tzafrir_laptop | ok. need to update CFLAGS as well, right |
| 17:50.24 | tzafrir_laptop | patch updated |
| 17:52.21 | philipp64 | you're still dropping the code-generation directives from the parent... |
| 17:52.50 | philipp64 | if someone is building their kernel with -fomit-frame-pointer then that needs to be honored... |
| 17:53.32 | tzafrir_laptop | which specific variable? |
| 17:59.06 | philipp64 | CFLAGS... from makeopts. |
| 17:59.13 | philipp64 | -CFLAGS = -g -Wall $(EXTRA_CFLAGS) |
| 17:59.14 | philipp64 | +EXTRA_CFLAGS := $(CFLAGS) |
| 17:59.16 | philipp64 | +CFLAGS = -g -Wall $(USB_INCLUDE) $(EXTRA_CFLAGS) |
| 18:00.10 | philipp64 | though I'm not even sure we need to modify $CFLAGS at all. It might be enough just to not override it... |
| 18:01.32 | philipp64 | nope. we do need to add in $(USB_INCLUDE)... |
| 18:01.46 | philipp64 | so my patch as above works fine. |
| 18:04.39 | philipp64 | amended: https://issues.asterisk.org/file_download.php?file_id=23214&type=bug |
| 18:12.02 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 18:12.23 | philipp64 | sort of related bug: https://issues.asterisk.org/view.php?id=15478 |
| 18:13.44 | philipp64 | is this for sruffell or tzafrir? |
| 18:16.59 | sruffell | hmm...that would be for me. |
| 18:17.16 | sruffell | that module can't be cross compiled, but the build shouldn't just fail... |
| 18:23.44 | tzafrir_laptop | philipp64, I wonder what's that EXTRA_CFLAGS is for |
| 18:24.16 | philipp64 | how do you mean? |
| 18:24.24 | philipp64 | In my revised patch, I have it as: |
| 18:26.02 | philipp64 | -CFLAGS= -g -Wall $(EXTRA_CFLAGS) |
| 18:26.04 | philipp64 | +CFLAGS_old := $(CFLAGS) |
| 18:26.06 | philipp64 | +CFLAGS= -g -Wall $(USB_INCLUDE) $(CFLAGS_old) |
| 18:26.39 | philipp64 | although... hmmmm... maybe CFLAGS_makeopts or CFLAGS_parent would have been a better name. |
| 18:27.41 | tzafrir_laptop | ok. EXTRA_CFLAGS was once used to add some flags. But that need is long gone |
| 18:27.54 | tzafrir_laptop | It can be safely overriden |
| 18:28.24 | tzafrir_laptop | Though simply using CFLAGS is probably cleaner |
| 18:30.32 | philipp64 | So... CFLAGS += -g -Wall $(USB_INCLUDE) then? |
| 18:31.02 | tzafrir_laptop | yes |
| 18:34.15 | tzafrir_laptop | patch updated |
| 18:41.54 | *** join/#asterisk-dev bradleyd_ (n=bradleyd@66.193.229.254) |
| 18:42.50 | bradleyd_ | any differences between 1.4.21.2 an 1.4.22 that would affect TE420 digium card? |
| 18:56.03 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:59.21 | kpfleming | bradleyd_: asterisk does not talk directly to cards, so that's highly doubtful unless the symptoms are not related to the card either |
| 19:00.26 | bradleyd_ | i was puzzled by it also, but that is what the doc said. SO know I am wondering if an error I have is the cause of the software versions. |
| 19:00.41 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) |
| 19:00.43 | kpfleming | what 'doc' are you talking about |
| 19:01.11 | bradleyd_ | the manual for the TE420 card |
| 19:01.26 | kpfleming | your statements are very confusing |
| 19:01.44 | kpfleming | first of all, this really belongs in #asterisk |
| 19:01.58 | kpfleming | but when you get there you need to clearly state what problem you are having |
| 19:02.47 | bradleyd_ | I did, was wondering about the source code...I was wondering why digium would state the their TE420 cards need 1.4.22 or later to operate. |
| 19:03.06 | bradleyd_ | if there were any differences anyone knew off the top of their head |
| 19:04.10 | kpfleming | please provide a link to that statement... i don't believe that is true |
| 19:05.08 | philipp64 | tzafrir_laptop: separate issue. got a minute more? |
| 19:05.25 | bradleyd_ | it is in their pdf, https://www.digium.com/elqNow/elqRedir.htm?ref=http://docs.digium.com/TE420/te400series-user-manual.pdf |
| 19:05.27 | tzafrir_laptop | philipp64, yes |
| 19:05.35 | kpfleming | let me take a look |
| 19:05.45 | bradleyd_ | k, thanks |
| 19:06.16 | kpfleming | page number? |
| 19:06.26 | philipp64 | asterisk's configure script is finding $(BUILD_DIR)/staging_dir/usr/lib/libtonezone.a ... but it's looking for zaptel/tonezone.h ... which it won't find, since we're using dahdi instead. |
| 19:06.47 | bradleyd_ | #34 |
| 19:07.28 | kpfleming | you have completely misunderstood what that page says |
| 19:07.43 | kpfleming | 1.4.22 is required because the installation steps are for using DAHDI, which was not supported by 1.4.21 and older |
| 19:07.54 | kpfleming | it has nothing to do with the card being a TE420 specifically |
| 19:08.13 | bradleyd_ | oh, sorry that I wasted your time--thanks |
| 19:08.14 | kpfleming | if you want to use zaptel with an older release of asterisk, feel free to do so, although using an older release has its own problems |
| 19:08.25 | bradleyd_ | k |
| 19:09.10 | tzafrir_laptop | philipp64, the problem is that it needs dahdi/user.h from dahdi-linux and dahdi/tonezone.h from dahdi-tools |
| 19:09.50 | tzafrir_laptop | any chance that those two files are installed to different directories? |
| 19:10.54 | philipp64 | oh, hang on. |
| 19:11.23 | philipp64 | I lost it in the noise... I wasn't building with --with-dahdi=... , which I need to be doing on a cross-compile. my bad. |
| 19:11.44 | philipp64 | I noticed that we have dahdi-tools dependent on dahdi-linux... and dahdi-linux always rebuilds. |
| 19:12.13 | philipp64 | if you do "make" twice in that directory, it doesn't say "nothing to build" the second time... (or whatever) |
| 19:12.31 | philipp64 | is that an artefact of kbuild? |
| 19:15.12 | philipp64 | i.e. are kernel modules always recompiled and relinked? or is there a way to get dahdi-linux to know when it's already built, and there's nothing to rebuild. |
| 19:16.40 | kpfleming | no, the kernel build process always does some number of steps, even if nothing has changed |
| 19:28.42 | tzafrir_laptop | philipp64, so the patch works for you? |
| 19:32.43 | philipp64 | yup. |
| 19:32.56 | philipp64 | figured out why dahdi-linux keeps rebuilding, too. |
| 19:33.04 | philipp64 | broken dependency on newt... |
| 19:33.19 | philipp64 | grrr... buildroot has so many broken makefiles. |
| 19:33.27 | kpfleming | dahdi-linux does not use newt |
| 19:35.21 | tzafrir_laptop | philipp64, one specific module gets rebuilt? all modules? |
| 19:45.48 | philipp64 | dahdi.ko gets rebuilt |
| 19:46.15 | tzafrir_laptop | .version was changed? |
| 19:46.44 | philipp64 | no... |
| 19:46.54 | philipp64 | actually, the problem seems to come from a couple of places: |
| 19:46.56 | philipp64 | DAHDI_TARGET_BINARY := lib/modules/$(LINUX_VERSION)/dahdi/dahdi.ko |
| 19:47.12 | philipp64 | when this gets evaluated, $(LINUX_VERSION) hasn't yet been set. |
| 19:47.27 | philipp64 | so I need to come up with a work around for that... hmm... |
| 19:48.02 | *** join/#asterisk-dev Chris-NB (n=chris@home.fuerstaller.com) |
| 19:58.24 | philipp64 | tzafrir_laptop: how long before this fix goes out in a new version of dahdi-tools? |
| 19:58.53 | tzafrir_laptop | it's in svn. It will take a while for 2.3 to be released. |
| 19:59.05 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 19:59.05 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:59.07 | tzafrir_laptop | not sure about a 2.2.0.x |
| 20:16.20 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 20:16.20 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:18.00 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 20:20.46 | philipp64 | ok. I'll put a patch file directly into our SVN tree then. |
| 20:26.23 | *** join/#asterisk-dev methos (n=methos@S0106000c42163173.ed.shawcable.net) |
| 21:14.36 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 21:16.24 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.101.140) |
| 21:17.44 | mnicholson | can anyone explain to me what the chan->tech->fixup() function is supposed to do? |
| 21:19.03 | Corydon76-dig | mnicholson: when the guts of a channel are replaced with a masquerade, change internal references to the channel so that the structure is still valid |
| 21:19.04 | russellb | it gets called during a masquerade |
| 21:20.02 | mnicholson | it looks like fixup is called twice during a masq, once on the "clonechan" and then again on the original channel, but with the arguments reversed |
| 21:20.44 | russellb | that is correct |
| 21:21.01 | mnicholson | what should the fixup fix in each of those situations? |
| 21:21.08 | mnicholson | i think chan_mobile's version is buggy |
| 21:21.28 | russellb | look at all of the others, the logic is pretty simply |
| 21:21.30 | russellb | simple* |
| 21:21.42 | russellb | iterate your pvt structs, replace any references to "old chan" with "new chan" |
| 21:21.43 | russellb | that's it |
| 21:22.07 | mnicholson | hmm, ok, i'll see if i can make sense of it |
| 21:22.31 | mnicholson | i looked in chan_sip, still didn't completely make sense, i'll look again and check chan_iax |
| 21:25.29 | russellb | chan_iax2 doesn't iterate, because it knows that the only reference to that channel would be in the pvt currently attached to the old channel |
| 21:25.39 | russellb | and that pvt is about to get moved to the new one, so it updates its owner pointer |
| 21:42.31 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 21:48.27 | mnicholson | all better now! |
| 21:51.15 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 21:51.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:05.58 | russellb | mnicholson: your commit message doesn't sound right |
| 22:06.08 | russellb | the masquerade handles moving the tech_pvt pointer for you |
| 22:06.33 | russellb | the only thing you're supposed to do in fixup is handle _internal_ ast_channel pointers to make them accurate before the swap that is about to happen |
| 22:07.08 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.215) |
| 22:07.29 | mnicholson | russellb, my fix only fiddles with the pvt->owner, the commit message may be incorrect |
| 22:08.13 | russellb | commit asterisk 205700 |
| 22:08.17 | MuffinMan | [205700] Committed by mnicholson on 2009-07-09T21:32:31.210950Z: Fix mbl_fixup() in chan_mobile to update newchan->tech_pvt instead of oldchan. |
| 22:08.17 | MuffinMan | .. |
| 22:08.17 | MuffinMan | ..(closes issue #15299) |
| 22:08.17 | MuffinMan | ..Reported by: nikkk |
| 22:08.18 | MuffinMan | .. |
| 22:08.20 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=205700 |
| 22:08.38 | mnicholson | russellb, the commit message is correct, but it is ambiguous |
| 22:08.44 | russellb | heh |
| 22:08.47 | russellb | ooooooookay! |
| 22:08.47 | russellb | :-) |
| 22:08.57 | russellb | i'll just assume we're on the same page |
| 22:09.11 | russellb | i'll look it over when I go through commits, i try to look at all of them .. |
| 22:09.42 | mnicholson | russellb, ok. The actual change does not change the tech_pvt pointer, it changes tech_pvt->owner |
| 22:09.55 | russellb | yep, i see what you did now |
| 22:09.56 | russellb | looks fine |
| 22:09.58 | russellb | kthxbye |
| 22:09.59 | russellb | :-) |
| 22:10.02 | mnicholson | :) |
| 22:36.57 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.216) |