| 00:01.41 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:18.59 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:18.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:55.43 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:55.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:24.17 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 01:24.17 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 01:32.08 | WIMPy | He, when I pressed return, I just saw that I typed make isntall. From the result it looks like someone here does so frequently. |
| 02:03.29 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:03.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:47.03 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 03:13.07 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:13.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:13.28 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 05:47.33 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 06:34.01 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 06:49.56 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:49.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.31 | *** join/#asterisk-dev GMLudo (~GMLudo@adm3.eyepea.eu) |
| 07:46.49 | oej | morning folks |
| 07:50.11 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1001) |
| 07:50.11 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 08:06.15 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 08:06.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:21.50 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:21.50 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:15.21 | *** join/#asterisk-dev hehol (~Adium@ip-178-202-243-147.unitymediagroup.de) |
| 09:36.11 | wdoekes | ok, so when chan_sip.c does a ast_queue_hangup_with_cause(channel, AST_CAUSE_PROTOCOL_ERROR); the sip status becomes '603 Declined'.. that can't be right, can it? |
| 09:36.34 | wdoekes | this is called from: __sip_autodestruct(), handle_response() for unhandled codes, handle_request_bye() on rare occasions, and (relevant in my case) from the retrans_pkt() retransmit handler on timeout |
| 09:38.27 | wdoekes | (I pass the status to the A leg by doing a Hangup(${HANGUPCAUSE})..) |
| 10:40.27 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:40.27 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:47.38 | WIMPy | If it's a timeout a timer expiry seems more appropriate. |
| 11:43.50 | oej | PROTOCOL ERROR should be something else, yes. |
| 12:24.11 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 12:24.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:49.39 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:49.39 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:11.03 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:15.29 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-imorlimhynpjgawy) |
| 13:59.06 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 14:00.50 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:09.47 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:09.47 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:14.29 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 14:14.59 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 14:14.59 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:18.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:18.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:28.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:28.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:41.39 | mjordan | oej: ping |
| 14:46.38 | anonymouz666 | talking about cdr_mysql... saved my life. there is a problem with some machines that ODBC backend does not work. Same system (CentOS 6), same version (1.8), same arch (64-bit), same database and tables (MySQL), different results... cel and cdr_adaptive odbc print messages like [Jul 11 20:22:55] WARNING[21960]: cdr_adaptive_odbc.c:676 odbc_log: Column type -9 (field 'cdrdb:cdr:clid') is |
| 14:46.38 | anonymouz666 | unsupported at this time. |
| 14:47.27 | mjordan | anonymouz666: what is the column type of that column in the database? |
| 14:48.52 | anonymouz666 | | clid | varchar(80) - this database was dumped from a machine that ODBC works. |
| 14:49.16 | anonymouz666 | the machine that works is Intel i5, the one that does not is a core 2 duo |
| 14:49.44 | mjordan | interesting. |
| 14:49.47 | anonymouz666 | I can't follow any logical stuff |
| 14:49.50 | anonymouz666 | it's all the same |
| 14:49.54 | anonymouz666 | just the processor is different |
| 14:50.03 | wdoekes | anonymouz666: show create table and look for collation stuff |
| 14:50.52 | anonymouz666 | the one that works, there's no collation stuff. |
| 14:50.56 | anonymouz666 | let me see the other |
| 14:53.24 | anonymouz666 | `clid` varchar(80) NOT NULL DEFAULT '', vs `clid` varchar(80) CHARACTER SET utf8 NOT NULL DEFAULT '', |
| 14:53.32 | anonymouz666 | is this the reason? |
| 14:54.03 | mjordan | anonymouz666: hm... I can't find a SQL type in sqlext.h that maps to -9 |
| 14:54.11 | mjordan | still looking however |
| 15:00.56 | oej | mjordan: pong |
| 15:03.05 | mjordan | oej: just wrapped up some DTMF testing |
| 15:03.12 | mjordan | oej: your suggestion is looking very promising :-) |
| 15:03.40 | oej | THanks for the feedback |
| 15:03.53 | mjordan | thanks for the suggestion! |
| 15:04.05 | oej | yeah, I've been deep down in RTP lately. I don't want to be that deep down in audio, but had to. |
| 15:04.08 | oej | ;-) |
| 15:09.39 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:14.54 | wdoekes | anonymouz666: I think it might be. doesn't hurt to test removing the charset |
| 15:16.59 | anonymouz666 | wdoekes: I am removing right now |
| 15:23.23 | anonymouz666 | problem solved. |
| 15:23.56 | anonymouz666 | thank you very much. I'd never fix that. |
| 15:24.24 | anonymouz666 | I need to spread this information, will benefit many people |
| 15:30.04 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:30.04 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:59.26 | WIMPy | Now when HANGUPCAUSe is converted to a function, wouldn't it be the right time to add a location? |
| 16:04.23 | mjordan | WIMPy: can you describe what you mean in a bit more detail? |
| 16:05.26 | WIMPy | The hangup location. The cause alone doesn't always make sense. |
| 16:07.01 | mjordan | as in location in the dialplan, location as in the channel that hung up, location as in ALI...? |
| 16:07.26 | WIMPy | Location as used in the PSTN. |
| 16:08.28 | WIMPy | If your call is rejected by the callee, they probably don;t want to talk to you. If it was your telco, you might want to check if you paid your bill :-) |
| 16:08.50 | opticron | if that is expressed in the cause code, that will be provided |
| 16:08.57 | mjordan | WIMPy: that makes sense, but since this is currently technology agnostic, you'd want to make sure that whatever is passed back makes sense for things like SIP as well |
| 16:09.06 | WIMPy | It's a seperate field. |
| 16:09.11 | opticron | ah |
| 16:09.46 | mjordan | opticron: is the control frame passing a string up from the channel technology, or a pointer to some struct? |
| 16:09.56 | opticron | pointer to a struct |
| 16:10.00 | mjordan | sweet |
| 16:10.07 | WIMPy | If you get a no channel or circuit available locally, you could try another route. If it happens at the callee, that' won;t help; |
| 16:10.10 | mjordan | WIMPy: that'd be a good improvement, but it'd probably be out of scope for 11 |
| 16:10.22 | mjordan | but it'd be definitely doable with the mechanisms in place |
| 16:10.24 | opticron | contains the asterisk cause and tech string currently, but others are easily addable |
| 16:10.45 | WIMPy | Or from earlier today: If you have a protocoll error, you want to know if you're involved in it. |
| 16:11.17 | opticron | and as soon as 11 gets branched, that structure gets a tad simpler |
| 16:14.54 | WIMPy | But, yes, to sensibly set the location within Asterisk, some sort of peer type would make sense. |
| 16:15.40 | WIMPy | That is a sip peer being a phone or an uplink. |
| 16:16.55 | Corydon76-home | mjordan: -9 is SQL_WVARCHAR |
| 16:17.19 | mjordan | Corydon76-home: thanks |
| 16:17.45 | Corydon76-home | In order to support it correctly, we need utf-8 checking and conversion code |
| 16:20.05 | Corydon76-home | Because without it, somebody will inevitably try to insert an extended character into a UTF-8 field, and they'll get freak-out |
| 16:31.19 | anonymouz666 | Corydon76-home is the DB Master |
| 17:10.20 | *** join/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 17:10.35 | *** part/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 17:56.52 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:56.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:16.55 | kpfleming | Corydon76-home: how would you suggest recovering from an alloca() failure? |
| 19:07.10 | kpfleming | opticron: technically, it's URI-encoding, not escaping :-) |
| 19:07.42 | Corydon76-home | kpfleming: same way you recover from any memory allocation error |
| 19:07.59 | Corydon76-home | At best, very poorly. |
| 19:08.12 | kpfleming | i don't think so... if there's no stack space available, there's very little you can do. if the heap is full, at least you can usually report it. |
| 19:08.18 | russellb | better question, how do you detect it ... |
| 19:08.36 | Corydon76-home | russellb: the BSDs all do stack checking |
| 19:08.57 | russellb | oh, so like 0.003% of asterisk installs |
| 19:09.11 | russellb | and they return null? |
| 19:09.14 | kpfleming | whistles |
| 19:09.22 | Corydon76-home | That includes Mac OS X, btw |
| 19:09.36 | Corydon76-home | and yes, alloca() returns NULL in those cases |
| 19:09.41 | russellb | ah, so 0.003002% |
| 19:09.45 | Corydon76-home | So you're looking more like 3%. |
| 19:09.53 | Qwell | That one OS X user should get more memory. :P |
| 19:09.53 | Qwell | hides |
| 19:10.01 | russellb | seriously doubts that |
| 19:10.05 | Corydon76-home | Qwell: again, stack, not heap |
| 19:10.05 | kpfleming | ditto. |
| 19:10.06 | file | 3% is a lot, it's not that much by any stretch of the math |
| 19:10.48 | Corydon76-home | Hey, we put format lengths on every stinking sscanf in Asterisk, because of a vulnerability in sscanf on NetBSD. |
| 19:11.10 | Corydon76-home | So don't tell me we don't make code changes for problems on BSD. |
| 19:11.15 | kpfleming | and like everyone already said, recovery from an out-of-stack/heap condition is nearly impossible |
| 19:12.25 | Corydon76-home | Well, it depends. If you're attempting to allocate 200 bytes on the stack for a string, and you only have 100 to spare, you still can go to a subroutine to spit out an error string |
| 19:12.33 | kpfleming | maybe |
| 19:12.45 | kpfleming | if the subroutine and printf() don't need more than 100 bytes of stack |
| 19:13.11 | Corydon76-home | Typically, they don't |
| 19:13.17 | Corydon76-home | printf() anyway |
| 19:13.36 | jrose_atDigium | You could enforce a strict amount of space to reserve on the stack for the purpose of errored returns. |
| 19:13.51 | jrose_atDigium | or something like that anyway. |
| 19:13.55 | Corydon76-home | Even asprintf doesn't... uses a file descriptor for the temporary storage |
| 19:14.08 | Corydon76-home | jrose_atDigium: I suspect the BSDs do that, actually |
| 19:14.09 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:c9e0:2297:73ad:9050) |
| 19:14.16 | kpfleming | a file descriptor to what? fds aren't storage. |
| 19:14.40 | Corydon76-home | Sure they are. Scratch space |
| 19:14.48 | kpfleming | no, an fd is a handle. |
| 19:14.53 | kpfleming | it points to *something*. |
| 19:15.16 | Corydon76-home | Well, sure, but not in user space |
| 19:15.27 | kpfleming | is now totally lost |
| 19:16.05 | Corydon76-home | asprintf opens a file handle, outputs to that, then allocates heap based upon how much was output to the file descriptor |
| 19:16.16 | Corydon76-home | It uses very little stack |
| 19:16.43 | kpfleming | still.. a file handle to what? a file in /tmp? tmpfs or something similar? a handle is a handle, it is only an access path to something. |
| 19:17.05 | kpfleming | the return value of socket() is also an fd, but cannot be used as temporary storage, for example. |
| 19:17.14 | Corydon76-home | Fair enough |
| 19:17.44 | Corydon76-home | But we're getting far afield from whether we might be able to handle a NULL return from alloca() |
| 19:17.47 | kpfleming | if it opens a file on the filesystem, then it's enormously expensive and we should stop using it |
| 19:18.11 | kpfleming | true enough |
| 19:18.22 | kpfleming | since none of the code currently checks the return value of alloca()... |
| 19:20.25 | Corydon76-home | which on Linux, doesn't matter, because it doesn't work that way |
| 19:30.05 | kpfleming | file: are you going to wait until sunday to commit the SIP over WebSocket stuff, as you usually do? |
| 19:30.24 | file | probably! |
| 19:31.02 | Corydon76-home | kpfleming: http://opensource.apple.com/source/sudo/sudo-4/sudo/alloca.c |
| 19:31.21 | Corydon76-home | That's why alloca() can return NULL: it uses heap |
| 19:31.33 | kpfleming | that's an implementation inside sudo |
| 19:32.18 | Corydon76-home | Yes, but that was the implementation inside BSD |
| 19:32.25 | kpfleming | that is very strange... i have no idea how 'reclaiming' memory from alloca() could ever be done |
| 19:33.49 | Corydon76-home | It assumes that alloca() in such a program is run often, so it uses pointers to the stack within the heap memory to determine, at every new call, whether other parts of the chain can be freed |
| 19:38.08 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.40.134) |
| 19:38.08 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:40.41 | Corydon76-home | Looks like alloca() was changed in Mac OS X to go with the gcc compiler-based definition |
| 19:40.53 | Corydon76-home | starting in Lion |
| 19:49.18 | tzafrir_laptop | https://reviewboard.asterisk.org/r/2027/ - any objection for it included (before the freeze) |
| 19:49.20 | tzafrir_laptop | ? |
| 19:53.07 | kpfleming | mjordan: speaking of that... take a look at what russellb did last year leading up to the feature freeze, where we built a list of candidate code/reviews/etc. to be considered as part of the freeze, because they would be able to be reviewed and merged in a reasonable period of time |
| 19:53.32 | russellb | i did something? neat |
| 19:53.41 | leifmadsen | lies |
| 19:53.50 | mvanbaak | impossible |
| 19:54.07 | kpfleming | yeah, back before you went over to the dark side |
| 19:54.15 | leifmadsen | dun dun dun |
| 19:54.27 | mvanbaak | "I am your father" |
| 19:54.29 | leifmadsen | russellb: he's calling you out |
| 19:54.33 | russellb | i see that |
| 19:54.45 | russellb | i'm not sure this is the dark side, though, heh |
| 19:54.58 | russellb | i didn't go to ... Avaya or something |
| 19:55.03 | mvanbaak | your powers have become stronger? |
| 19:55.03 | kpfleming | true |
| 19:55.11 | kpfleming | but that would have made my statement less interesting |
| 19:55.28 | russellb | true |
| 19:55.29 | russellb | leifmadsen: i am your father |
| 19:55.48 | russellb | actually has a patch to post! |
| 19:55.56 | russellb | going to be fun to try to spin this as a bug fix, heh |
| 19:56.16 | mvanbaak | just commit it ;-) |
| 19:56.18 | kpfleming | Bug: Asterisk does not make toast. |
| 19:56.26 | Qwell | russellb: is this some more Fedora eth0 wackiness? :p |
| 19:56.29 | mvanbaak | nor does it make bear |
| 19:56.34 | russellb | heh, nah |
| 19:56.48 | mvanbaak | I want to start that hobby |
| 19:56.51 | leifmadsen | russellb: huh that's awkward then |
| 19:56.52 | russellb | event cache handling performance issue ... |
| 19:56.52 | mvanbaak | brew my own beer |
| 19:57.16 | jrose_atDigium | brews a bear |
| 19:57.21 | leifmadsen | heh |
| 19:57.26 | russellb | leifmadsen: yeah, is kinda awkward, my bad yo |
| 19:57.35 | russellb | especially since you're older than me |
| 19:57.51 | tzafrir_laptop | is actually really interested in getting some actual feedback to either https://reviewboard.asterisk.org/r/726/ or https://reviewboard.asterisk.org/r/1598/ |
| 19:58.04 | jrose_atDigium | Perfectly explainable though. Leifmadsen is a time traveler. |
| 19:58.38 | russellb | there goes tzafrir_laptop , trying to get real work done |
| 19:58.49 | mvanbaak | lol |
| 19:59.21 | leifmadsen | rookie mistake |
| 19:59.25 | leifmadsen | minecraft! |
| 19:59.33 | russellb | leifmadsen: duuuuuuuude |
| 19:59.37 | leifmadsen | hides |
| 19:59.43 | leifmadsen | russellb: sorry, my bad :) |
| 19:59.48 | russellb | leifmadsen: i think i need to work a few days straight to work off last night's minecraft binge |
| 19:59.57 | leifmadsen | sounds about right |
| 20:01.02 | file | Minecraft addicts. |
| 20:05.24 | russellb | correct |
| 20:06.22 | *** join/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 20:06.29 | *** part/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 21:04.35 | kpfleming | some day, we should figure out how to rewrite menuselect. i just updated my trunk checkout, and menuselect showed chan_motify enabled, but res_xmpp not enabled, even though chan_motif depends on it. |
| 21:06.22 | Qwell | is res_xmpp defaultenabled? |
| 21:06.31 | Qwell | could have just checked himself.. |
| 21:07.24 | Qwell | It is. But, I bet it's the same issue as app_voicemail and res_adsi, when it wasn't defaultenabled |
| 21:07.39 | Qwell | it's screwy |
| 21:08.46 | Qwell | there's some weird ordering, and a couple double negatives |
| 21:43.50 | wedhorn | mjordan: i've posted https://reviewboard.asterisk.org/r/2040/ and would appreciate some feedback on the general approach taken |
| 21:44.04 | wedhorn | it's pretty much a precursor to working on skinny locking |
| 21:46.40 | mjordan | wedhorn: sure thing! |
| 21:47.09 | wedhorn | thanks |
| 21:52.39 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-afnjxivngkxudcyz) |
| 22:16.06 | mjordan | wedhorn: if you're telling me that in regards to the e-mail I sent out to #asterisk-dev, do you mind replying to that e-mail as well? That way its on more then just my radar :-) |
| 22:17.34 | wedhorn | mjordan: actually I wasn't, but seeing as it's relevant, will do. |
| 22:17.51 | mjordan | thanks :-) |
| 22:37.32 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 22:58.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 22:58.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:53.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:53.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |