| 00:10.09 | *** join/#asterisk-dev simond (n=simon@76.74.139.38) |
| 00:15.05 | *** join/#asterisk-dev anthm (n=anthm@70-9-230-238.area4.spcsdns.net) |
| 00:15.05 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 00:25.30 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 00:46.54 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 00:56.15 | Juggie | Corydon76-dig: ping |
| 00:59.03 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:16.22 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:16.22 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:41.16 | *** join/#asterisk-dev JerJer[mobile] (n=jj@dhcp-11-163.hstf.interop.net) |
| 01:53.25 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:56.21 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 02:03.02 | Corydon76-dig | Juggie: pong |
| 02:33.55 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.198) |
| 02:34.36 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.179.149) |
| 03:09.51 | Juggie | Corydon76-dig, still there? |
| 03:10.49 | Juggie | i'm heading to bed, i'll find you tomorow, i wanted to run an idea by you. |
| 03:17.02 | Corydon76-dig | Of course I'm still here |
| 03:17.12 | Corydon76-dig | Tomorrow, however, I won't be |
| 03:31.16 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 03:44.14 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 03:48.10 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 04:05.25 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 04:17.32 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:55.13 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-282332.home.otenet.gr) |
| 04:58.43 | steliosk | ~seen paravoid |
| 04:58.46 | jbot | paravoid is currently on #asterisk-dev. Has said a total of 49 messages. Is idling for 7d 4h 36m 30s, last said: 'pri_dchannel is such crap'. |
| 05:35.19 | *** join/#asterisk-dev fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 05:42.41 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 06:08.13 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 06:28.24 | *** join/#asterisk-dev gmaruzz (n=maruzz@213-140-6-122.ip.fastwebnet.it) |
| 06:37.23 | *** join/#asterisk-dev Sir0x (n=cmayer@p5B0842A7.dip.t-dialin.net) |
| 06:37.38 | Sir0x | morning |
| 06:41.29 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.134) |
| 06:53.53 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:02.26 | *** join/#asterisk-dev bps (n=none@host.250.19.23.62.rev.coltfrance.com) |
| 08:10.26 | paravoid | steliosk: mpou |
| 08:20.53 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 09:41.51 | *** join/#asterisk-dev kay2 (n=two@gob75-7-82-247-113-230.fbx.proxad.net) |
| 09:41.57 | kay2 | hi |
| 09:42.21 | kay2 | is it interesting to have a RTMP endpoint for asterisk ? so it would let to do click2call from a browser that has flash |
| 09:52.37 | tzafrir | mvanbaak, what exactly is this (channel-specific?) parking-lot? |
| 09:54.36 | mvanbaak | tzafrir: right now there's one parkinglot. so if you host multiple companies on a pbx and companyA parks a call companyB can pickup |
| 09:54.48 | mvanbaak | just dial 701 till you have someone on the phone |
| 09:55.02 | mvanbaak | with this parkinglot, you can create multiple parking 'zones' |
| 09:55.30 | mvanbaak | and by setting the parkinglot on a channel, that channel can only pickup calls in that specific parking 'zone' |
| 09:55.55 | mvanbaak | great for multihosting |
| 10:17.51 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:19.13 | agx | mvanbaak, unluckly parking is not that easy, on some phones you need to do some trick to hear the number where you've parked (and using autopark from features.conf si buggy in 1.4) |
| 10:20.49 | *** join/#asterisk-dev floppp (n=flopp@nat-staff.b3g-telecom.com) |
| 10:21.30 | tzafrir | mvanbaak, currently Zaptel has some ugly internal logic to hold a single call |
| 10:21.37 | tzafrir | chan_zap, that is |
| 10:22.09 | mvanbaak | tzafrir: we know. jpeeler added the parkinglot info there yesterday |
| 10:22.21 | mvanbaak | and told me it worked |
| 10:22.40 | tzafrir | Anything that removes complexity from chan_zap helps :-) |
| 10:22.55 | mvanbaak | agx: hhmm. This work is on based on trunk. |
| 10:22.56 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.140) |
| 10:23.13 | mvanbaak | agx: and I never had to play with phone settings to hear the number I parked to |
| 10:23.24 | mvanbaak | and as for autopark: if it's buggy file a bugreport ;) |
| 10:27.01 | agx | mvanbaak, well "file a bugreport" sounds hilarious, but i'm not in the mood of flames this morning :) |
| 10:27.32 | agx | mvanbaak, you using polycom phones? |
| 10:31.43 | mvanbaak | agx: no |
| 10:32.05 | mvanbaak | snom, gs, cisco and aastra |
| 10:34.02 | mvanbaak | is the autopark stuff also buggy in 1.6/trunk ? |
| 10:35.20 | agx | mvanbaak, no sorry tested 1.6 only about trying the new codec negotiation stuffs, got miserably crashes and gived up |
| 10:35.59 | agx | mvanbaak, i usally rebind the Snom's conference key as "trasnfer to 700" to park stuffs |
| 10:45.00 | mvanbaak | I use one of the speeddials for that most of the time |
| 10:48.30 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 11:31.43 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 12:08.27 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 12:13.31 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:24.30 | *** join/#asterisk-dev jeffg (i=0phTISc7@pdpc/supporter/active/jeffg) |
| 12:28.18 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:37.21 | *** join/#asterisk-dev _Krieger_ (n=krieger@193.39.118.158) |
| 12:46.32 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:49.13 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 12:54.08 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:54.08 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:15.38 | flujan | ping Corydon-* |
| 13:15.48 | flujan | ping Corydon76-dig |
| 13:16.16 | flujan | ping file |
| 13:16.49 | Corydon76-dig | What now? |
| 13:17.52 | flujan | hello, Corydon... I contact the digium support as you said tomorrow... I updated zaptel to the last release, |
| 13:18.18 | flujan | today I perform tests, and I believe it could a be a lock in asterisk. I just don't have enough knowledge to make it for sure |
| 13:18.43 | flujan | could you please check this lock output? |
| 13:18.44 | flujan | http://pastebin.com/m2e48eed8 |
| 13:18.47 | Corydon76-dig | This STILL isn't a support channel |
| 13:19.08 | flujan | and sorry for disturbing you, but I do not know others who can help me interpret this... |
| 13:19.25 | flujan | ok, but I believe it is a bug with asterisk translate.c |
| 13:20.12 | Corydon76-dig | If you have a new report, the proper thing to do is to file the report on bugs.digium.com and coordinate on #asterisk-bugs |
| 13:20.34 | flujan | Corydon76-dig: ok will do that... thanks anyway and sorry again... :) |
| 13:20.37 | Corydon76-dig | If this is for an existing report, then add to that report and coordinate on #asterisk-bugs |
| 13:24.29 | tzanger | hmm |
| 13:24.30 | tzanger | with zaptel |
| 13:24.47 | tzanger | to spans take preference over everything else for zaptel clock? |
| 13:25.02 | tzanger | i.e. I have a tdm400. if I have a dynamic span that is clock=0, the tdm400 is providing timing |
| 13:25.14 | tzanger | with clock=1 or 2 or 3 though, the span seems to always provide clock |
| 13:26.30 | tzanger | it appears that analog cards take lowest priority |
| 13:28.40 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 13:31.37 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.235.113) |
| 13:37.07 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:38.30 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:38.30 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:55.20 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 13:55.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:58.49 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 13:58.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:00.53 | oej | Afternoon folks |
| 14:04.19 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 14:06.20 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 14:13.34 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 14:29.36 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 14:33.12 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 14:42.30 | flujan | hello oej |
| 14:50.39 | lmadsen | morning oej |
| 14:56.13 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 14:57.20 | agx | oej, do you have a codec negotiation branch active? |
| 14:57.34 | oej | Videocaps is kind-of that |
| 14:57.50 | oej | it's a media negotiation branch with focus on video, but can be extended to audio |
| 14:57.51 | agx | oej, is still a separate branch or part of 1.6-beta ? |
| 14:57.58 | oej | A separate branch |
| 14:58.09 | agx | oej, all right, i'll search svn for it, thank you |
| 14:58.51 | agx | oej, i want the phones on local LAN to talk each other with the best codec they have but when switching to MOH or Voicemail they need to be reinvited with G.711 |
| 15:01.42 | agx | oej, is http://svn.digium.com/view/asterisk/team/oej/videocaps/ ? |
| 15:03.43 | oej | agx: yes |
| 15:03.54 | oej | We never do re-invites to switch codec. |
| 15:04.23 | oej | We can however set up a call with multiple codecs and then start sending G.711 if it's doable, even if we have another codec active in the call |
| 15:05.18 | agx | oej, do you mean i set the phones with allow=g722,g729,ulaw and then when i enter dialplan own session i use Set(SIP_CODEC=ulaw) to force it? Its ok for voicemail but will not work with MOH |
| 15:05.33 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:05.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:10.20 | oej | agx: As I said, I don't think you can *force* asterisk to change codec today. SIP_CODEC is used in call setup. |
| 15:10.49 | agx | oej, oky |
| 15:10.53 | oej | agx: But if you have g722, g729 and alaw and the other side has g729 and alaw - BOTH codecs are allowed in the call and the RTP stream can switch any time. |
| 15:11.11 | oej | agx: In fact, that happens now and then. Asterisk sends out an "ouch" and then just lives happily with it. |
| 15:13.35 | agx | oej, yes but if i've a license for 10 channels and that's the 11th g729 call there is an error when putting it on hold about "translate from g729 to slin" |
| 15:16.18 | codefreeze | oej-- a question for you. I'm still laboring on my bug11210 branch. I see that dialogs doomed for destruction (via hangups, etc), are marked with needdestroy. Then, in do_monitor, about once a second, we search for such and destroy them... why don't we just destroy them immediately? |
| 15:16.51 | oej | I never understood that part either - or cared much. |
| 15:17.13 | oej | Do_monitor is kind of the central thread that does that kind of stuff, like reload config. Singlethread stuff. |
| 15:17.32 | oej | But it might just be a remains of the past, something that was never questioned |
| 15:17.41 | codefreeze | tends to think there is "method in their madness"; discovering it is the challenge... |
| 15:18.26 | oej | do_monitor locks the dialog list, right, while doing this? We don't want all call threads to do that too often. |
| 15:19.16 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 15:19.33 | codefreeze | yes it does. And at high call volumes, say 1500 calls/sec, you could have built up 1500 or more.... |
| 15:24.22 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 15:24.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:24.46 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.198) |
| 15:27.06 | codefreeze | It would really, really, be nice, if there was a function I could call, that would use ast_log() to print out the current owners of a lock....... |
| 15:27.53 | oej | Yep |
| 15:28.03 | Corydon76-vcch | That's only stored when debugging is turned on |
| 15:28.10 | oej | I was happy when I found that Linux stuff so I could at least show the NUMBERS of locks that existed |
| 15:28.25 | oej | We could propably add the thread ID to that log output now to at least help a bit |
| 15:28.43 | oej | That way you could log and see who caught it by digging through the log files |
| 15:30.54 | codefreeze | I'm noticing that about 3% or so of the dialogs marked with "needdestroy", are LOCKED when do_monitor() runs thru the list to destroy them... subsequent calls get them cleared out... I'm now very curious as to where they are locked.... |
| 15:31.23 | oej | That's part of the magic |
| 15:31.39 | putnopvut | codefreeze: does "core show locks" not do the trick for you? |
| 15:31.41 | oej | We turn on the flag and then we do some more stuff |
| 15:32.17 | codefreeze | putnopvut: no, these locks seem to be pretty short-lived. I haven't caught one yet with "core show locks". |
| 15:33.41 | codefreeze | oej: and magic it is! :) |
| 15:34.23 | agx | oej, i've checked translate.c it looks like that when asterisk negotiate a codec it will always uses that one for all the others calls. I mean: A and B support g729,ulaw . When A put B on hold it try to translate it to slin always using the 1st codec even if the phone support more codecs. |
| 15:36.27 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.140) |
| 15:46.09 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 15:47.48 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:48.32 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 15:52.52 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.140) |
| 16:05.54 | Juggie | Corydon76-dig: ping. |
| 16:14.05 | jpeeler | is MAX_BUCKETS for an ao2 container just the number of elements? |
| 16:14.35 | putnopvut | jpeeler: no, it's the number of unique hashes that can be formed. |
| 16:14.51 | jpeeler | hmm |
| 16:14.54 | jpeeler | how does one determine the MAX_BUCKETS required for an ao2 container? |
| 16:14.58 | putnopvut | jpeeler: so if for instance, you had just 1 bucket, then it would be a linked list. |
| 16:15.21 | jpeeler | putnopvut: what about beyond that |
| 16:15.26 | putnopvut | jpeeler: what I've done is to pick a prime number which is roughly the number of elements I expect to be in the container at any given time. |
| 16:15.50 | jpeeler | oh i get it now |
| 16:16.11 | Juggie | putnopvut, got 30 seconds, i want an opinion on a thought i had :) |
| 16:16.13 | putnopvut | Yeah, each bucket is a linked list of elements that all hash to the same value. |
| 16:16.21 | jpeeler | but then, why did you choose a prime? |
| 16:16.23 | putnopvut | Juggie: sure. |
| 16:16.59 | putnopvut | jpeeler: it was russell's idea. Apparently that allows for better distribution of the objects into the container. |
| 16:17.04 | kpfleming | umm... you don't want the number of buckets to be the number of elements |
| 16:17.19 | Juggie | putnopvut, at it360 there was alot of discussion in the asterisk track about hosted pbx's and the fact you cant isolate in the AMI, after discussing it for a bit and thinking about it, i had this thought... what about if we could setup a AMI user such that we could filter on a channel variable, eg, MYVAR=USER1 |
| 16:17.35 | kpfleming | that creates a lot of overhead, because you have a bucket plus a linked list for each element |
| 16:17.53 | kpfleming | Juggie: what about events that occur at channel creation time? |
| 16:18.26 | putnopvut | kpfleming: that's true, but it also provides for quicker lookups when trying to find an element. |
| 16:18.50 | Juggie | kpfleming, thats a good question, i could not think of any other way to do it though when you consider incomming calls. |
| 16:19.31 | kpfleming | i already proposed that |
| 16:19.45 | kpfleming | the endpoints have to be marked with a 'virtual host' identifier or something |
| 16:19.56 | kpfleming | for trunks, it gets much harder |
| 16:20.04 | Juggie | right but what if it never gets to an endpoint was the situation i thought about |
| 16:20.15 | Juggie | it goes to an auto attendant then to voicemail |
| 16:20.54 | Juggie | without an endpoint like you said it gets much harder. |
| 16:21.09 | jpeeler | is this true: the container is segmented by the number of buckets, each containing a different hash, and the hash is used internally to speed up searches. |
| 16:21.37 | oej | agx: sorry, was in phone conference call |
| 16:24.06 | Juggie | kpfleming, in that case i think the only solution may be to allow the 'virtualhost' to be set in the dialplan once the call is answered and you know which client it is for |
| 16:24.21 | kpfleming | yes |
| 16:24.25 | kpfleming | it's a complex problem |
| 16:25.24 | *** join/#asterisk-dev moy (n=moyhu@189.169.62.71) |
| 16:25.31 | putnopvut | jpeeler: yes, as I understand it. |
| 16:26.22 | jpeeler | putnopvut: is there a general rule to determine a good number of max_buckets? |
| 16:26.25 | Juggie | i guess the only problem with using a channel variable to do this is when the channel variable gets assigned to the channel would cause some events to not get sent. |
| 16:26.42 | jpeeler | i have no idea how many objects will actually be put in |
| 16:26.44 | Corydon76-vcch | jpeeler: yes, a prime number |
| 16:27.01 | jpeeler | any prime? |
| 16:27.13 | file | a happy prime! |
| 16:27.27 | Corydon76-vcch | jpeeler: think about scale. If it's small, try 7. Large, try 37 or 41. |
| 16:27.44 | Qwell | why prime? |
| 16:27.46 | file | (just joking, don't go looking for a happy prime... although you could I suppose...) |
| 16:27.51 | putnopvut | jpeeler: if you're talking about number of parking lots, I'd expect a small number. |
| 16:28.20 | jpeeler | putnopvut: well that's where i was leaning... but with multiple parking lots the number could go way up |
| 16:28.47 | jpeeler | i mean... i guess all of the calls would have to be parked too though, so maybe not |
| 16:29.05 | putnopvut | jpeeler: that's true, but I'd expect that in the normal case, most people aren't going to have a ton of parking lots. |
| 16:29.28 | Corydon76-vcch | jpeeler: Yeah, I'd go for 7, then. |
| 16:29.39 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 16:29.53 | jpeeler | Corydon76-dig: i am curious, why not say 3? |
| 16:29.56 | Corydon76-vcch | jpeeler: you're mainly looking for even distribution, but remember that there's no collision avoidance |
| 16:30.42 | jpeeler | Corydon76-dig: i haven't looked at adding elements yet, do i have to determine which bucket to add to? |
| 16:31.16 | putnopvut | jpeeler: sort of. You have to provide the hash function used by astobj2 |
| 16:32.24 | putnopvut | You would use ao2_container_link, and then astobj2 uses the hash function provided to determine which bucket to put the element in. |
| 16:32.32 | putnopvut | actually... |
| 16:32.36 | jpeeler | putnopvut: so the hash function needs to attempt to spread the inserted objects evenly among the buckets? |
| 16:33.10 | putnopvut | actually it's just ao2_link, not ao2_container_link |
| 16:33.14 | putnopvut | jpeeler: yes. |
| 16:33.30 | putnopvut | There's a function called ast_str_hash you can use if you're hashing based on a string. |
| 16:33.57 | putnopvut | If you want to see how it works, I believe it is in strings.h |
| 16:34.10 | file | "magic" |
| 16:35.10 | *** join/#asterisk-dev RoyK (n=roy@gprs-ggsn6-nat.mobil.telenor.no) |
| 16:38.35 | kpfleming | right, so you'd be best off to run a representative sample of your proposed entries through the available hashing functions to see how the distribution looks |
| 16:38.46 | kpfleming | if it's poor, then you might need to create your own hashing function |
| 16:41.31 | jpeeler | kpfleming: are you referring to general asterisk hashing functions or are there some defaults specifically for ao2? |
| 16:41.50 | kpfleming | i don't know |
| 16:41.55 | kpfleming | my ao2 knowledge is very small |
| 16:42.30 | jpeeler | oh ok, i wasn't seeing any builtin hash functions for ao2, although that seems like that would be nice to have |
| 16:46.19 | file | ast_str_hash is the only one we have right now I do believe |
| 16:48.19 | *** part/#asterisk-dev gmaruzz (n=maruzz@213-140-6-122.ip.fastwebnet.it) |
| 16:48.47 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 16:51.02 | jpeeler | file: yeah i'll probably just hash the parkinglot name |
| 17:02.59 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584618.dsl.bell.ca) |
| 17:04.29 | *** join/#asterisk-dev Daviey (n=dave@ubuntu/member/daviey) |
| 17:09.40 | mvanbaak | jpeeler: as you might have noticed, I have the parkinglot stuff in most channel drivers now |
| 17:10.23 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 17:10.45 | jpeeler | mvanbaak: yeah, i haven't looked at it yet, but thanks |
| 17:11.39 | agx | in channel/chan_sip.c can i change tmp->nativeformats to more then 1 single codec when/after negotiating ? |
| 17:17.58 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 17:19.16 | mvanbaak | jpeeler: :) |
| 17:19.29 | mvanbaak | jpeeler: you are actually running the astobj1 version ? |
| 17:21.03 | jpeeler | mvanbaak: i'm just starting the conversion, so yes |
| 17:24.19 | mvanbaak | cool |
| 17:29.24 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.134) |
| 17:50.57 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 17:57.53 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584618.dsl.bell.ca) |
| 18:13.12 | Damin | Bahh.. |
| 18:13.41 | jpeeler | putnopvut: is it more preferred to use a container with one bucket as opposed to just using the linkedlist API? |
| 18:14.07 | putnopvut | jpeeler: no, it is not. |
| 18:14.42 | putnopvut | jpeeler: I guess the one advantage you'd have there is having refcounted objects in a linked list. |
| 18:15.11 | putnopvut | But the problem is that you can't use the linked list macros directly on it and so you don't have the same amount of control you would otherwise. |
| 18:16.04 | jpeeler | i see |
| 18:19.23 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 18:20.09 | kpfleming | well.. ideally there would be a linked-list style ao2 container, but there is not at this point |
| 18:20.40 | putnopvut | kpfleming: there's an idea. |
| 18:20.42 | jpeeler | ah right |
| 18:21.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:21.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:23.18 | mvanbaak | hey oej |
| 18:23.44 | mvanbaak | I got stuck on the linkedlist stuff when looking at astobj2 |
| 18:30.30 | oej | Me too :-) |
| 18:35.34 | mvanbaak | oej: jpeeler is fixing it in main/features.c for the parkinglot stuff |
| 18:35.45 | mvanbaak | we can bug him about it once he's done :) |
| 18:36.03 | jpeeler | which may take a while... |
| 18:36.19 | mvanbaak | no problem |
| 18:36.42 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 18:36.42 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 19:06.48 | oej | We may want to have "example code" as an option in Menuselect. My compilation of 1.4 stopped on eagi-sphinx, which is not needed at all. I have to edit the makefile to disable that stuff and code in utils |
| 19:17.30 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 19:23.57 | oej | assertion "current_variable_set_list->next != 0" failed: file "expand.c", line 489 |
| 19:24.12 | oej | I can't file the "expand.c" file when compiling. This is running "make" on 1.4... |
| 19:24.19 | oej | Weird stuff |
| 19:33.48 | file | oej: upgrade make |
| 19:34.20 | jsmith | Hey guys, did something radically change with Zaptel 1.4.10? |
| 19:34.24 | jsmith | feels like a total idiot |
| 19:34.50 | jsmith | Download/compile/install zaptel 1.4.10, and when I start Zaptel (via the RH initscript), it says that it's missing /dev/zap |
| 19:35.25 | jsmith | For some reason, it's not loading the proper modules like it did before |
| 19:35.27 | oej | That was supposed to only be active on April 1st |
| 19:35.46 | jsmith | oej: That was just zaptel *trunk*, not 1.4 branch :-) |
| 19:38.27 | lmadsen | and I don't think it was an april fools joke to remove zaptel trunk... |
| 19:38.32 | jsmith | Nope |
| 19:38.35 | jsmith | It wasn't |
| 19:38.45 | lmadsen | it was pretty out of date |
| 19:38.48 | lmadsen | funny enough :) |
| 19:47.53 | *** part/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 19:51.50 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.198) |
| 19:52.17 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 19:52.58 | codefreeze | Corydon76-dig: that little change to chan_sip concerning __sip_destroy.... sigh.... |
| 19:55.53 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.198) |
| 19:57.34 | Juggie | jsmith, did you clear customs in toronto when you left? |
| 19:57.41 | Juggie | (us customs i mean) |
| 19:58.14 | jsmith | Juggie: Roger! |
| 19:58.21 | Juggie | thats what i figured |
| 19:58.32 | Juggie | pre-clearing before you leave is so much more convient |
| 19:58.42 | Juggie | no screwing around when you land |
| 20:32.45 | *** join/#asterisk-dev Bourrelle (n=Bourrell@132.207.156.100) |
| 20:44.09 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584618.dsl.bell.ca) |
| 20:57.58 | Corydon76-vcch | Looks like the backers of CogoBlue are ethically-challenged |
| 20:58.33 | file | hrm? |
| 20:59.35 | Corydon76-vcch | He posted a note to the -users list raving about his project, without identifying it as such |
| 21:00.19 | Corydon76-vcch | A user coming across that note might believe it was by a customer recommending it, not a hawker of his own products |
| 21:00.53 | Corydon76-vcch | Maybe they're just not getting the response they thought they would... |
| 21:02.25 | Corydon76-vcch | M12402 |
| 21:02.26 | MuffinMan | [new] [Asterisk] Core/NewFeature 0012402: [patch] Restrict what is printed during -rx output reported by Corydon76 http://bugs.digium.com/view.php?id=12402 |
| 21:05.14 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:11.38 | putnopvut | I'm trying to make asterisk build with the LOW_MEMORY flag set, and in trunk, I'm getting errors like: |
| 21:11.50 | putnopvut | astman.c:101: error: expected identifier or â(â before âwhileâ |
| 21:11.57 | putnopvut | There are no while loops in astman.c |
| 21:12.33 | putnopvut | Any idea where to look when such an odd compiler error occurs? |
| 21:14.39 | putnopvut | Here's a more complete error log: |
| 21:14.40 | putnopvut | http://pastebin.ca/980216 |
| 21:14.52 | putnopvut | none of it makes any sense. |
| 21:17.47 | Corydon76-vcch | putnopvut: betcha it's a macro with do { } while (...) |
| 21:18.36 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:19.17 | kpfleming | i bet there is no definition of uint64_t for some reason |
| 21:19.59 | kpfleming | putnopvut: did you say trunk? |
| 21:20.04 | putnopvut | kpfleming: yes. |
| 21:20.35 | kpfleming | doesn't make much sense, since line 95 is a function prototype |
| 21:21.10 | putnopvut | kpfleming: exactly what I was thinking... |
| 21:21.35 | kpfleming | let me see if i can get preprocessor output to look at |
| 21:21.52 | Corydon76-vcch | kpfleming: ooo, yeah, it's fun |
| 21:27.42 | kpfleming | bingo! |
| 21:28.08 | kpfleming | just for your edification, add a line of 'astman.o: astman.i' to utils/Makefile and then recompile, and you can see the preprocessor output |
| 21:28.47 | putnopvut | kpfleming: thank you very much! |
| 21:29.04 | kpfleming | the offending code is in asterisk.h, where ast_add_profile() is #defined to 0 (yes, zero) if LOW_MEMORY is defined |
| 21:29.09 | kpfleming | that is bad |
| 21:29.10 | kpfleming | very bad |
| 21:29.23 | kpfleming | it should be do { } while (0) like the other functions are |
| 21:29.28 | kpfleming | AFAIK |
| 21:30.10 | kpfleming | but even so, astman.c will need to not redefine those functions if they are #defined |
| 21:30.26 | kpfleming | so somebody please fix it :-) |
| 21:30.42 | kpfleming | actually, we can't change the #define for ast_add_profile |
| 21:30.48 | kpfleming | so the changes just need to happen in astman.c |
| 21:31.16 | putnopvut | kpfleming: great. Thanks for the help. I'll get on it. |
| 21:32.25 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 21:39.52 | putnopvut | kpfleming: ooh, that preprocessor output makes the compilation errors make complete sense now. Thanks for the tip. |
| 21:40.22 | kpfleming | you are most welcome |
| 21:40.32 | kpfleming | i added that .i rule a long time ago when working on something similar |
| 21:41.09 | file | puts a pthread barrier in front of kpfleming |
| 22:00.29 | putnopvut | yay! It builds! |
| 22:14.16 | kpfleming | fweet |
| 22:15.02 | file | putnopvut: yay |
| 22:41.14 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:41.15 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:52.22 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 23:00.41 | *** join/#asterisk-dev fujin (n=aj@unaffiliated/fujin) |
| 23:00.42 | fujin | Hiyas! |
| 23:01.03 | fujin | just wanted to say hanks to mmichelson for fixing http://bugs.digium.com/view.php?id=11775, if he's around |
| 23:01.07 | fujin | anywa, thanks ! |
| 23:01.07 | *** part/#asterisk-dev fujin (n=aj@unaffiliated/fujin) |
| 23:02.28 | lmadsen | putnopvut: ^^^ |
| 23:02.53 | putnopvut | oh, cool. |
| 23:04.36 | jsmith | putnopvut: Way to go... now you're really setting people's expectations! |
| 23:04.59 | jsmith | putnopvut: Keep that up, and people might start believing that filing a bug will lead to a fix ;-) |
| 23:05.07 | putnopvut | lol |
| 23:06.16 | file | jsmith: that is crazy talk |
| 23:06.46 | jsmith | file: Yes, which is why I shouldn't hang out in IRC while medicated |
| 23:07.25 | jsmith | file: http://www.despair.com/ap24x30prin.html |
| 23:10.24 | putnopvut | jsmith: I should double-check, but I think that poster is hanging up in PQ here. |
| 23:10.55 | putnopvut | it is. |
| 23:11.19 | tzafrir | speaking about that, can anybody look at korihor's report at #asterisk ? |
| 23:11.45 | jsmith | With a nick like that, I've gotta check it out |
| 23:12.00 | jsmith | tzafrir: What is the issue he's reporting? |
| 23:13.22 | tzafrir | answer-on-polarity does not work with 1.2.25/wctdm.c (regression vs. 1.2.24) |
| 23:13.41 | *** join/#asterisk-dev RoyK (n=roy@ip-210-6-149-91.dialup.ice.no) |
| 23:19.55 | *** part/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 23:29.31 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:29.31 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:36.16 | *** part/#asterisk-dev RoyK (n=roy@ip-210-6-149-91.dialup.ice.no) |