| 15:00.27 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:00.27 | *** 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 |
| 15:39.49 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-mfzoxotutzojhnph) |
| 15:47.12 | *** join/#asterisk-dev bchia (~Adium@nat/digium/x-tmsevseeaktcfdgg) |
| 16:00.14 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@38.100.211.103) |
| 16:12.11 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-xsqiebknilxezstg) |
| 16:32.06 | *** join/#asterisk-dev Tim_Toady (~fuzzy@130.43.51.201.dsl.dyn.forthnet.gr) |
| 16:53.51 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:05.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:05.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:06.57 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.1.141) |
| 17:18.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:bd79:76f6:fd8f:ff9d) |
| 17:36.14 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:36.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:53.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:53.06 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:59.53 | jrose_atDigium | (12:55:35 PM) jrose: Hmmm, crap. I don't think I'm going to be able to assign callids before user authorization in the SIP channel driver... at least not without creating some elaborate system to catalog invites that ended in auth challenges and adding a way to grab the callid from that on the second invite. That's probably beyond the scope of what I'm doing here. |
| 17:59.53 | jrose_atDigium | (12:57:55 PM) kpfleming: the initial INVITE dialog sticks around when the 401/407 response is sent... it has to, because that's where the nonce and other authentication information is stored. it's matched up by Call-ID (the SIP kind) when the second INVITE arrives. |
| 17:59.53 | jrose_atDigium | (12:58:40 PM) kpfleming: but what you are working on should be Asterisk channel related.. if the SIP activity didn't create an Asterisk channel, then it should be out of scope. also, this should move to #asterisk-dev. |
| 18:00.51 | jrose_atDigium | kpfleming: Actually, part of the reason for migrating the creation of call IDs from pbx thread creation to the channel drivers themselves is so that we can catalog stuff that happens before the channel is created. |
| 18:01.30 | kpfleming | ok, i suppose. but at the point you are talking about, no 'call' or Asterisk channel exists. |
| 18:02.46 | jrose_atDigium | Right. The same could be said though at almost any point before the SIP channel driver actually create a channel since there are a number of avenues where we'll just reject the invite before creating the channel. |
| 18:03.18 | jrose_atDigium | So failed calls also get call IDs for the time being. |
| 18:06.11 | jrose_atDigium | *though not if they don't make it throught he auth. |
| 18:08.54 | jrose_atDigium | I would actually prefer for invites that fail to auth to get call IDs as well though since they generally represent some independent attempt to call. I just don't want an auth challenge to result in a separate callid for the challenged auth from the auth that actually goes through... or for the auth that ends up being rejected completely. |
| 18:09.49 | jrose_atDigium | For now though, I've moved the call id creation to the point after authentication takes place. *use of authorization above was probably meant to be authentication* |
| 18:10.58 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:32.57 | Kobaz | hey jrose |
| 18:33.10 | Kobaz | So I have some channel logging updates |
| 18:33.15 | Kobaz | mostly it's formatting |
| 18:33.53 | Kobaz | i remember someone mentioning that people parse the asterisk logs |
| 18:34.05 | Kobaz | so what do we do about that |
| 18:44.23 | mjordan | Kobaz: people parsing Asterisk logs is a problem |
| 18:44.43 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:44.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:45.08 | mjordan | when can either accept it as a breaking change, or put in something to turn the logging of it on/off |
| 18:47.32 | Kobaz | mm |
| 18:47.54 | Kobaz | it is a new version |
| 18:48.08 | Kobaz | so people need to accept that some stuff of theirs may need upgrading |
| 18:48.19 | Kobaz | if anything the changes will make it easier to parse |
| 18:48.31 | Kobaz | i'll post a review once i address the others i have pending |
| 18:49.35 | Kobaz | for a new version it doesn't seem useful to keep old logging cruft |
| 18:49.46 | Kobaz | for the sake of backwards compat |
| 18:49.57 | Kobaz | if people are serious they should be using the ami |
| 18:50.34 | pabelanger | or the same APIs the security events use |
| 18:50.42 | pabelanger | or are they also affected? |
| 18:51.00 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 18:51.20 | mjordan | pabelanger: different thing |
| 18:51.37 | Kobaz | i didn't change any of those |
| 18:51.52 | mjordan | security events, imo, shouldn't change from version to version, or at least not without a lot of thought. General logging statements, on the other hand, are more up for dibs |
| 18:52.34 | Kobaz | agreed |
| 18:53.20 | russellb | any performance testing on the new call logging stuff? |
| 18:53.30 | russellb | i need to look at how it was done ... i'm behind |
| 18:53.56 | kpfleming | the security events are binary structures, they will change over time. the log format output of them could also change, but a user can choose to generate their own log format version of them if they wish. |
| 18:57.58 | jrose_atDigium | russellb: You talking about the call id logging? |
| 18:58.12 | jrose_atDigium | If so, no, no performance testing has been done so far. |
| 18:58.21 | russellb | yes |
| 18:58.33 | jrose_atDigium | It was done with thread local storage for the most part. |
| 18:58.51 | jrose_atDigium | It involves basically no locking, so I don't believe performance impact will be especially significant. |
| 18:58.59 | russellb | sounds good |
| 18:59.27 | russellb | did it have filters? |
| 18:59.31 | jrose_atDigium | Noooooo |
| 18:59.42 | russellb | k, thta's where i was worried about locking :) |
| 18:59.55 | jrose_atDigium | Looking at that filter code, I came to the conclusion that it would require so much locking that it would probably destroy my brain. |
| 19:00.47 | jrose_atDigium | At first I thought some of it could be salvaged for the immutable values on channels... but then I realized that there basically are no guaranteed immutable values for channels, so yeah... |
| 19:03.07 | Kobaz | speaking of immutable values for channels |
| 19:03.18 | Kobaz | i want to start work on building in message passing |
| 19:03.27 | Kobaz | channel variables would be the first to do |
| 19:03.39 | Kobaz | channel variables are already copy on write anyway |
| 19:04.18 | Kobaz | there would be a worker thread that would be responsible for setting channel variables by reading from a lockless queue |
| 19:04.33 | Kobaz | so you would no longer need to lock a channel to get/set variables |
| 19:04.45 | Kobaz | just get a ref to it, to ensure that your channel doesn't go away while getting variables |
| 19:04.46 | russellb | you probably still have to local a channel to send a message to it |
| 19:04.48 | russellb | so.. |
| 19:04.56 | Kobaz | all you should need is a ref |
| 19:04.58 | russellb | local? lock |
| 19:05.08 | jrose_atDigium | Hmmm, apparently DAHDI doesn't work at all with the call identifiers right now since it never starts a new PBX thread. |
| 19:05.25 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:05.25 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:05.54 | jrose_atDigium | *more accurately call identifiers never work with DAHDI. DAHDI still works fine as it is for clarification. |
| 19:07.44 | Kobaz | russellb: channel variables would be able to be read without locking the channel because they are read-only.. and if a pointer exists it will be valid |
| 19:09.03 | Kobaz | everything would be COW and pointer updates would always be done last to guaranteed atomicity |
| 19:11.00 | kpfleming | Kobaz: umm... i hate to tell you this, but that Read-Copy-Update, a technique on which IBM holds a number of patents. they have licensed them for use in open source software in various ways (they are used heavily in the Linux kernel, for example), but any potential use of RCU techniques in Asterisk would need to be thoroughly researched before it made its way into the code base. |
| 19:11.08 | kpfleming | s/but that/but that's/ |
| 19:11.30 | Kobaz | hmmm |
| 19:11.58 | Kobaz | another reason software patents need to go away |
| 19:12.10 | Kobaz | especially obvious ones |
| 19:12.18 | russellb | i think software patents are great |
| 19:12.20 | russellb | and nothing should be changed |
| 19:12.24 | Kobaz | haha |
| 19:13.36 | Kobaz | kpfleming: channel variables are already copy on write, it would be the same code but in a message-passing method |
| 19:14.05 | Kobaz | I don't see any remarkably new technology being implemented |
| 19:14.20 | Kobaz | with respect to the copying and updating |
| 19:14.32 | kpfleming | copy-on-write != RCU. RCU has specific features that go beyond COW. |
| 19:15.00 | kpfleming | and neither of us are lawyers, nor do we want to be, so let's not try to debate whether your proposed usage may or may not run afoul of the patents. |
| 19:15.44 | Kobaz | yeah |
| 19:18.35 | WIMPy | He, there's a patent on IF, so ..... |
| 19:19.50 | Kobaz | and there's a patent on triple linked lists |
| 19:20.31 | kpfleming | if you look hard enough, including squinting your eyes just so, there's a patent on everything |
| 19:20.35 | kpfleming | including patenting things |
| 19:20.49 | Kobaz | i'm sure there's gotta be a patent on "using a computer for decision making" |
| 19:21.34 | kpfleming | and one for using a electronic means of communication in a way that causes others to respond in an inflammatory manner |
| 19:23.37 | WIMPy | Another thing: Tonight I tried to catch up with the opaquification thing and that it didn't really make sense to me. |
| 19:24.25 | WIMPy | What's the point in using a function like ast_channel_caller_set if it uses the pointer to the supplied structure instead of copying the contents? |
| 19:24.45 | Qwell | WIMPy: it's all just groundwork for future changes |
| 19:25.11 | WIMPy | If the idea is to have definitely valid data, usind externally supplied data seems silly. |
| 19:25.25 | WIMPy | Yes, I understand. |
| 19:26.04 | WIMPy | But I went, allocated the struct, passed it to the function and free'd it again, obviousely causing a crash. |
| 19:26.47 | WIMPy | But if the stuct were to be copied later, the caller would have to free it, as I initially tried. |
| 19:27.29 | kpfleming | this is only syntax changes for now |
| 19:27.35 | kpfleming | no semantic changes... those will come later |
| 19:27.49 | kpfleming | but these changes make more complex changes possible in the future |
| 19:27.51 | otherwiseguy | WIMPy: The point of the initial pass isn't to have definitely valid data. It was to initially hide the implementation and get something committed such that people weren't going around and creating more and more links to the internals, making the process impossible to ever really get started. |
| 19:27.57 | kpfleming | when the thing you have wont' be an actual pointer |
| 19:29.25 | otherwiseguy | Yep. In about 10 lines of non search-replace code, you can change the ast_channel to something that just holds a pointer to the internal data and has a channel name. Then, theoretically you could rewrite masquerades to basically swap out that pointer, etc. |
| 19:29.46 | otherwiseguy | or other stuffs. |
| 19:30.06 | otherwiseguy | But it was such a huge change, that making semantic changes at the same time would have been a horribly buggy proposition. |
| 19:30.36 | otherwiseguy | And maintaining a branch to do everything at once would be a nightmare. It would break with almost every commit. |
| 19:31.05 | otherwiseguy | Here is 50k lines of code. Find the bugs! GO! |
| 19:31.18 | WIMPy | Well, my point was: If you take the pointer, it's still the callers struct that is used in the channel, so it can be accessed directly. If you want to later change it to copy, the client needs to |
| 19:31.28 | WIMPy | dispose it, which it currently can't. |
| 19:33.28 | otherwiseguy | It *does* copy the ast channel caller. It is a struct assign. |
| 19:34.40 | otherwiseguy | struct blah a = struct blah b is a copy. |
| 19:36.50 | otherwiseguy | i.e. caller, in the underlying structure is struct ast_party_caller caller, not a pointer. And the setter assings *(struct ast_party_caller *) to caller. |
| 19:39.09 | WIMPy | Well, I already fond that I might want to look for another function, but the mentioned ast_channel_caller_set only does chan->__do_not_use_caller = *value; |
| 19:39.31 | kpfleming | that's a structure copy |
| 19:40.10 | otherwiseguy | Also, you must be looking at something old because the __do_not_use stuff went away. |
| 19:40.49 | WIMPy | Yes, I'm going with the first commit that didn't compile any more. |
| 19:41.09 | otherwiseguy | Ah. Yes. It did pretty much break the world for automerge. |
| 19:41.23 | kpfleming | the price of progress |
| 19:43.30 | WIMPy | So has it since then changed to a copy, so I also have to free it then? |
| 19:46.40 | kpfleming | yes, but i think you already did before too... it was always a copy in the ast_channel structure |
| 19:47.20 | otherwiseguy | WIMPy: http://pastebin.ubuntu.com/933044/ |
| 19:47.26 | WIMPy | No. Removing the source after setting it, produces a crash. |
| 19:47.38 | WIMPy | But there might be something else wrong, still. |
| 19:49.30 | WIMPy | otherwiseguy: Looks like what I did, but that then relies upon Asterisk to free "caller" when the channel is destroyed or am I on a completely wrong track here? |
| 19:50.12 | otherwiseguy | You don't free it. It is a struct, not a dynamically allocated memory. |
| 19:50.36 | kpfleming | umm... a struct can be dynamically allocated. you are mixing things up. |
| 19:51.34 | otherwiseguy | As in, not a pointer to dynamically allocated memory, but instead a statically allocated bit of memory representing a struct. |
| 19:52.25 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 19:52.33 | WIMPy | Hmm, yes I did that so I could use the same code for both the old and the new version, but that's probably not neccessary. |
| 19:54.02 | otherwiseguy | ok. I'm really going to go grab some lunch now. |
| 19:54.46 | kpfleming | and where you said 'statically allocated', you probably meant stack-allocated, since statically allocated is something else entirely :-) |
| 19:54.53 | otherwiseguy | :-D |
| 19:55.05 | otherwiseguy | Words are hard. |
| 19:55.09 | otherwiseguy | Code is easier. |
| 19:55.21 | WIMPy | :-) |
| 19:56.16 | otherwiseguy | I'm lucky I can still spell my own name after all of the config stuff. |
| 20:31.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:31.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:32.46 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:32.46 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:49.51 | elguero | I know I am probably just missing it somewhere... where would one find the commit template when committing to trunk only? |
| 20:51.51 | Qwell | elguero: https://wiki.asterisk.org/wiki/display/AST/Commit+Messages |
| 20:53.36 | elguero | Qwell: thanks... thats what I was looking for... |
| 20:57.45 | WIMPy | Wow. I should have taken a look at that earlier. In other channels I see lots of ast_channel_caller(chan)->some.member=value; . |
| 20:58.21 | WIMPy | I.e. not using the .._set function. Was that just a search&replace type thing or what's the idea here? |
| 21:00.56 | WIMPy | The way otherwiseguy pasted should be the end result, I guess? |
| 21:02.45 | otherwiseguy | Yep, more or less. app_meetme has an example of using the set function. |
| 21:03.55 | WIMPy | Yes, I already had it working, but completely messed it up while trying to make it work with older versions as well. |
| 21:39.47 | mjordan | elguero: congrats :-) |
| 21:45.37 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:09.26 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-unlhvlinmivxshzz) |
| 22:38.24 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 22:42.09 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 22:59.00 | WIMPy | I guess I need soem lessons in c. While trying to make the code usable for both the old and the new version, I tried to expand it as in http://wimpy.yeti.dk/pastebin |
| 22:59.15 | WIMPy | That explodes. Where am I thinking wrong there? |
| 22:59.48 | otherwiseguy | Are you trying to free the caller struct at some point? |
| 22:59.58 | WIMPy | no |
| 23:00.09 | otherwiseguy | Why do you have &&? |
| 23:00.55 | WIMPy | Don't I need that to get rid of the pointer? That's what gcc suggests as well. |
| 23:01.05 | otherwiseguy | That isn't how that works. You would just pass "caller". |
| 23:01.21 | otherwiseguy | ast_channel_caller_set takes a pointer. |
| 23:01.48 | otherwiseguy | So you would pass either &s_caller, or caller. |
| 23:02.32 | otherwiseguy | But there is no reason to have both. |
| 23:03.17 | otherwiseguy | I mean, you can, if you don't want to go around changing arrows to periods, but eh. |
| 23:03.45 | otherwiseguy | Aren't pointers fun? :-D |
| 23:04.25 | WIMPy | Yes, it's so that I can do caller=&ast->caller for older versions. |
| 23:04.34 | WIMPy | And yes. Pointers are lots of fun. |
| 23:06.47 | otherwiseguy | I remember when I started at Digium. It had been years (like a decade) since I had done any C development. And that was just some school stuff. I made so many little test programs doing things with pointers those first few weeks. WHY ARE YOU CRASHING program!? |
| 23:07.58 | otherwiseguy | Luckily it came back pretty quick. |
| 23:07.58 | WIMPy | Hmm. Just passing caller looks fine when compiling, but it crashes. |
| 23:08.22 | otherwiseguy | Where does it crash, though? |
| 23:09.16 | WIMPy | On hangup |
| 23:09.35 | WIMPy | And the callerID is some nonsense. |
| 23:10.32 | otherwiseguy | I'd have to see the code, but the problem shouldn't be in the set() function. It's hard to mess up a struct copy. |
| 23:11.41 | otherwiseguy | If you have a non-optimized build, and backtrace info and post it to pastebin, I'll take a quick look. |
| 23:12.18 | WIMPy | lcr_in_setup (line 910) in http://wimpy.yeti.dk/chan_lcr.c |
| 23:12.35 | otherwiseguy | 403 permission denied |
| 23:13.34 | WIMPy | changed |
| 23:14.56 | WIMPy | http://wimpy.yeti.dk/bt |
| 23:22.06 | otherwiseguy | Ah. Looks like you aren't initializing the caller struct at all. |
| 23:22.30 | WIMPy | Initialize in what way? |
| 23:22.46 | otherwiseguy | So some things that would be NULL aren't, and are tried to be freed inside the caller struct. |
| 23:23.01 | otherwiseguy | ast_party_caller_init(&caller) |
| 23:23.11 | WIMPy | When doing it stright with the struct, i.e. the way you posted, it all works. |
| 23:23.26 | WIMPy | Ah. |
| 23:23.47 | WIMPy | So I just go an zero the struct before using? |
| 23:24.30 | otherwiseguy | It would be better to call the ast_party_caller_init function as if things change underneath, it will handle it. |
| 23:26.03 | otherwiseguy | I haven't really looked at the underlying structure of the callerid stuff that much, but it looks like most everything uses the struct, and calls the init function on it. The init function does an ast_part_id_init on two fields inside the ast_party_caller struct, and there is initing going on down below that as well. |
| 23:26.37 | WIMPy | I will try. |
| 23:27.33 | otherwiseguy | The ast_party_caller_free() function basically goes through and frees things that are inside the caller struct. If you allocate an ast_party_caller dynamically, it looks like you'd have to call both ast_party_caller_free and ast_free on it, unless I am missing something. |
| 23:27.48 | otherwiseguy | But I haven't seen anywhere that actually dynamically allocates one. |
| 23:29.00 | otherwiseguy | So yeah, an ast_party_caller_init(&s_ast_caller) *should* do the trick. |
| 23:29.30 | otherwiseguy | It gets hard to handle multiple Asterisk versions with #ifdefs after a while. |
| 23:29.35 | WIMPy | Yes! |
| 23:29.49 | otherwiseguy | Much easier to split things out into their own branches. :-) |
| 23:29.49 | WIMPy | That did the trick. |
| 23:29.54 | WIMPy | Thanks a lot. |
| 23:30.00 | otherwiseguy | No problem. Glad I could help. |
| 23:30.06 | WIMPy | Yes, it's really ugly and checking the version num isn;t ideal, either. |
| 23:30.32 | otherwiseguy | Yep. and doing MAJOR_VERSION MINOR_VERSION stuff gets annoying, etc. |