| 00:26.18 | tzafrir_home | russellb, regarding the variables renaming patches in chan_zap: |
| 00:27.18 | tzafrir_home | I really have a hard time understanding that code. Go figure that "tmp" is a ast_channel and i is a zt_pvt (or the other way around) |
| 00:27.34 | tzafrir_home | So when will it be a good time to clear things out? |
| 00:45.25 | *** join/#asterisk-dev seanbright (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 00:48.14 | *** join/#asterisk-dev RoyK (n=roy@ip-21-60-149-91.dialup.ice.no) |
| 01:04.31 | *** join/#asterisk-dev pputman (n=pputman@c-71-207-165-154.hsd1.al.comcast.net) |
| 01:24.54 | Corydon76-dig | Evening, centrex |
| 01:28.13 | seanbright | Corydon76-dig: time for a quick question about adaptive odbc? |
| 01:32.43 | *** join/#asterisk-dev jeffg (i=UPjUUORv@pdpc/supporter/active/jeffg) |
| 01:34.11 | JunK-Y | tzafrir_home: i already proposed standard for structs, like chan is an ast_channel, etc, so looking at code would be much faster in my opinion. |
| 01:38.04 | Corydon76-dig | seanbright: shoot |
| 01:38.45 | seanbright | Corydon76-dig: well after actually thinking about it for 10 seconds, i think i understand now. |
| 01:39.02 | seanbright | Corydon76-dig: was going to ask about the locking on the table list |
| 01:39.16 | Corydon76-dig | rwlocks |
| 01:39.21 | seanbright | right |
| 01:39.32 | seanbright | but i was wondering why locking was necessary |
| 01:39.47 | seanbright | but realized that odbc_log could get trampled on if reload was called |
| 01:40.12 | seanbright | (without the locks, that is) |
| 01:40.41 | Corydon76-dig | or unload |
| 01:40.44 | seanbright | right |
| 01:41.15 | seanbright | i'm trying to pull the "multiple sinks" concept up to the cdr infrastructure |
| 01:41.19 | seanbright | so that all the modules can use it |
| 01:41.43 | Corydon76-dig | Why? |
| 01:42.01 | seanbright | its part of the nolosscdr thing |
| 01:42.04 | Corydon76-dig | The reason to do it from ODBC is that it could address multiple types of databases |
| 01:42.07 | russellb | so that there can be per-sink CDR queues |
| 01:42.24 | Corydon76-dig | Ah... |
| 01:42.27 | russellb | so that if one sink is down, the CDRs for that sink can stay queued up ... |
| 01:42.41 | russellb | i.e. magic |
| 01:42.52 | Corydon76-dig | Well, adaptive doesn't do that currently |
| 01:42.57 | seanbright | right |
| 01:43.02 | seanbright | but it does the multi-sink thing |
| 01:43.10 | seanbright | baby steps |
| 01:43.11 | seanbright | :) |
| 01:43.16 | Corydon76-dig | Heh |
| 01:43.38 | Corydon76-dig | Isn't this what CDRfix5 was supposed to do? |
| 01:43.49 | Corydon76-dig | Or no, it's NoLossCDR |
| 01:43.52 | russellb | nope, that branch was just modifying how and what CDRs were generated |
| 01:43.57 | russellb | well, not "just" |
| 01:44.08 | russellb | it was/is a non-trivial effort :) |
| 01:44.11 | russellb | just different |
| 01:44.17 | Corydon76-dig | Right |
| 01:44.39 | seanbright | juggie pulled out the cdr batch stuff too |
| 01:44.56 | seanbright | a.k.a. removed it |
| 01:45.01 | seanbright | which i'm not sure was the right thing to do |
| 01:45.15 | russellb | well. the same problems can be addressed with your code |
| 01:45.17 | Corydon76-dig | I thought that was the whole point of the branch |
| 01:45.37 | russellb | as long as the actual logging is deferred to another thread, the batch mode is no longer useful |
| 01:45.43 | russellb | and to do what you're doing, that will be required |
| 01:45.51 | seanbright | i see |
| 01:45.56 | russellb | well, maybe it's not required |
| 01:46.00 | russellb | but i'm saying it's required :) |
| 01:46.05 | seanbright | so the batching was "bad" because it held up the primary logging thread? |
| 01:46.10 | russellb | you need to have CDR consuming thread(s) |
| 01:46.15 | seanbright | keep in mind i wasn't around when the branch was originally created |
| 01:46.21 | seanbright | so i'm missing some history |
| 01:46.27 | russellb | no, non-batching was bad because it could block channel destruction and such |
| 01:46.45 | seanbright | ahh |
| 01:46.47 | Corydon76-dig | So I'm thinking that the CDR engines should return one of three values... OK, FAIL, and DEFER |
| 01:47.11 | russellb | FAIL as in, can't post it, and AFAIK, never will be able to post any other CDRs? |
| 01:47.27 | russellb | in most cases, i would hope it would be OK or DEFER |
| 01:47.36 | Corydon76-dig | No, this record has a fatal problem with it, and it will not succeed, so don't try it again |
| 01:47.44 | seanbright | well we had that before |
| 01:47.45 | russellb | ah, this record ... hmm |
| 01:48.23 | Corydon76-dig | russellb: maybe even there's a filter on the CDR that tells it not to post |
| 01:48.24 | seanbright | but i remember a conversation in here where you told juggie that was bad |
| 01:48.30 | seanbright | or wrong or whatever |
| 01:48.36 | Corydon76-dig | adaptive has a filter like that |
| 01:49.06 | seanbright | it wasn't defer though, it was TEMPFAILURE or something |
| 01:49.07 | bkruse | In the default modules.conf for 1.4, it says "If you want, load the GTK console right away." then it has noload => pbx_gtkconsole.so, that is not right is it? |
| 01:49.13 | Corydon76-dig | A column must match a certain value or the record will not be posted |
| 01:49.17 | russellb | DEFER/TEMFAILURE, same thing |
| 01:49.26 | Corydon76-dig | Right |
| 01:49.30 | russellb | bkruse: bad wording |
| 01:49.34 | bkruse | Is it just showing that example as a noload/load |
| 01:49.36 | bkruse | russellb: gotcha |
| 01:49.44 | russellb | Corydon76-dig: ah, ok, that makes sense ... that's a use case for FAIL |
| 01:50.05 | Corydon76-dig | So then if it defers, the main CDR code keeps multiple queues |
| 01:50.23 | russellb | seanbright: it may be useful to write a design document on this to make sure we're all on the same page :) |
| 01:50.28 | russellb | Corydon76-dig: yeah |
| 01:50.32 | russellb | it sounds like we are, but it wouldn't hurt |
| 01:50.46 | Corydon76-dig | Maybe each backend has a thread that queries the queue for it, or else the core retries the CDR after a certain delay |
| 01:50.48 | russellb | that design documentation could be written as a doxygen page |
| 01:51.04 | russellb | Corydon76-dig: hmm ... that's added complexity to the CDR modules |
| 01:51.16 | russellb | Corydon76-dig: i'm thinking a thread pool in the CDR core that services the queues |
| 01:51.31 | Corydon76-dig | russellb: that's doable |
| 01:51.35 | russellb | thread per sink, even ... |
| 01:51.42 | seanbright | that's what we have today |
| 01:51.45 | seanbright | thread per sink |
| 01:51.55 | russellb | that's the most straight forward way, yeah |
| 01:52.01 | Corydon76-dig | Or maybe a single queue and it holds a callback to the backend that deferred the CDR |
| 01:52.17 | Corydon76-dig | and with a single queue, you've got fair queueing |
| 01:52.30 | seanbright | so a deferred cdr is one that will never be posted to a given sink? |
| 01:52.45 | russellb | seanbright: deferred is one that must try again |
| 01:52.51 | Corydon76-dig | seanbright: no, defer is "hasn't succeeded YET" |
| 01:53.05 | russellb | i'm thinking multiple queues will make the code more straight forward |
| 01:53.13 | russellb | and also better lends itself to concurrency |
| 01:53.20 | Corydon76-dig | seanbright: FAIL is "don't try again" |
| 01:53.47 | russellb | SMP systems can have multiple sinks being serviced simultaneously |
| 01:53.58 | Corydon76-dig | russellb: then you're talking a thread for each backend, to ensure fairness |
| 01:53.59 | seanbright | Corydon76-dig: in what scenario would a record be deferred? |
| 01:53.59 | russellb | where as with a single queue, you have some queue lock that prevents that from happening |
| 01:54.08 | russellb | basically, yeah |
| 01:54.11 | russellb | or a thread per sink anyway |
| 01:54.16 | Corydon76-dig | seanbright: the database isn't responding or timed out |
| 01:54.27 | seanbright | in the current implementation, we have a cdr queue per sink and a posting thread per queue |
| 01:54.40 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 01:54.42 | Corydon76-dig | seanbright: or the database has a specific error that tells it to retry |
| 01:54.44 | seanbright | Corydon76-dig: we had that in at one point but you suggested it should be removed |
| 01:55.20 | seanbright | Corydon76-dig: because how could you distinguish between a "temporary" failure and a hard one? |
| 01:55.22 | Corydon76-dig | seanbright: no, I suggested that the record eventually timeout after a certain number of retries |
| 01:55.28 | seanbright | Corydon76-dig: ah |
| 01:55.42 | Corydon76-dig | Juggie wanted to retry forever |
| 01:56.00 | russellb | it may be worth making that configurable |
| 01:56.06 | Corydon76-dig | I agree |
| 01:56.07 | russellb | there are some people that would rather let it try forever |
| 01:56.12 | seanbright | this got a lot more complicated all of a sudden. |
| 01:56.14 | seanbright | ;) |
| 01:56.23 | seanbright | Juggie: ping |
| 01:56.24 | seanbright | heh |
| 01:56.28 | Corydon76-dig | We could probably also go with some TCP logic for the timeout... each time, the retry period doubles |
| 01:56.30 | russellb | seanbright: heh ... that's why we should document the project goals :) |
| 01:56.43 | russellb | Corydon76-dig: good idea... |
| 01:56.50 | russellb | even random backoff :) |
| 01:56.58 | Corydon76-dig | Right |
| 01:57.08 | russellb | like ethernet does with collisions |
| 01:57.57 | Corydon76-dig | seanbright: baby steps |
| 01:58.00 | seanbright | heh |
| 01:58.01 | russellb | lol |
| 01:58.18 | seanbright | my head explodes in all-grows-up steps ;) |
| 01:58.31 | Corydon76-dig | M12082 |
| 01:58.32 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/DatabaseSupport 0012082: Dial plan pattern matching not working from odbc tables reported by kactus http://bugs.digium.com/view.php?id=12082 |
| 01:58.39 | Corydon76-dig | Another person failed to read the config file |
| 01:59.28 | seanbright | he's making a habit of that |
| 02:00.03 | russellb | ok, time to go home ... |
| 02:00.11 | Corydon76-dig | Earlier today, he reopened a bug after I had fixed it... apparently thinking that the beta was going to change... |
| 02:00.12 | seanbright | its only 9pm |
| 02:00.17 | seanbright | banker's hours? |
| 02:00.17 | Corydon76-dig | -2 karma for that |
| 02:00.19 | russellb | Corydon76-dig: lol |
| 02:00.22 | russellb | nice. |
| 02:00.47 | russellb | seanbright: i know, i've only been here for 10 hours :( |
| 02:00.58 | seanbright | russellb: you're fired |
| 02:01.00 | russellb | with no break |
| 02:01.13 | seanbright | russellb: take up smoking |
| 02:01.17 | russellb | ha |
| 02:01.18 | russellb | i'll pass |
| 02:01.18 | seanbright | russellb: all the cool kids are doing it |
| 02:01.20 | seanbright | <-- |
| 02:01.26 | russellb | anyway, i'm sure i'll be back on in like an hour |
| 02:01.27 | russellb | heh |
| 02:01.27 | Corydon76-dig | seanbright: even worse, he's getting married |
| 02:01.29 | seanbright | see ya |
| 02:01.36 | russellb | 5 weeks and 3 days! |
| 02:01.48 | seanbright | may god have mercy on his soul |
| 02:01.59 | seanbright | what is he? 24? |
| 02:02.03 | seanbright | that's too young for such things |
| 02:02.06 | Corydon76-dig | Who knows, maybe one day I'll get married |
| 02:02.15 | jpeeler | he's 23 |
| 02:02.21 | Corydon76-dig | and have kids |
| 02:02.25 | jpeeler | and i too have been wondering how he is going to handle things |
| 02:02.37 | Qwell | I was like 21.. |
| 02:02.38 | seanbright | Corydon76-dig: move to vermont |
| 02:02.53 | Corydon76-dig | seanbright: I was actually thinking about marrying a woman |
| 02:02.58 | seanbright | really? |
| 02:03.05 | seanbright | huh |
| 02:03.08 | seanbright | well then stay right where you are |
| 02:03.09 | jpeeler | Qwell, not saying he was too young, just that it's going to be a big transition i think |
| 02:03.10 | seanbright | :) |
| 02:03.13 | Qwell | ahh |
| 02:03.33 | lmadsen | I don't even have a g/f! |
| 02:03.36 | lmadsen | pffft marriage |
| 02:03.37 | Corydon76-dig | jpeeler: more for her, I think |
| 02:03.48 | Corydon76-dig | lmadsen: I don't either |
| 02:03.54 | jpeeler | Corydon76-dig, heh |
| 02:03.55 | Corydon76-dig | Go go online dating sites |
| 02:03.59 | lmadsen | pffft |
| 02:04.04 | lmadsen | go go ex-g/fs |
| 02:04.07 | seanbright | heh |
| 02:04.15 | seanbright | i'm gf-less as well |
| 02:04.27 | lmadsen | although the ex-g/f bailed on me, so I guess I should call the girl on the 13th floor |
| 02:04.27 | Corydon76-dig | jpeeler: you have an SO we haven't heard about yet? |
| 02:04.29 | seanbright | and i'm totally ok with that |
| 02:04.38 | jpeeler | SO? |
| 02:04.38 | lmadsen | seanbright: you and me both |
| 02:04.42 | lmadsen | significant other |
| 02:04.47 | Corydon76-dig | what he said |
| 02:04.53 | jpeeler | ah, yes i do |
| 02:05.14 | Corydon76-dig | It's a nice way of saying it without assuming anything about your sexual orientation |
| 02:05.18 | jpeeler | she actually just visited about two weeks ago |
| 02:05.22 | jpeeler | i see |
| 02:05.26 | jpeeler | well see above |
| 02:05.30 | lmadsen | Corydon76-dig: or your commitment level :) |
| 02:05.30 | Corydon76-dig | Heh |
| 02:05.38 | lmadsen | just means they are first in line :) |
| 02:05.40 | Corydon76-dig | lmadsen: that, too |
| 02:06.07 | Corydon76-dig | jpeeler: what does she think of HSV? |
| 02:06.59 | jpeeler | she liked it a lot actually |
| 02:07.17 | Corydon76-dig | Unlike Atlanta, HSV actually has a source of water |
| 02:08.08 | Corydon76-dig | We seem to be about to fight the War of Georgian Aggression |
| 02:09.04 | Corydon76-dig | (GA lawmakers want to move the TN border north, so they can sink a pipe into the Tennessee River.) |
| 02:10.37 | Corydon76-dig | because Georgia likes building cities without a clear source of water... |
| 02:11.01 | seanbright | well there's the atlantic |
| 02:11.04 | seanbright | ;) |
| 02:11.17 | seanbright | water reclamation |
| 02:13.02 | Corydon76-dig | Actually, if they just drink the salt water, that should solve the problem of overpopulated cities... |
| 02:13.14 | seanbright | there you go |
| 02:13.16 | seanbright | its a win-win |
| 02:13.44 | Corydon76-dig | and then we can feed their brined corpses to Ireland for food |
| 02:14.10 | *** join/#asterisk-dev anthm (n=anthm@68-31-195-6.area4.spcsdns.net) |
| 02:14.10 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 02:14.15 | seanbright | its the circle of life |
| 02:14.19 | Corydon76-dig | Jonathan Swift would approve |
| 02:14.41 | lmadsen | lol |
| 02:15.32 | Corydon76-dig | and everybody who remembers English literature is giggling |
| 02:17.54 | jpeeler | are there any other places that callerid information is configured other than zapata.conf? |
| 02:29.18 | Corydon76-dig | jpeeler: for Zaptel channels, no, unless it's reset via the dialplan |
| 02:30.05 | jpeeler | this might be a stupid question, but tdm cards do support caller id right? |
| 02:30.21 | Qwell | if your telco sends it |
| 02:30.38 | jpeeler | it certainly does |
| 02:31.53 | jpeeler | i had an old box running 1.4.0 with another card and it was working |
| 02:32.36 | Qwell | callerid=asreceived in...one of those configs |
| 02:32.47 | file | die blender die! |
| 02:34.06 | jpeeler | yeah that's in zapata.conf and is set |
| 02:39.52 | seanbright | here's a zaptel question |
| 02:40.53 | seanbright | you know how with a pri, when you get dnis, it drops into the specified context at the dnis' extension? |
| 02:41.48 | seanbright | so if you receive 5555 for dnis, and you have a 5555 exten in the from-pstn context (for example) it will go to it? |
| 02:42.33 | seanbright | it would be nice if you could set up extens for tdm to drop into by default |
| 02:42.44 | seanbright | instead of having to match on _X. |
| 02:43.28 | seanbright | does that make any sense whatsoever? |
| 02:45.46 | *** join/#asterisk-dev jameswf-home (n=james@mobile-166-214-039-059.mycingular.net) |
| 02:51.59 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:51.59 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:01.45 | Corydon76-dig | seanbright: it drops into "s" by default, because TDM doesn't send any digits |
| 03:02.09 | Corydon76-dig | only PRI sends digits |
| 03:02.23 | JT | POTS you mean? |
| 03:02.43 | seanbright | Corydon76-dig: right, but it would be nice if you could define a default exten for the TDM channels in zapata.conf, for example |
| 03:03.12 | Corydon76-dig | JT: T1 CAS is the same way |
| 03:03.17 | JT | PRI is TDM |
| 03:03.25 | JT | as is T! CAS |
| 03:03.27 | JT | T1 |
| 03:03.37 | Corydon76-dig | JT: PRI is one layer above TDM |
| 03:03.47 | JT | it is still a TDM service |
| 03:04.01 | JT | the only difference is a timeslot is reserved for a messaging channel |
| 03:04.05 | Corydon76-dig | That's like calling a web server an Ethernet service |
| 03:04.09 | JT | hardly |
| 03:04.15 | JT | look at how it's structured |
| 03:04.17 | JT | telecomms 101 |
| 03:04.30 | JT | PRI circuits definitely use TDM |
| 03:04.33 | Corydon76-dig | JT: and a web server typically runs on Ethernet |
| 03:05.16 | Corydon76-dig | When I refer to TDM, I refer to the fact that you are directly interacting with that layer |
| 03:05.16 | JT | PRI is no more or less TDM than CAS |
| 03:05.35 | Corydon76-dig | With PRI, you're interacting with one layer above TDM |
| 03:05.39 | JT | you are directly interfacing to the layer though, even with PRI |
| 03:05.40 | seanbright | ok... i just meant fxo ports |
| 03:05.42 | JT | err |
| 03:05.46 | JT | it's on the same level |
| 03:05.49 | JT | same timeslots |
| 03:05.56 | Corydon76-dig | JT: the signalling is one layer above |
| 03:06.16 | JT | but it actually occurs just in a single timeslot |
| 03:06.21 | Corydon76-dig | You are not bit-fiddling with PRI |
| 03:07.06 | Corydon76-dig | Just like on a web server, you're interacting on the TCP level and while yes, technically, it's all on Ethernet, you aren't directly interacting with that layer |
| 03:07.19 | JT | ask anyone in telecomms what TDM is, i'm pretty sure they'll tell you that both CAS and PRI service classify as TDM services |
| 03:07.34 | JT | but pri isn't encapsulated in packets |
| 03:07.37 | Corydon76-dig | And a web service is an Ethernet service |
| 03:07.40 | JT | ... |
| 03:07.56 | JT | a web service does not have to run on ethernet |
| 03:08.01 | JT | it's an IP service |
| 03:08.07 | Corydon76-dig | JT: in any case, this is a pointless argument |
| 03:08.41 | seanbright | i'll declare myself the loser and we can move on |
| 03:08.43 | seanbright | heh |
| 03:09.01 | JT | either way, PRI are recognised by telco people as a TDM service, as is anything that involves the use of time division multiplexing |
| 03:09.31 | Corydon76-dig | Regardless you STILL cannot get DID on a non-PRI signalled line, which was the point |
| 03:09.50 | Corydon76-dig | unless you use E&M |
| 03:10.27 | JT | right |
| 03:10.36 | JT | unless they use a very dodgy method like dtmf ;) |
| 03:10.39 | Corydon76-dig | seanbright: back to your question |
| 03:10.44 | seanbright | heh |
| 03:10.49 | Corydon76-dig | What was your question? |
| 03:10.54 | seanbright | haha |
| 03:11.05 | seanbright | ok, imagine if you will |
| 03:11.15 | seanbright | i have a t1 pri |
| 03:11.21 | seanbright | 50 DIDs |
| 03:11.40 | seanbright | then 6... analog lines... |
| 03:12.02 | seanbright | fxs signalling |
| 03:12.06 | Corydon76-dig | You can hack it by dropping each of the POTS lines into a separate context, then at the s,1 extension, Goto the DID that you want in the general dialplan |
| 03:12.16 | seanbright | ah |
| 03:12.22 | seanbright | that's a good plan |
| 03:12.50 | Corydon76-dig | Just remember that with PRI, you can send early audio, but with POTS, you need to Answer the line first |
| 03:13.14 | seanbright | yeah |
| 03:13.43 | Corydon76-dig | So they will behave in potentially incompatible ways |
| 03:13.46 | seanbright | right now i just drop all the pots calls into the s extension and goto a default exten in a common context |
| 03:14.04 | Corydon76-dig | Echo is also potentially worse on those analog lines |
| 03:14.16 | seanbright | so that my local lines and 1 of my pri dids go to the same ivr without a lot of extra work |
| 03:15.14 | seanbright | we only use the analog lines for toll-free outbounds and local inbounds |
| 03:15.34 | seanbright | so very little, in other words. |
| 03:15.46 | Corydon76-dig | Interesting |
| 03:15.50 | Corydon76-dig | Not local outbound? |
| 03:16.42 | seanbright | no |
| 03:16.42 | seanbright | we are a sales center |
| 03:16.48 | seanbright | and operate a bunch of different brands |
| 03:16.49 | Corydon76-dig | or 911? |
| 03:17.02 | seanbright | 911 uses analog, yes. |
| 03:17.28 | seanbright | but because our CRM integration is lacking, we set our caller id on all outbound calls to our local number |
| 03:17.35 | seanbright | its ugly as hell |
| 03:18.10 | seanbright | long story short, we need to minimize the use of the analogs for outbound calls |
| 03:18.47 | seanbright | but that's a different issue |
| 03:18.54 | seanbright | anyway |
| 03:18.59 | seanbright | thanks for the context idea |
| 03:19.22 | seanbright | gotta be up at 5. night. |
| 03:19.41 | Corydon76-dig | 'night |
| 03:25.09 | jpeeler | how is caller id information transmitted over the wire? |
| 03:25.54 | JT | on pots? |
| 03:26.14 | ecto | FSK tones, right? |
| 03:26.38 | jpeeler | yes on pots |
| 03:26.39 | Corydon76-dig | 300 Baud signal between the first and second rings |
| 03:27.05 | JT | jpeeler: depends on which scheme |
| 03:27.10 | JT | jpeeler: there's at least 3 |
| 03:27.13 | JT | one is fsk |
| 03:27.16 | JT | there's also dtmf |
| 03:27.28 | Corydon76-dig | DTMF before the first ring |
| 03:30.29 | jpeeler | does asterisk have the capability to display raw signal output? |
| 03:30.38 | jpeeler | it seems the most information asterisk gives is the ring pattern information |
| 03:33.55 | russellb | display it where? |
| 03:33.58 | ecto | jpeeler: this is on a zap channel? |
| 03:34.04 | jpeeler | yes |
| 03:34.10 | jpeeler | just on the console |
| 03:34.13 | russellb | for zap channels, the best thing to do is use ztmonitor |
| 03:34.14 | ecto | use ztmonitor to record the sound |
| 03:34.18 | russellb | to capture the raw audio |
| 03:34.28 | russellb | and then you can analyze it with audacity or your tool of choice |
| 03:34.33 | russellb | audacity <3 |
| 03:34.43 | ecto | audacity is not audacious |
| 03:34.59 | ecto | but audacity is the right tool to use in this instance |
| 03:35.12 | jpeeler | i might be going overboard, sounds like i'll be doing what you guys were doing with zaptel debugging earlier |
| 03:35.27 | jpeeler | i just wanted to make sure the caller id information is actually arriving |
| 03:35.44 | russellb | let's back up a second :) |
| 03:35.48 | russellb | what are you trying to debug? |
| 03:36.17 | russellb | or are you just curious ... |
| 03:36.47 | russellb | if you're not getting callerid ... make sure you have callerid=asreceived set for your FXO port |
| 03:36.50 | russellb | in zapata.conf |
| 03:36.56 | jpeeler | i'm just trying to verify how far the caller id information gets because i don't see any info on the console |
| 03:37.01 | jpeeler | yeah i did that |
| 03:37.09 | russellb | ah, so you're not getting it? |
| 03:37.22 | jpeeler | is the asreceived parameter required for both channels? |
| 03:37.26 | russellb | then yeah, i'd use ztmonitor ... verify if you get it on the wire |
| 03:37.38 | russellb | nope ... just the fxo port (fxs_ks signalling channel) |
| 03:37.50 | ecto | another option is to use zapbarge to listen to the channel and see if you're hearing the tones... |
| 03:38.14 | jpeeler | well i'm pretty sure it's on the wire though, i had an old asterisk installation setup and the caller id info was present |
| 03:38.16 | ecto | I did that with a customer not too long ago |
| 03:38.21 | russellb | hm, yeah, i guess zapbarge would get the audio before asterisk mutes the FSK |
| 03:38.43 | *** join/#asterisk-dev ricko73 (n=dhartman@wilug/newlug/ricko73) |
| 03:39.34 | russellb | i still like ztmonitor, though, so you can save it :) |
| 03:39.54 | ecto | right |
| 03:47.07 | jpeeler | if i followed the last ztmonitor example, i would need to load the streamrx.raw? |
| 03:48.29 | ecto | right |
| 03:48.45 | ecto | and use sox to convert it to wav (ztmonitor will tell you the exact sox command to use) |
| 03:49.32 | jpeeler | it looks like audacity handles raw audio, can't i just import it? |
| 03:49.41 | ecto | jpeeler: yeah |
| 03:49.55 | ecto | I haven't used audacity in ages, so I couldn't remember that |
| 03:50.48 | jpeeler | ok so ztmonitor has a normal stream and a preecho stream |
| 03:51.00 | jpeeler | but both rx streams look identical |
| 03:51.37 | ecto | are you echo canceling the stream? |
| 03:51.47 | ecto | or, if you don't have echo, they'll look the same |
| 03:52.27 | jpeeler | i do have software echo cancellation turned on |
| 03:53.06 | jpeeler | ok, so how do i determine if these signals are actually valid caller id info? |
| 03:56.31 | ecto | you'll have to listen to it... if it's North American CID, you'll hear the FSK tones (sounds kinda like a fax machine) between the first and second rings |
| 03:57.31 | Qwell | I actually have a presentation on CID on the wiki |
| 03:57.35 | Qwell | jpeeler: got vpn access? |
| 03:57.48 | jpeeler | Qwell, yes |
| 03:58.24 | Qwell | see msg :) |
| 03:58.39 | russellb | jpeeler: another way to test caller id ... plug in an analog phone that supports caller id and call it |
| 03:58.46 | jpeeler | ecto, i don't hear the rings (am i supposed to?) but i do hear something before the call starts |
| 03:58.48 | russellb | a much more boring hack of a test ... |
| 03:59.13 | jpeeler | russellb, true, but i don't have any phones! and as i said earlier i am pretty sure caller id is working since i tried it last week with my old asterisk install |
| 03:59.17 | Qwell | jpeeler: it's a really quick burst.. you'll have to slow it down |
| 03:59.26 | ecto | jpeeler: oh, yeah, that's right... zapbarge lets you hear the rings |
| 03:59.33 | russellb | and yeah, i guess you don't hear the rings that way |
| 03:59.37 | russellb | that would be expected |
| 04:03.48 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 04:04.08 | russellb | jpeeler: you know, i bet super target has a cheap callerid capable phone ;) |
| 04:04.21 | russellb | and that's like ... rock throwing distance away |
| 04:04.31 | file | throwing rocks is not nice. |
| 04:04.40 | jpeeler | heh, i was looking online for a decent one yesterday |
| 04:04.44 | jpeeler | i'm quite particular |
| 04:04.48 | jpeeler | at least with phones |
| 04:05.02 | jpeeler | after all i'm waiting 6 months just to wait for the right cell phones to come out! |
| 04:05.24 | jpeeler | anyway, is there something simple i could be overlooking that would cause the caller id info not to get displayed? |
| 04:05.43 | russellb | well. how are you trying to display it again? |
| 04:05.48 | *** part/#asterisk-dev ricko73 (n=dhartman@wilug/newlug/ricko73) |
| 04:06.00 | russellb | NoOp(CallerID is ${CALLERID(all)}) ? |
| 04:06.12 | jpeeler | yep that's what i have... |
| 04:07.35 | russellb | if you have the callerid option set correctly, then no |
| 04:07.38 | russellb | i can't think of anything else |
| 04:07.42 | russellb | aside from kicking it |
| 04:07.47 | russellb | and testing with an analog phone |
| 04:10.34 | jpeeler | :( well i'm not going to rest until i have it working |
| 04:10.41 | jpeeler | but that's probably enough for tonight |
| 04:11.55 | russellb | you just contradicted yourself :) |
| 04:12.20 | russellb | go buy yourself a $10 phone :-p |
| 04:12.38 | jpeeler | fine i will tomorrow on the way home from work |
| 04:12.52 | file | $10? little pricey |
| 04:12.54 | jpeeler | you just don't believe i have caller id... |
| 04:13.20 | russellb | it doesn't hurt to have a bunch of phones, anyway :) |
| 04:13.31 | russellb | but it's the logical sanity check in this situation |
| 04:16.43 | jpeeler | i thought about just borrowing the one from work, but i don't think it has caller id |
| 04:17.16 | ecto | I was looking over the janitor list--I know, the website is still horribly out of date--but the strcat, strncat, etc. one still looks valid... |
| 04:17.32 | ecto | a quick count shows at least 344 instances of strncat in trunk... |
| 04:17.50 | russellb | ooh |
| 04:17.53 | ecto | not even sure if that's a goal anymore though |
| 04:17.55 | russellb | then yeah |
| 04:17.57 | russellb | yeah, it is |
| 04:18.02 | russellb | some places are harder to convert than others |
| 04:18.12 | Corydon76-dig | Eh? |
| 04:18.13 | russellb | also, that web site shouldn't be there anymore |
| 04:18.21 | russellb | it should be a link to svn view, isn't it? |
| 04:18.30 | ecto | It wasn't last I tried... |
| 04:18.31 | russellb | Corydon76-dig: converting string manipulation weirdness to ast_str |
| 04:18.36 | russellb | o.O |
| 04:18.37 | Corydon76-dig | Ah... |
| 04:18.55 | russellb | avoiding buffer size passing errors, mainly |
| 04:19.08 | russellb | because ast_str tracks that internally |
| 04:19.19 | russellb | and can resize buffers, too, for non-stack allocated buffers |
| 04:21.26 | russellb | C string management is such a joy ... |
| 04:21.31 | russellb | is that an oxymoron? |
| 04:21.51 | russellb | you know ... sometimes I love C, and sometimes it makes me bitter |
| 04:22.29 | ecto | sounds like any programming language, really |
| 04:22.42 | russellb | probably so |
| 04:22.57 | ecto | I dunno, C# is pretty neat |
| 04:24.27 | lmadsen | Corydon76-dig: hey... I'm still working with another client, but I thought I'd let you know that my only break today was 9:30pm-11:00pm, so I didn't get a chance to call Oz |
| 04:24.33 | lmadsen | I'll be doing that first thing tomorrow morning though |
| 04:24.54 | Corydon76-dig | Okay, I won't be around tomorrow morning, though |
| 04:25.22 | lmadsen | oh ok, well I'll at least try and get all the stuff installed and get some debugging information |
| 04:25.44 | lmadsen | I have a weekly meeting tomorrow morning, so that is going to kill off an hour, and I might not actually get up before the meeting anyways |
| 04:25.59 | lmadsen | today has been a LOOOOOOOOOOOONG day |
| 04:26.27 | lmadsen | up at 7:30am, on-site at a meeting until 1pm, then working with one client until 9:30, then another one tonight from 11:00pm - 1:00am... |
| 04:26.37 | lmadsen | although that's probably normal for you guys :) |
| 04:28.11 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-32-245.sttlwa.dsl-w.verizon.net) |
| 04:28.40 | philipp64 | jmls: howdy. |
| 05:01.52 | *** join/#asterisk-dev jeffg (i=tQ1lCrFb@pdpc/supporter/active/jeffg) |
| 05:06.12 | philipp64 | I missed the conversation on this a few days ago, but Julian brought up some issues with cross-compiling Curl w/ Asterisk. |
| 05:07.29 | philipp64 | I'm trying to help out with that, and from what I can tell, Asterisk's "configure" file will run curl-config locally, even if $cross_compiling is "yes". |
| 05:09.20 | philipp64 | There doesn't seem to be an easy way (that I can tell, anyway, but I'm no autoconf expert) Asterisk to use a given path for curl libraries when cross-compiling. |
| 05:09.31 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 05:45.00 | philipp64 | Is this a known issue when cross-compiling? |
| 05:55.44 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 05:55.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:06.55 | *** join/#asterisk-dev jameswf-home (n=james@mobile-166-214-210-137.mycingular.net) |
| 06:35.04 | lmadsen | holy crap... that's it... work is done... I'm off to bed! :) |
| 06:40.53 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-117347.home.otenet.gr) |
| 07:22.08 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 07:33.35 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583194.dsl.bell.ca) |
| 07:42.19 | jmls | morning all |
| 07:43.40 | jmls | philipp64: hey! |
| 07:44.19 | jmls | jsmith-away: ping |
| 07:45.54 | philipp64 | jmls: pong |
| 07:46.11 | jmls | you up early or late ? ;) |
| 07:46.21 | jmls | it's 7:45 am here |
| 07:53.58 | philipp64 | it's midnight. |
| 08:09.27 | jmls | yikes |
| 08:09.27 | jmls | school run :( |
| 08:09.27 | *** join/#asterisk-dev jsmith-away (n=jsmith@72.21.36.138) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-117347.home.otenet.gr) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev BBHoss (n=hoss@c-71-207-173-38.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev phearless (n=phear@host217-34-75-65.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev _Vile (n=vile@208.100.152.234) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 08:09.27 | *** join/#asterisk-dev MuffinMan (n=muffins@neutrino.joshua-colp.com) [NETSPLIT VICTIM] |
| 08:09.27 | *** mode/#asterisk-dev [+o jsmith-away] by irc.freenode.net |
| 08:10.06 | jmls | hey! jsmith-away ! |
| 08:10.06 | jmls | any thoughts on why single queue member works for you ? |
| 08:10.06 | jmls | gotta run. brb |
| 08:21.55 | *** join/#asterisk-dev Deeewayne (n=dwayne@216.207.245.1) |
| 08:21.55 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 08:26.15 | *** join/#asterisk-dev IgorG (n=IgorG@host-195-162-53-193.pppoe.omsknet.ru) |
| 08:35.39 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 08:43.57 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 08:43.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:27.04 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 09:27.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:38.04 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 09:38.04 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 09:38.04 | *** mode/#asterisk-dev [+o tzafrir_laptop] by irc.freenode.net |
| 09:38.12 | *** join/#asterisk-dev jameswf-home (n=james@mobile-166-214-210-137.mycingular.net) |
| 09:41.51 | awk | does anyone have a patch for 1.4.17 to fix this... |
| 09:42.01 | awk | http://bugs.digium.com/view.php?id=11790 |
| 09:42.09 | awk | I don't want to upgrade to 1.4.18 our version is stable |
| 09:56.02 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 09:56.08 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:56.21 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:13.23 | jmls | jsmith: found an interesting wrinkle - I was able to get "single member" to work ... |
| 10:14.22 | jmls | you have to set autofill=no ... |
| 10:18.56 | jmls | if you were running on the latest 1.4 svn, and 1.6 is in beta4, would you have the confidence to run 1.6 instead of 1.4 ? |
| 10:19.19 | jmls | i.e. should I do all of my stress-testing on 1.6 instead of 1.4 with a view to moving to 1.6 asap |
| 10:21.11 | jmls | (I am making thousands of zap calls in and out via a loop sippd into a queue, using curl and jabber. Also, I am making thousands of calls outbound via an automated dialler). All calls are mixmonitored as well. So it is a fairly intensive test |
| 10:36.51 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:05.31 | *** join/#asterisk-dev mbranca (i=daemon@mi-gw1.voismart.net) |
| 11:20.36 | agx | tdm400p hell... "Feb 28 12:18:36 DEBUG[31564] dsp.c: busy detector: avgtone of 220 not close enough to desired 200" ... it should be 200,200 but instead looks like 220,180 or 180,220, i suspect i've to recompile using BUSY_PERCENT bigger then 10 ? |
| 12:02.46 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 12:21.22 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:57.47 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 13:00.01 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 13:00.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:20.13 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 13:21.30 | *** join/#asterisk-dev jameswf-home (n=james@mobile-166-214-129-030.mycingular.net) |
| 13:44.58 | *** join/#asterisk-dev jeffg (i=owqUxBoV@pdpc/supporter/active/jeffg) |
| 13:54.05 | *** join/#asterisk-dev jeffg_ (i=AocMZCCC@pdpc/supporter/active/jeffg) |
| 14:19.12 | *** join/#asterisk-dev kannan (n=kann@123.201.60.116) |
| 14:20.23 | *** join/#asterisk-dev slavon_net (n=slavon@slavon.bigtelecom.ru) |
| 14:22.15 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 14:36.37 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 14:39.47 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.111.94) |
| 14:42.35 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:42.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.37 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:32.37 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:39.37 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:41.14 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 15:46.41 | joetester | aaaaaah! zaptel 1.4.9.1 locks up my machine! |
| 15:50.39 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 16:00.14 | Kobaz | i've been using zaptel 1.4.5.1 for a while now since newer ones have been giving some trouble |
| 16:01.15 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 16:01.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:01.59 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:01.59 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:05.35 | tzafrir | joetester, what hardware do you have? |
| 16:14.04 | joetester | It's a te212p |
| 16:14.09 | joetester | the card |
| 16:16.18 | joetester | otherwise it's a pretty standard machine... worked perfect with 1.4.4, since 1.4.9.1 yesterday it's been locking up like crazy, every 10 minutes or so. And not like a linux segfault, like a Windows/DOS crash when it dumped memory and froze up. The keyboard doesn't even respond anymore. |
| 16:16.46 | joetester | I have to manually reset the power switch, so it's really bad. |
| 16:16.51 | Kobaz | do you get anything interesting at all in syslog |
| 16:17.07 | Kobaz | what if you tail the syslog on the main console |
| 16:17.29 | joetester | Let me check... |
| 16:17.30 | Kobaz | or even better use sysctl to bump up the console verbosity |
| 16:19.04 | joetester | syslog is just standard syslog stuff... nothing indicates it ever crashed except the reboot stuff. |
| 16:20.40 | joetester | I'm guessing it's not even able to log stuff. |
| 16:25.24 | joetester | I ran an upgrade of most packages on the machine, I figure it might not have liked some older package. |
| 16:25.51 | joetester | Including kernel, recompiled everything, I'm checking if it changes things. |
| 16:28.08 | Kobaz | mmm |
| 16:28.25 | Kobaz | next step is kdb, heh |
| 16:28.48 | tzafrir | serial console, actually |
| 16:28.59 | Kobaz | when does it lock? |
| 16:29.24 | joetester | Again! |
| 16:29.32 | joetester | zt_tone_init |
| 16:29.45 | Kobaz | if it doesn't lock immediatly on boot, you can tail syslog from the console to check for interestingness |
| 16:30.00 | tzafrir | joetester, what linux distro is it? |
| 16:30.06 | joetester | debian 4.0 stable |
| 16:30.10 | joetester | etch |
| 16:30.17 | tzafrir | also: are you near the console? |
| 16:30.22 | Kobaz | tzafrir: what would a serial console gain you that using a local monitor and keyboard wouldn't? |
| 16:30.46 | tzafrir | get the exact trace, I guess |
| 16:31.27 | Kobaz | but if you look at the console on the box itself, it would be the same |
| 16:31.33 | tzafrir | joetester, if you are, try pressing alt-sysrq-p , and see if you get anything |
| 16:31.38 | Kobaz | yeah |
| 16:31.56 | joetester | Yeah mean while it's crashed? |
| 16:31.59 | Kobaz | but if you get a kernel panic written out to the console right before it locks, it may tell you something |
| 16:32.03 | Kobaz | yeah, the magic sysreq key |
| 16:32.34 | tzafrir | I wonder if it actually crashed, or actually in a deadlock |
| 16:33.34 | tzafrir | joetester, sorry, so you did get a trace |
| 16:33.39 | tzafrir | I missed that |
| 16:33.46 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 16:33.58 | tzafrir | a crash , indeed |
| 16:34.17 | joetester | Not yet, wait up. |
| 16:35.35 | joetester | First time I do alt-sysreq-p.... unfortunately someone rebooted it, I have to wait for another crash, which shouldn't be too long fortunately. |
| 16:36.17 | joetester | alt-sysreq-p yields info in a "similar layout" to what I see on the screen when it crashes. |
| 16:38.40 | joetester | Sorry if I'm all over the place it's really hectic on my side. |
| 16:41.01 | mvanbaak | can imagine that |
| 16:41.46 | joetester | tzafrir, I will do exactly as you say. |
| 16:42.22 | tzafrir | joetester, I missed the fact you already got a trace |
| 16:42.30 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-284196.home.otenet.gr) |
| 16:42.43 | joetester | Crash happened again. I tried to press alt-sysreq-p, nothing happens of course. |
| 16:42.54 | joetester | It's completely frozen solid. |
| 16:44.00 | joetester | I don't fully get a trace, it's not logged it just happens to be seen on the screen, but I can't scroll up or down or anything. |
| 16:44.18 | joetester | Locked up solid like a windows ME machine. |
| 16:45.17 | joetester | Maybe I can capture this over the serial console, is that what you want? |
| 16:48.03 | *** part/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 16:48.34 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:49.49 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 16:49.49 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 16:51.15 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:52.29 | Juggie | Corydon76: ping |
| 17:06.52 | mvanbaak | dont you have to enable something first before the sysrq key works ? |
| 17:07.47 | joetester | mvanbaak: I tried it when the machine was up, and it worked. When it has crashed it doesn't work, just like everything on the keyboard. |
| 17:08.29 | mvanbaak | ah |
| 17:08.30 | mvanbaak | ok |
| 17:15.13 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 17:15.50 | joetester | It's this, I'm an idiot: M12053 |
| 17:15.54 | joetester | M12053 |
| 17:15.55 | MuffinMan | [closed] [Zaptel] General 0012053: Zaptel crashes kernel - zt_init_tone_state reported by foxfire http://bugs.digium.com/view.php?id=12053 |
| 17:31.38 | *** join/#asterisk-dev juanjoc (n=juanjoc@200.69.219.113) |
| 17:44.33 | *** join/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 17:47.10 | jmls | damn. |
| 17:47.18 | jmls | what did I miss ? |
| 17:48.53 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:59.31 | Qwell | I think somebody made chan_sip unhappy |
| 18:00.35 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:00.35 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 18:00.51 | lmadsen | morning all :) |
| 18:00.57 | Qwell | lmadsen: you did it, didn't you? |
| 18:01.09 | lmadsen | sounds like something I'd do |
| 18:01.28 | Qwell | chan_sip is segfaulting on me whenever I make a call O.o |
| 18:01.51 | lmadsen | eep! |
| 18:01.58 | lmadsen | sounds about right |
| 18:03.35 | Qwell | I bet it's because I'm using LOW_MEMORY.. |
| 18:03.54 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-32-245.sttlwa.dsl-w.verizon.net) |
| 18:04.14 | philipp64 | jmls: back. network issues here in the western states. |
| 18:04.34 | philipp64 | the GNI backbone was severely perturbed by the outages in Florida. |
| 18:04.41 | jmls | philipp64: that's normal service over here ;) |
| 18:04.53 | philipp64 | I had seattle => boise traffic going into a blackhole in Miami!!! |
| 18:05.09 | philipp64 | you in Albion? |
| 18:06.15 | philipp64 | anyway, I posted a query yesterday evening about how to get "configure" to use a certain path to CURL_LIB when cross-compiling, but didn't see an answer. |
| 18:06.18 | jmls | nope. UK |
| 18:06.22 | jmls | yeah I saw. |
| 18:07.18 | philipp64 | seems it wants to use the target's curl-config --libs ... which will of course always be the path on the TARGET's root filesystem. but not the host's. |
| 18:09.37 | Juggie | Corydon76: ping |
| 18:10.05 | Qwell | What happens if you ast_strdupa(NULL)? |
| 18:11.38 | putnopvut | Qwell: segfault on strlen |
| 18:11.52 | Qwell | really? |
| 18:12.31 | putnopvut | Qwell: I've been wrong before but the macro calls strlen on the pointer, and I'm almost certain strlen on a NULL pointer will segfault. |
| 18:12.38 | Qwell | interesting |
| 18:12.51 | Qwell | that sounds like a bug in the macro.. but that's sorta beside the initial point |
| 18:13.25 | putnopvut | Why do you ask? |
| 18:13.35 | Qwell | so, executing an application from the dialplan vs from an agi causes the arguments to be different |
| 18:13.44 | Qwell | from dialplan, it's an empty string. from agi, it's NULL |
| 18:14.11 | putnopvut | That's odd. |
| 18:14.13 | Qwell | obviously, ast_strlen_zero will catch either, but... |
| 18:14.33 | Qwell | Pickup() is ast_strdupa()ing the args before the ast_strlen_zerp |
| 18:14.47 | Qwell | so, I wasn't able to reproduce from dialplan - but this guy is using an AGI |
| 18:15.39 | jmls | jbot: hug jsmith-away |
| 18:15.40 | jbot | ACTION hugs jsmith-away |
| 18:16.42 | Qwell | so, what do you guys think about this change in main/pbx.c, pbx_exec() |
| 18:16.44 | Qwell | -res = app->execute(c, data); |
| 18:16.49 | Qwell | +res = app->execute(c, S_OR(data, "")); |
| 18:17.30 | jmls | prevents a segfault ? |
| 18:17.43 | jmls | if data is null ? |
| 18:17.46 | Qwell | well, I could easily fix Pickup() to handle NULL properly |
| 18:17.46 | putnopvut | Qwell: seems reasonable to me. |
| 18:17.54 | Qwell | but yes, that's the theory - protect from future ones |
| 18:18.02 | jmls | Qwell: I agree also |
| 18:18.07 | jmls | aha hah |
| 18:18.15 | putnopvut | Just need to make sure that no applications explicitly check fora NULL data pointer though. |
| 18:18.27 | putnopvut | Make sure they use ast_strlen_zero instead. |
| 18:18.29 | Qwell | putnopvut: none can, or they wouldn't work from dialplan |
| 18:18.31 | jmls | jbot: hug putnopvut |
| 18:18.32 | jbot | ACTION hugs putnopvut tightly until putnopvut turns slightly blue |
| 18:18.35 | Qwell | since dialplan is using empty string |
| 18:18.42 | putnopvut | jmls: :) |
| 18:18.52 | jmls | got a queue problem :) |
| 18:19.05 | putnopvut | jmls: Okay, what's up? |
| 18:19.43 | jmls | You know I was playing with a "single member" in a queue (local channel) which then did dialplan magic to call the "right" agent ? |
| 18:20.11 | jmls | but hit the problem where the calls stacked up until the first was answered ? |
| 18:20.28 | putnopvut | Yeah, that makes sense because the queue only thinks there is one member. |
| 18:21.19 | jmls | weeeeellllll, if you change autofill=no then it sends each call as soon as the previous is answered |
| 18:21.33 | jmls | iow it works as I wanted it to. |
| 18:22.10 | putnopvut | ...I think you may have mistyped a word somewhere because it sounds like autofill = yes and autofill = no did the same thing. |
| 18:22.41 | jmls | no, they didn't do the same thing |
| 18:22.41 | putnopvut | Are you saying that with autofill enabled the calls would stack up until after the first call had completed? |
| 18:23.13 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-32-245.sttlwa.dsl-w.verizon.net) |
| 18:23.14 | jmls | putnopvut: autofill=yes with a single queue member (local/Single@agentq/n) stacks |
| 18:23.25 | jmls | putnopvut: autofill=no with a single queue member (local/Single@agentq/n) does not stack |
| 18:23.31 | putnopvut | What do you mean by "stack" ? |
| 18:23.38 | jmls | xx calls waiting |
| 18:23.58 | putnopvut | Okay, I think the reason for that is due to the "dumbness" of when you have autofill turned off. |
| 18:24.15 | jmls | heh. the "dumbness" made it work :) |
| 18:24.58 | putnopvut | When you have autofill turned off, the head caller in the queue will always attempt to call queue members without first checking which members are available. |
| 18:25.23 | jmls | ok, that's probably why it works for jsmith as well then |
| 18:25.26 | putnopvut | When autofill is on, the other callers will see that the "one" member of the queue is in use and will not attempt to call until the member becomes available. |
| 18:25.50 | jmls | putnopvut: that's a real shame. Even if you have "ringinuse=yes" ? |
| 18:26.26 | putnopvut | Hmmm, if you set ringinuse=yes, I'd suspect that what you are attempting should work. |
| 18:26.35 | putnopvut | I'm trying to think it through... |
| 18:28.10 | jmls | putnopvut: that's what I thought, but it didn't work |
| 18:29.34 | putnopvut | jmls: I'm looking through the code now to see if I can find why that's not working for you. |
| 18:30.55 | jmls | jbot: hug putnopvut ! |
| 18:30.56 | jbot | ACTION hugs putnopvut ! tightly until putnopvut ! turns slightly blue |
| 18:31.05 | putnopvut | jmls: I see what the trouble is. |
| 18:31.45 | jmls | yay! |
| 18:31.46 | putnopvut | The autofill section will only consider a member available if his state is "Not in Use" or "Unknown" and he's not paused. |
| 18:32.03 | putnopvut | So the autofill code doesn't take into account the fact that you have ringinuse set on the queue. |
| 18:32.16 | *** join/#asterisk-dev Deeewayne (n=dwayne@216.207.245.1) |
| 18:32.16 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:32.44 | putnopvut | lol |
| 19:09.29 | jmls | putnopvut: you want me to raise a bug or not ? |
| 19:10.34 | putnopvut | Oh, yeah, sorry I got a bit distracted with some stuff. |
| 19:11.00 | putnopvut | Actually, there's no need to submit a report. I believe I can fix this really quickly. |
| 19:11.10 | putnopvut | I'll just need to do a couple tests before merging it in. |
| 19:13.48 | jmls | cool. thanks |
| 19:15.19 | russellb | Corydon76-dig: ping |
| 19:15.22 | russellb | M10972 |
| 19:15.23 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0010972: [patch] safe/limited Originate manager action reported by tzafrir http://bugs.digium.com/view.php?id=10972 |
| 19:15.26 | russellb | didn't you merge that already? |
| 19:15.40 | jmls | it's in the changes file for 1.6 |
| 19:15.45 | Corydon76-vcch | pong |
| 19:15.50 | Corydon76-vcch | russellb: different patch |
| 19:15.59 | russellb | does it make this one irrelevant? |
| 19:16.22 | Corydon76-vcch | No, but the second patch will fix that issue. It just needs testing |
| 19:16.41 | Corydon76-vcch | 3rd patch, even. My second patch |
| 19:16.47 | russellb | Corydon76-dig: ok, just checking |
| 19:16.49 | russellb | thanks |
| 19:16.58 | jmls | russellb: ping ;) |
| 19:17.30 | jmls | dang ... |
| 19:18.07 | russellb | Qwell: ping |
| 19:18.07 | russellb | M12100 |
| 19:18.07 | MuffinMan | [new] [Asterisk] Applications/General 0012100: pickup launched with null option will crash asterisk reported by foxfire http://bugs.digium.com/view.php?id=12100 |
| 19:18.07 | russellb | patch looks fine to me, merge it |
| 19:18.19 | file | dear me russellb is looking through issues |
| 19:18.23 | Qwell | russellb: I just wanted to make sure it fixed his issue |
| 19:18.25 | not_jmls | stop him |
| 19:18.33 | Qwell | I can only assume it does, but.. |
| 19:18.40 | russellb | Qwell: assume the best, he'll reopen it :) |
| 19:18.45 | Qwell | works |
| 19:20.30 | russellb | not_jmls: yes? |
| 19:20.41 | Juggie | russellb, Corydon76 is not around today is he? |
| 19:21.13 | Corydon76-vcch | No, I'm not |
| 19:21.18 | russellb | nope |
| 19:21.36 | not_jmls | russellb: thanks :) |
| 19:21.43 | Juggie | Corydon76, i just read over the log from last night re:nolosscdr, you mentioned we should have a defered post which i used to have before |
| 19:21.54 | jmls | see, changing nick worked :) |
| 19:22.00 | Juggie | but as i recall you argued black and blue with me to remove it because you were not willing to change res_odbc |
| 19:22.02 | jmls | russellb: you da cross-compile man ? |
| 19:22.12 | russellb | jmls: file a bug report please |
| 19:22.28 | Corydon76-vcch | Juggie: I disagreed with you about a post that tried forever to repost |
| 19:22.50 | jmls | okiedokie |
| 19:23.12 | Juggie | Corydon76-dig, i was never going to let something try forever to repost. |
| 19:23.29 | Corydon76-vcch | Juggie: That is what I'm opposed to |
| 19:23.39 | Juggie | but my issue which brought this to your attention was that there is no way to tell from ast_obc_prepare_and_execute what actually happened |
| 19:23.51 | Juggie | so how can i decide if its to be deffered, or fatal |
| 19:24.08 | Juggie | that was where we started this conversation previously. |
| 19:24.15 | Corydon76-vcch | Juggie: you have to assume it's fatal unless the driver can tell you otherwise |
| 19:24.29 | putnopvut | jmls: http://pastebin.ca/922363 |
| 19:24.42 | putnopvut | jmls: See if that fixes the behavior you were seeing with autofill. |
| 19:25.02 | Juggie | but in the case of adaptive since it uses res_odbc i only know if it suceeded or not |
| 19:25.14 | Juggie | but if not, i have no idea why.. i dont know if the sql is invalid, or if it cant connect, etc. |
| 19:25.16 | jmls | putnopvut: wilco |
| 19:25.36 | Corydon76-vcch | Juggie: correct |
| 19:25.56 | Juggie | so then an error in adaptive_odbc would allways be fatal then |
| 19:26.05 | Corydon76-vcch | Correct |
| 19:26.14 | Juggie | which is why you said i should retry w/ a time limit and not try to decide if something was a temprary problem or not |
| 19:26.25 | Juggie | but now you are telling us to add a temporary state |
| 19:28.13 | Juggie | see my problem, one of the best cdr modules and i cant tell if the error was fatal or not within odbc so i cant make any decisions so as you said i would have to assume fatal. |
| 19:29.42 | Corydon76-vcch | Well, thank you for calling it one of the best |
| 19:30.52 | Corydon76-vcch | DEFER is an extra feature that may well never be used |
| 19:31.55 | Juggie | i thought we had decided to remove it to be quite honest which i did. |
| 19:32.00 | jmls | putnopvut: the patch failed. was it for trunk or 1.4 ? |
| 19:32.18 | putnopvut | 1.4 |
| 19:32.31 | Corydon76-vcch | Juggie: I don't think it will ever be used for ODBC |
| 19:32.33 | jmls | Hunk #1 FAILED at 2393. |
| 19:33.18 | Juggie | Corydon76-vcch, well it really coudn't possibly be unless we modded res_odbc to give more information. |
| 19:33.37 | Juggie | i'll think about it anyways, i do like the max retries/max time approach |
| 19:33.55 | Juggie | the only thing i want to avoid is, getting stuck on one record when the ones after it are fine. |
| 19:35.16 | Juggie | eg, lets say hypotehtically, we have a record which pushes the write in cdr_csv over the pre determined size of the buffer which is 1024, that would never write, but if all the records after that one are fine, i dont want to block on the bad record |
| 19:35.20 | Juggie | until it times out |
| 19:37.01 | putnopvut | jmls: what svn revision are you trying to patch against? |
| 19:37.04 | jmls | putnopvut: never mind, patched by hand / eye co-ordination ;) |
| 19:37.10 | jmls | latest 1.4 svn |
| 19:37.50 | jmls | compiling now. will let you know the results. |
| 19:38.00 | putnopvut | jmls: wonderful! |
| 19:44.24 | *** join/#asterisk-dev joshaidan (n=joshaida@S0106001c1023e838.tb.shawcable.net) |
| 19:48.31 | jmls | putnopvut: that works just dandy, thanks very much ;) |
| 19:48.49 | putnopvut | great thanks for testing! |
| 19:49.02 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:49.36 | russellb | codefreeze: ping |
| 19:49.42 | russellb | codefreeze: see email regarding astobj2 debugging |
| 19:51.26 | *** join/#asterisk-dev luisetelondon (n=luis@82-69-88-130.dsl.in-addr.zen.co.uk) |
| 19:52.31 | luisetelondon | hi, I have an issue using ChannelRedirect function |
| 19:53.37 | luisetelondon | When the channel is redirected, and the call connected to the other party, it appears a continuous noise like a cos |
| 19:53.48 | luisetelondon | anyone has suffered it before? Asterisk 1.4 |
| 19:56.47 | Corydon76-vcch | luisetelondon: wrong channel, try #asterisk |
| 19:57.03 | luisetelondon | thanks |
| 20:17.25 | codefreeze | russellb: read the email. Very, very interesting. Have to go to a (hopefully brief) doctor appt in a few minutes, but at first glance, looks reasonable. |
| 20:19.07 | russellb | codefreeze: ok, great to hear :) |
| 20:19.14 | russellb | codefreeze: hope the appt goes well ... |
| 20:19.25 | codefreeze | The only prob I might have with it, is that if your intention is to not track all the calls (avoid noise), you lose |
| 20:19.29 | russellb | codefreeze: but when you get back, let me know if it's not clear enough ... |
| 20:19.38 | russellb | codefreeze: interesting |
| 20:19.42 | russellb | codefreeze: let's talk about it when you get back |
| 20:19.51 | codefreeze | ok |
| 20:20.02 | russellb | codefreeze: we could always implement some sort of filtering ... per module, or object type, or who knows |
| 20:20.29 | russellb | have it turned on in the ao2_alloc() call for example ... |
| 20:20.37 | russellb | we can brainstorm later |
| 20:35.58 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 20:44.19 | denon | actually, he's saying that he looks strange .. . |
| 20:44.26 | denon | "* jameswf-home looks strangely" |
| 20:44.28 | denon | :) |
| 20:48.46 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:51.50 | mvanbaak | meh, my nagios is loosing it |
| 20:52.27 | mvanbaak | it put a server on 'ok' status with message "Service recovered. New status: 100% packetloss" |
| 20:52.37 | jsmith-mobile | mvanbaak: don't get me started on nagios |
| 20:53.22 | mvanbaak | it really gives me this mood: "dont worry lads, the thing is still down. no need to worry!" |
| 20:54.28 | kpfleming | jsmith is mobile? how leet |
| 20:54.53 | jsmith-mobile | mvanbaak: I could tell you horror stories |
| 20:55.10 | jsmith-mobile | kpfleming: on the road |
| 20:55.17 | bkruse | mvanbaak: cacti ftw |
| 20:56.05 | jsmith-mobile | mvanbaak: i used to manage the world's largest nagios setup |
| 20:57.20 | mvanbaak | jsmith-mobile: ah |
| 20:58.03 | jsmith-mobile | mvanbaak: so I'm obviously biased |
| 20:58.29 | mvanbaak | you used nagios to monitor the nagios ? |
| 20:58.32 | mvanbaak | ;) |
| 21:01.21 | jsmith-mobile | mvanbaak: Honestly, yes |
| 21:02.25 | jmls | mvanbaak: you need to put your brain into liquid nitrogen to cool it after reading that code |
| 21:02.37 | mvanbaak | jmls: no kiddin |
| 21:02.55 | mvanbaak | but it's interesting |
| 21:03.04 | jmls | you need to get out more |
| 21:03.04 | jsmith-mobile | mvanbaak: we had twelve dedicated Nagios servers |
| 21:03.13 | mvanbaak | jmls: whehehehe |
| 21:03.31 | mvanbaak | jsmith-mobile: wow, I have 1 dedicated VM running on 64megs of ram |
| 21:03.36 | mvanbaak | and it does the job |
| 21:04.21 | mvanbaak | monitoring about 300 machines and roughly 10.000 services |
| 21:06.00 | mvanbaak | ah, almost the same size ;) |
| 21:06.20 | mvanbaak | where did you work? google ? |
| 21:08.45 | bkruse | jsmith-mobile: That is when you realize how much traffic snmp polls costs |
| 21:09.56 | *** join/#asterisk-dev joshaidan (n=joshaida@S0106001c1023e838.tb.shawcable.net) |
| 21:13.06 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 21:37.30 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:45.01 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 21:45.23 | *** join/#asterisk-dev _kb1_kanobe (n=jsmith@bdr2.fieldrd.scrd.ca) |
| 21:48.22 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:51.11 | mvanbaak | someone here that has time to teach me about the obj and list stuff ? |
| 21:51.39 | putnopvut | mvanbaak: which obj and list stuff do you refer to? |
| 21:51.54 | jmls | mvanbaak: a really good lesson. Don't touch it :) |
| 21:51.57 | mvanbaak | astobj and AST_TRAVERSE |
| 21:52.20 | mvanbaak | lol jmls |
| 21:52.37 | putnopvut | mvanbaak: I can't tell you much about astobj since i haven't used it. But as far as things like AST_LIST operations, I can help out. |
| 21:52.48 | putnopvut | And I can also help out with astobj2 as well. |
| 21:53.10 | mvanbaak | putnopvut: well, russell told me the idea for astobj and astobj2 is the same |
| 21:53.14 | mvanbaak | hang on, let me commit what I have right now |
| 21:53.26 | mvanbaak | it's totally horrible I'm sure, but hey, I'm learning |
| 21:53.41 | putnopvut | mvanbaak: It's much appreciated :) |
| 21:54.56 | mvanbaak | there she goes |
| 21:54.56 | putnopvut | mvanbaak: as far as AST_LIST operations and astobj2 API calls go, the .h files are actually very useful and give some decent examples of usage, but if you have any specific questions, I will certainly answer them. |
| 21:55.09 | mvanbaak | nice |
| 21:55.11 | mvanbaak | thank you |
| 21:55.29 | putnopvut | include/asterisk/linkedlists.h and include/asterisk/astobj2.h |
| 21:56.26 | mvanbaak | http://svn.digium.com/view/asterisk/team/group/multiparking/main/features.c?view=markup |
| 21:56.39 | mvanbaak | line 2268 |
| 21:56.41 | mvanbaak | and below |
| 21:57.11 | mvanbaak | in the old setup we did: |
| 21:57.21 | mvanbaak | pu = curlot->occupiedlots; |
| 21:57.28 | mvanbaak | while (pu) { |
| 21:57.42 | mvanbaak | and go te the next entry with: pu->next |
| 21:58.16 | mvanbaak | actually, the code still has that |
| 21:58.36 | mvanbaak | and I just cant get my brain to spit out how to do it in this new setup |
| 21:59.29 | putnopvut | Okay, so you have the AST_LIST_TRAVERSE there, which takes care of the initialization and setting pu to be pu->next. |
| 21:59.55 | putnopvut | So let's see what else can be changed over too. |
| 22:00.24 | mvanbaak | yeah, first iteration I can follow |
| 22:00.44 | mvanbaak | but in there I have to skip some entries if ->notquiteyet is set |
| 22:00.45 | putnopvut | I'm just seeing if there's any odd list usage in that loop anywhere that need to be changed. |
| 22:00.59 | mvanbaak | and run stuff on the ones with notquiteyet set to 0 |
| 22:01.20 | mvanbaak | and then remove them from the list because we are done with them |
| 22:01.47 | putnopvut | Okay, so first step, let's take care of skipping certain entries. |
| 22:02.12 | mvanbaak | yup |
| 22:02.22 | putnopvut | If you want to skip an entry, all you have to do is check for that condition (notquiteyet is set), and just continue if you want to move to the next item in the list. |
| 22:02.41 | putnopvut | by continue, I mean the literal "continue;" |
| 22:03.00 | mvanbaak | so no more 3 blocks of 'if (pu1)' as there is now ? |
| 22:03.07 | putnopvut | right |
| 22:03.32 | mvanbaak | nice |
| 22:04.02 | putnopvut | The tricky part is removing an item from a list while you are traversing the list. |
| 22:04.08 | putnopvut | There are a few steps: |
| 22:04.44 | putnopvut | First of all, if you're ever going to modify the contents of a list while you traverse it, you need to use AST_LIST_TRAVERSE_SAFE instead of AST_LIST_TRAVERSE |
| 22:04.55 | putnopvut | or rather AST_LIST_TRAVERSE_SAFE_BEGIN |
| 22:05.30 | putnopvut | Then if you need to remove an item from the list, then you can AST_LIST_REMOVE_CURRENT, then free the item, then continue if you want to move to the next item in the list. |
| 22:05.49 | mvanbaak | well, in this case, when a timeout is reached we send the call somewhere and remove it from the list |
| 22:06.29 | putnopvut | Okay, let me look at how that's done currently. Which lines are they in the link you pointed me to earlier? |
| 22:07.09 | mvanbaak | starts at 2287 |
| 22:07.17 | mvanbaak | if (tms > pu->parkingtime) { |
| 22:07.25 | mvanbaak | 'you've been parked too long' |
| 22:07.52 | mvanbaak | and 2342 takes care of removing the item |
| 22:08.00 | mvanbaak | 2342 and later that is |
| 22:09.21 | putnopvut | Okay, I see. |
| 22:10.24 | putnopvut | So all you would need to do is AST_LIST_REMOVE_CURRENT(&curlot->parkings, list) to remove the current item from the list |
| 22:10.52 | mvanbaak | hhmm, that makes sense |
| 22:11.00 | mvanbaak | and is easier then it was |
| 22:11.13 | putnopvut | Yes, it is much less prone to error, I think. |
| 22:11.27 | mvanbaak | but to run that I should change the AST_LIST_TRAVERSE to AST_LIST_TRAVERSE_SAFE_BEGIN right |
| 22:12.26 | putnopvut | Yes, and add AST_LIST_TRAVERSE_SAFE_END to the end of the list. |
| 22:12.36 | putnopvut | End of the traversal I mean. |
| 22:12.41 | putnopvut | Sorry if I'm being confusing :) |
| 22:12.57 | mvanbaak | after the closing } that is ? |
| 22:14.27 | putnopvut | Yes, that is correct. |
| 22:15.53 | mvanbaak | like this ? (refresh, I committed the new version |
| 22:16.39 | mvanbaak | oh, did the remove on 2399 now |
| 22:16.52 | Qwell | mvanbaak: bad comments :D |
| 22:18.18 | mvanbaak | yeah yeah. shoot me |
| 22:18.41 | mvanbaak | I'm trying to get it into my brain |
| 22:18.56 | Qwell | jbot: shoot mvanbaak |
| 22:18.57 | jbot | ACTION shoots mvanbaak in the head with a phase pistol! |
| 22:18.58 | mvanbaak | it looks cool, and if it does what I think it does it's pretty nice |
| 22:19.06 | Qwell | done, sir. |
| 22:19.10 | mvanbaak | thank you |
| 22:19.24 | mvanbaak | my will tells the cisco phones go your way |
| 22:19.33 | Qwell | works |
| 22:20.19 | mvanbaak | putnopvut: I changed that block of 'remove from list' at 2342 and later (I think) |
| 22:21.38 | putnopvut | mvanbaak: Okay, I'll have a look at it |
| 22:21.46 | mvanbaak | so basically, instead of copying it to a temp var and run the remove code on that (because the original stuff is moved to pu->next) we run everything on the current item and simply remove it from the list |
| 22:21.50 | mvanbaak | right ? |
| 22:22.04 | jmls | is there anywhere where we have a minumum version for dependencies ? |
| 22:22.13 | kpfleming | version of what? |
| 22:22.16 | jmls | for example, what version of curl |
| 22:22.19 | kpfleming | no |
| 22:22.26 | kpfleming | we don't use version numbers, we use feature tests |
| 22:22.42 | Qwell | I think for curl we do ;/ |
| 22:22.43 | putnopvut | mvanbaak: yes |
| 22:22.48 | mvanbaak | putnopvut: cool |
| 22:22.54 | mvanbaak | it's starting to make sense |
| 22:22.55 | putnopvut | mvanbaak: what is pu->findparknext? |
| 22:23.16 | putnopvut | That's the only thing that's kind of unclear to me at this point. |
| 22:23.18 | jmls | kpfleming: dumb question, but, for example, how would I know which version/release of foo to install on my centos 4 box ? |
| 22:23.48 | mvanbaak | nonexistant |
| 22:24.13 | putnopvut | mvanbaak: okay :) |
| 22:24.25 | mvanbaak | I took it from line 505 |
| 22:24.31 | kpfleming | jmls: sorry, i don't know |
| 22:24.42 | jmls | fair enough. thanks |
| 22:24.47 | kpfleming | i suppose it would be good for someone to document the minimum versions that provide the features we need, but nobody has ever done that |
| 22:24.58 | jmls | are the feature tests in the make file ? |
| 22:25.33 | mvanbaak | jmls: my bet is they are in the autoconf stuff |
| 22:25.34 | kpfleming | no, in the configure script |
| 22:27.22 | mvanbaak | hhmm |
| 22:27.41 | mvanbaak | features.c:2358:51: error: macro "AST_LIST_REMOVE_CURRENT" passed 2 arguments, but takes just 1 |
| 22:27.44 | mvanbaak | features.c: In function ?manage_parkinglot?: |
| 22:27.47 | mvanbaak | features.c:2358: error: ?AST_LIST_REMOVE_CURRENT? undeclared (first use in this function) |
| 22:29.21 | putnopvut | mvanbaak: ah, that's right, I keep forgetting that in trunk, AST_LIST_REMOVE_CURRENT takes one less parameter. |
| 22:29.33 | putnopvut | mvanbaak: so change it to AST_LIST_REMOVE_CURRENT(list); |
| 22:29.39 | putnopvut | Sorry about that. |
| 22:29.46 | mvanbaak | wow, even better |
| 22:29.54 | codefreeze | Isn't it normal to upgrade a rdlock to wrlock? |
| 22:30.12 | file | no |
| 22:30.15 | file | no no no... |
| 22:30.58 | file | (to codefreeze) |
| 22:31.16 | mvanbaak | and the argument to AST_LIST_TRAVERSE_SAFE_END ? |
| 22:31.20 | mvanbaak | is that: list |
| 22:31.21 | mvanbaak | ? |
| 22:31.33 | codefreeze | file: shucks, why not? |
| 22:31.35 | mvanbaak | or the &curlot->parkings |
| 22:31.40 | kpfleming | umm... yeah |
| 22:31.48 | kpfleming | if you can't upgrade a rdlock to a wrlock, then they are pretty hard to work with |
| 22:33.08 | putnopvut | mvanbaak: it is &curlot->parkings |
| 22:33.16 | file | codefreeze: well, you can do it by unlocking and then acquiring a write lock... but you have to verify the previous data again |
| 22:33.21 | mvanbaak | yeah, figured that |
| 22:33.27 | mvanbaak | features.c:2433: warning: statement with no effect |
| 22:33.28 | mvanbaak | meh |
| 22:33.43 | mvanbaak | AST_LIST_TRAVERSE_SAFE_END(&curlot->parkings); |
| 22:33.50 | mvanbaak | that's the line 2433 |
| 22:34.35 | mvanbaak | ah |
| 22:34.46 | mvanbaak | it's: AST_LIST_TRAVERSE_SAFE_END; |
| 22:34.56 | codefreeze | file: hmmmm. that defeats the purpose. Need the data to be readable, but guaranteed not to change, then wrlock and mod it. |
| 22:34.57 | putnopvut | Oh, right.... |
| 22:35.41 | file | codefreeze: exactly what purpose? |
| 22:36.13 | outtolunc | does it even have a ; |
| 22:36.34 | mvanbaak | putnopvut: you just made me go from 8 pages of compile errors to 2 pages |
| 22:36.48 | codefreeze | file: exactly: merge_contexts_and_delete; prepare a replacement from the existing dialplan, rdlock'd while doing so, then upgrade and swap. |
| 22:37.00 | putnopvut | mvanbaak: Hell yeah! |
| 22:38.25 | file | codefreeze: can't, during this "upgrade" time it would technically be possible for it to change, as another thread waiting on a write lock could acquire it before you |
| 22:39.53 | *** join/#asterisk-dev anthm][ (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:41.01 | *** join/#asterisk-dev Mavvie (n=edwin@ppp121-44-15-77.lns10.syd7.internode.on.net) |
| 22:41.05 | Mavvie | mvanbaak: still awake? |
| 22:41.17 | mvanbaak | Mavvie: yes |
| 22:41.35 | Mavvie | mvanbaak: do you recall my strange callback / DTMF issue? |
| 22:41.49 | mvanbaak | putnopvut: one last question: if you have time can you quickly review the list usage in manage_parkinglot |
| 22:41.55 | mvanbaak | http://svn.digium.com/view/asterisk/team/group/multiparking/main/features.c?view=markup |
| 22:42.03 | mvanbaak | line 2260 and later |
| 22:42.21 | mvanbaak | Mavvie: remotely yeah. it does ring a bell |
| 22:42.38 | codefreeze | file: http://lists.boost.org/threads-devel/2007/04/0186.php agrees with you. |
| 22:42.43 | putnopvut | mvanbaak: will do |
| 22:42.49 | Mavvie | mvanbaak: hmmm... is putnopvut your Mantis id or was that somebody else then? |
| 22:43.26 | putnopvut | Mavvie: that's me. |
| 22:43.31 | Mavvie | mvanbaak: sorry. |
| 22:43.35 | file | from a coding perspective it's possible to make the data structure a bit more complex and modify the implementation to support it... except for one scenario where it would not work, which I can't remember |
| 22:43.41 | Mavvie | putnopvut: sorry, wrong pointer in my head. |
| 22:43.53 | file | (that statement is in regards to rwlocks... not your PBX stuff) |
| 22:43.54 | Mavvie | putnopvut: I've done some experiments and have a different theory: |
| 22:44.02 | Mavvie | putnopvut: See http://bugs.digium.com/view.php?id=11917#83095. |
| 22:44.34 | putnopvut | Mavvie: the common link in all the failures seems to be the presence of a PRI... |
| 22:44.37 | Mavvie | putnopvut: the theory is, "could it be that DTMF isn't recognized at all on outgoing PRI channels?". |
| 22:45.05 | putnopvut | Mavvie: you were able to place the call, so I think DTMF is detected in some way. |
| 22:45.23 | Mavvie | putnopvut: that's done with PRI signalling, no DTMF involved. |
| 22:45.31 | mvanbaak | putnopvut: thanks a lot for your time |
| 22:45.47 | Mavvie | "could it be that incoming DTMF isn't recognized at all on outgoing PRI channels?" |
| 22:46.05 | putnopvut | Mavvie: that very well may be. |
| 22:46.36 | putnopvut | And if that's the case, it's more than likely a libpri bug of some sort. |
| 22:47.08 | kpfleming | it used to be that way a very, very long time ago, but is certainly not the case now |
| 22:50.09 | putnopvut | mvanbaak: your usage of the AST_LIST macros looks correct to me. You can actually get rid of the pl and pt variables in that function now. |
| 22:50.57 | Mavvie | kpfleming: are you refering to putnopvut and me or to something else? |
| 22:51.36 | mvanbaak | putnopvut: thanks a lot |
| 22:51.44 | mvanbaak | putnopvut: it finally makes sense to me now |
| 22:51.46 | mvanbaak | really |
| 22:52.25 | putnopvut | mvanbaak: cool. There are a TON of places all over the source that use those macros, so it would probably help to see how they use them in case you ever have difficulties. |
| 22:52.54 | mvanbaak | yeah |
| 22:53.15 | mvanbaak | but because there are TON of places and it did not make sense at all that was of no help |
| 22:53.19 | mvanbaak | till now |
| 22:53.35 | kpfleming | Mavvie: you |
| 22:53.37 | mvanbaak | actually, you made my day |
| 22:54.03 | mvanbaak | at work it was shit. I had 43 phonecalls and around 80 emails |
| 22:54.10 | mvanbaak | so no work done at all |
| 22:54.32 | mvanbaak | and now,.... I start to really understand the AST_LIST stuff |
| 22:54.35 | mvanbaak | \o/ |
| 22:54.47 | Mavvie | kpfleming: I dare to disagree with you, would you mind running a couple of tests with me? |
| 22:54.56 | putnopvut | mvanbaak: wonderful! |
| 22:55.05 | kpfleming | no, i cannot do that |
| 22:55.09 | Mavvie | kpfleming: I'm not afraid to be proven wrong :-) |
| 22:55.27 | kpfleming | what i can say that is that there are thousands of calls placed outbound on PRIs every day that have full DTMF support, including some here at Digium |
| 22:55.49 | kpfleming | but unless you can point to a specific problem in the code, this not really a -dev topic anyway |
| 22:56.23 | Mavvie | kpfleming: true. And they all work fine here. This is a call originated via a call-file and incoming DTMF from the called phone where it goes wrong. |
| 22:56.37 | putnopvut | mvanbaak: what does SKREP mean? I noticed that in some of the code you and oej were committing. |
| 22:57.26 | Mavvie | kpfleming: If you have a spare second, please read up on http://bugs.digium.com/view.php?id=11917 and or the results at #0082351 and #0083095 |
| 22:58.14 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 22:59.41 | kpfleming | i do not, sorry |
| 23:02.03 | mvanbaak | putnopvut: it's a comment by OEJ to make 'make' bail out |
| 23:02.13 | mvanbaak | so he knows where he left |
| 23:02.25 | mvanbaak | must be something swedish |
| 23:02.27 | mvanbaak | ;) |
| 23:03.50 | mvanbaak | actually, I found in my code I do the same |
| 23:04.02 | mvanbaak | DOOD: |
| 23:04.10 | mvanbaak | which means: DEAD: |
| 23:04.25 | mvanbaak | so SKREP must be something like that |
| 23:04.44 | mvanbaak | features.c:2458: error: expected identifier or ?(? before ?return? |
| 23:04.45 | mvanbaak | meh |
| 23:04.49 | mvanbaak | annoying |
| 23:05.00 | mvanbaak | no syntax errors or whatever in that function |
| 23:05.11 | russellb | i'm sure it's a bug in gcc ;) |
| 23:05.30 | mvanbaak | maybe the AST_LIST stuff took 100% of my 'I can handle this' capability |
| 23:05.43 | mvanbaak | and I should leave the code as it is and continue tomorrow |
| 23:06.02 | mvanbaak | russellb: must be ;) |
| 23:06.10 | mvanbaak | but,...... I'm learning |
| 23:06.26 | mvanbaak | and that's fun |
| 23:06.45 | russellb | good, good |
| 23:07.04 | mvanbaak | corramor: that last message to the ml (regarding GLOBAL function) is too funny |
| 23:07.25 | mvanbaak | 'it's new in 1.4 because 1.2 and 1.4 are closed for new features' |
| 23:07.39 | mvanbaak | erm |
| 23:07.45 | mvanbaak | Corydon76-vcch that is |
| 23:07.46 | putnopvut | mvanbaak: I think the error gcc is reporting may be due to the fact that there's an AST_LIST_TRAVERSE_SAFE_END but there's no AST_LIST_TRAVERSE_SAFE_BEGIN in that function. |
| 23:08.08 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:08.08 | *** join/#asterisk-dev anthm][ (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:08.08 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:08.08 | putnopvut | In the do_parking_thread function |
| 23:08.43 | mvanbaak | and again: putnopvut to the rescue |
| 23:08.44 | snuff-work | mm or you can just build it to pre-comp stage with macros expanded in code and go fishing that way |
| 23:08.45 | putnopvut | mvanbaak: corramor just came in here wondering what you were talking about :) |
| 23:12.35 | mvanbaak | gheh |
| 23:12.39 | Corydon76-vcch | mvanbaak: must be a language thing |
| 23:13.03 | mvanbaak | Corydon76-vcch: must be ;0 |
| 23:13.34 | Corydon76-vcch | I didn't think it was particularly difficult to understand |
| 23:14.42 | Mavvie | putnopvut: will run my PRIs with debug=3 in modprobe.conf to see if it throws something interesting. |
| 23:15.21 | Qwell | trivia: what is the first command anybody should type on a branch new freebsd install? |
| 23:15.36 | Mavvie | Qwell: pkg_add -r bash |
| 23:15.42 | Qwell | Mavvie: damn close |
| 23:15.48 | Qwell | cd /usr/ports/shells/bash/ :P |
| 23:16.06 | Qwell | (probably only because I didn't know about pkg_add...) |
| 23:16.08 | putnopvut | Mavvie: all right. Thanks for your continued testing on this one. I hope that we can figure out what's actually wrong. It would suck if it turned out it was a problem with your telco or something. |
| 23:18.05 | putnopvut | But I don't think that's the case. |
| 23:18.05 | mvanbaak | Qwell: scp my_leet_machine:/var/storage/OS/OpenBSD/bsd.rd /bsd.rd |
| 23:18.05 | mvanbaak | reboot |
| 23:18.05 | mvanbaak | boot bsd.rd |
| 23:18.05 | Qwell | wassat? |
| 23:18.05 | mvanbaak | OpenBSD installer |
| 23:18.10 | mvanbaak | OpenBSD > FreeBSD |
| 23:18.42 | mvanbaak | btw, this is really funny: http://www.noob.us/humor/if-business-meetings-were-like-internet-comments/ |
| 23:19.00 | putnopvut | mvanbaak: Ah yes, I've seen that one. |
| 23:20.24 | Corydon76-vcch | Qwell: also vim |
| 23:20.32 | Qwell | nano, thanks |
| 23:20.39 | mvanbaak | Qwell: bsd.rd is OpenBSD kernel + ramdisk with tools you need for recovery/install |
| 23:20.41 | Qwell | Mavvie: so, pkg_add you say? |
| 23:20.48 | Corydon76-vcch | Oh, right, you're one of the silly people |
| 23:20.50 | mvanbaak | like fdisk, disklabel, ifconfig etc |
| 23:21.09 | mvanbaak | Qwell: yeah, try to use packages when they are there |
| 23:21.26 | mvanbaak | ports should only be used when there's no good package for the tool you want |
| 23:21.33 | Mavvie | Qwell: yes. But don't count on ftp.freebsd.org having an available slot at this moment. |
| 23:22.19 | Mavvie | Qwell: don't forget the -r, to retrieve it from a remote repository. |
| 23:22.23 | Qwell | yeah |
| 23:22.28 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 23:22.54 | mvanbaak | Mavvie: fbsd does not use $PKG_PATH ? |
| 23:23.09 | mvanbaak | =15 |
| 23:23.46 | Mavvie | mvanbaak: that one can only contain directories, no URLs |
| 23:24.13 | mvanbaak | Mavvie: yipes |
| 23:24.17 | Mavvie | mvanbaak: use PACKAGEROOT for that. |
| 23:24.35 | Mavvie | or PACKAGESITE (looks like a typo in the documentation |
| 23:24.51 | mvanbaak | # echo $PKG_PATH |
| 23:24.53 | Qwell | so, some things use PKG, others use PACKAGE? |
| 23:24.55 | mvanbaak | # echo $PKG_PATH ftp://spargel.kd85.com/pub/OpenBSD/4.1/packages/i386 |
| 23:24.57 | Qwell | silly bsd |
| 23:25.00 | mvanbaak | # |
| 23:25.17 | mvanbaak | Qwell: s/bsd/freebsd/ |
| 23:25.42 | mvanbaak | on OpenBSD and NetBSD it's PKG_* |
| 23:26.00 | mvanbaak | ah |
| 23:26.08 | mvanbaak | on mirbsd it's PKG_* as well |
| 23:26.15 | Mavvie | mirbsd = openbsd |
| 23:26.20 | mvanbaak | booting dragonfly now |
| 23:26.36 | mvanbaak | ah, there it's PKG_* as well |
| 23:27.12 | mvanbaak | Mavvie: mirbsd is a fork of openbsd, but not the same anymore |
| 23:28.04 | Mavvie | anyway, it seems like PKG_ is used locally, PACKAGE is used for network stuff. |
| 23:28.51 | mvanbaak | in fbsd yeah |
| 23:40.42 | mvanbaak | thankies Mavvie |
| 23:40.52 | mvanbaak | I should get some sleep indeed |
| 23:40.56 | mvanbaak | Fri Feb 29 00:40:56 CET 2008 |
| 23:41.12 | mvanbaak | but not before my commit gets through |
| 23:41.21 | mvanbaak | so prolly will be 3 AM |
| 23:41.23 | mvanbaak | ;) |
| 23:42.52 | mvanbaak | time for bed |
| 23:42.57 | mvanbaak | thanks again putnopvut |
| 23:56.47 | *** join/#asterisk-dev RoyK (n=roy@ip-183-50-149-91.dialup.ice.no) |