| 00:33.20 | philipp64|laptop | ponders that developers are perhaps more concerned with interoperability than users. |
| 00:33.52 | WIMPy | . |
| 00:34.28 | otherwiseguy | Yes, because interoperability is terrible for users. |
| 00:34.31 | otherwiseguy | </sarcasm> |
| 00:35.41 | philipp64|laptop | I guess I'm old if I look back at the days when implementers did interoperability "bake-offs". |
| 00:35.59 | philipp64|laptop | now it seems more fashionable just to finger-point, which is what Taqua is doing here. |
| 00:36.12 | philipp64|laptop | ah, the good old days. |
| 00:37.04 | WIMPy | I sometimes have halucinations about a there having been a thing in the past, called the rouboustness principle. |
| 00:37.33 | philipp64|laptop | in a parallel universe, perhaps. |
| 00:37.39 | otherwiseguy | When your users use completley disparate hardware, you can't just "back off" of interoperability without pissing off one group of your users for the sake of another. |
| 00:37.46 | philipp64|laptop | We used to call it Postel's axiom. |
| 00:40.32 | otherwiseguy | Ok, from what you are saying I think I interpretted your words exactly the opposite from what you meant. Interoperability to me means being liberal in what you accept and strict in what you send. |
| 00:41.05 | otherwiseguy | Backing off of interoperability sounds like "adhering directly to the spec no matter what". |
| 00:41.07 | philipp64|laptop | yeah, that's Postel's axiom |
| 00:41.14 | otherwiseguy | Yes, I know. :-) |
| 00:41.29 | otherwiseguy | Which is what made me realize that I didn't disagree with you. :-) |
| 00:41.34 | philipp64|laptop | so Taqua didn't used to slavishly require the RPID and now they do. |
| 00:42.54 | philipp64|laptop | they keep saying "the problem is at the asterisk end". |
| 00:42.56 | otherwiseguy | Also, when in asterisk-dev and you talk about "developers" it tends to lead one to believe that you might be talking about Asterisk developers. |
| 00:43.12 | philipp64|laptop | I say, I've not changed the config in over a year and it used to work but now it doesn't. |
| 00:43.42 | philipp64|laptop | right... I wanted to ask an Asterisk developer what values the rpid gets populated from. |
| 00:43.57 | philipp64|laptop | the canned sip.conf.sample is a little thin on details. |
| 00:46.56 | otherwiseguy | yes. i meant with the "developers caring more about interoperability than users" statement. I thought "what does he mean? interoperability is great for users. we care about users and interoperability!" In any case, if you have the source available the chan_sip's add_rpid() function should show exactly what it gets set from. |
| 00:48.45 | philipp64|laptop | yeah, I saw that it came from connected.id.number ... |
| 00:49.00 | philipp64|laptop | and if I were more familiar with the source, I'd know off the top of my head what sets that. :-) |
| 00:50.21 | philipp64|laptop | I've not poked around the source in a couple of years now. |
| 00:54.51 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 00:55.56 | otherwiseguy | If I knew the answer, I'd give it to you (despite this not being a support forum), but I don't off the top of my head and if I don't feed my girlfriend, she very well might stab me. |
| 00:56.53 | philipp64|laptop | gf's with knives is generally a good thing. |
| 01:10.59 | philipp64|laptop | *not |
| 03:29.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:29.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:24.31 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 04:58.36 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 05:49.19 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 05:49.25 | schmidts | good morning |
| 06:43.31 | *** join/#asterisk-dev mpe (~mpe@109.70.54.56) |
| 07:00.24 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1008) |
| 07:00.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:00.55 | oej | Good morning folks |
| 07:02.42 | philipp64|laptop | evening. |
| 07:13.54 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 07:13.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.55 | *** join/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 07:14.59 | *** part/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 07:16.48 | *** join/#asterisk-dev Tim_Toady (~fuzzy@62.1.174.66.dsl.dyn.forthnet.gr) |
| 08:16.53 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 08:18.56 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 09:07.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:07.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:07.09 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 10:41.33 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 12:03.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:03.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:03.52 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8d79:4b8a:e445:4e04) |
| 12:11.12 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 12:29.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wluqjwcjcysujgsz) |
| 12:29.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:35.42 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 12:38.38 | *** join/#asterisk-dev kwk (~kleine@carbon.gonicus.de) |
| 12:40.31 | *** part/#asterisk-dev kwk (~kleine@carbon.gonicus.de) |
| 13:52.53 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-yeduyesxxbinlcle) |
| 14:15.27 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-izkgvlqufnsoxaua) |
| 14:31.32 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:31.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:07.17 | *** join/#asterisk-dev gnuday (~gnuday@31.205.53.107) |
| 16:15.20 | gnuday | I have successfully got distributed device states working on an asterisk 1.8.11.1 based corosync/pacemaker 2 node active/active cluster. My question is: can I find out which node a sip device is currently registered to? If so how? I have read all the relevant documentation and can not find anything relevant. Many thanks. |
| 16:25.45 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:25.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:34.43 | gnuday | I would like to avoid the added complexity of DUNDI if possible. |
| 16:37.54 | pabelanger | gnuday: please don't cross post |
| 16:41.51 | leifmadsen | gnuday: plus that isn't a dev question |
| 16:42.02 | pabelanger | leifmadsen: ohai! |
| 16:42.37 | leifmadsen | pabelanger: o/ |
| 16:45.10 | gnuday | Sorry about the cross- posting but the user documentation is rather scant for the AIS functionality. Many thanks for your reply though. |
| 16:49.25 | leifmadsen | points gnuday to the topic |
| 17:35.02 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:35.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:35.09 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:35.44 | rgagnon | Good day people.... I have a quick question about a possible modification to an existing variable sent to AGI clients |
| 17:36.05 | rgagnon | IE: I am patching asterisk to parse the oli tag in the From header... so we can get ANI2 |
| 17:37.24 | rgagnon | should I change the printf() format to %02d for the existing "callingani2" variable that is sent to AGI ? or do you think that will break compatibility... IE: it is called ANI2, but when it is 00, or 07, AGI passes "0" or "7" respectively... does that seem like a big deal? |
| 17:38.08 | rgagnon | I guess I should say this is for SIP, but of course AGI would be for anything |
| 17:42.41 | rgagnon | .... while this stews, I will be afk getting lunch ... (in case anyone wonders why I don't respond) |
| 17:43.40 | acidfoo | I wonder, when does the memory allocated in the function ast_inet_ntoa() buf = ast_threadstorage_get(&inet_ntoa_buf, INET_ADDRSTRLEN) is suppose to be freed ? |
| 17:48.05 | file | it's thread local storage, it lives for the lifetime of the thread |
| 17:49.10 | acidfoo | ok |
| 17:55.49 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:55.49 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:03.42 | acidfoo | if anyone know a bit about varlgrind... I'm running asterisk with valgrind and im trying to understand some trace... by example this one: http://pastebin.com/YM7Ri4VW (sccp is a module written here) |
| 18:04.33 | acidfoo | sccp.c:754 is a call to ast_pthread_create |
| 18:05.14 | acidfoo | does the trace mean that the stack allowed fro the thread is never freed ? |
| 18:06.00 | acidfoo | thanks in advance |
| 18:12.56 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:12.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:33.47 | mjordan | acidfoo: no. Its providing a stack trace from the point where the memory on the heap which leaked was allocated. calloc did the actual allocation, but _dl_allocate_tls in dl-tls.c is the one who called calloc; which was called by pthread_create in allocatestack; which was called by ast_pthread_create_stack in utils.c; etc. |
| 18:34.55 | mjordan | the memory - on the heap - that was leaked is not the same thing as the memory on the stack associated with that particular thread |
| 18:35.48 | acidfoo | ok |
| 18:41.09 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:41.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:50.39 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:100e) |
| 18:50.39 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 18:50.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:50.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:52.49 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:52.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:58.02 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:58.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:16.35 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 19:16.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:39.16 | kpfleming | putnopvut: i believe the answer to the question you posed on that review is 'no'... logical expressions are only defined to return zero or non-zero. |
| 19:39.23 | kpfleming | s/return/evaluate to/ |
| 19:39.47 | rgagnon | https://reviewboard.asterisk.org/r/1947/ |
| 19:39.53 | putnopvut | kpfleming: Okay, that's what I thought, but I was having difficulty finding any sort of language to support me. |
| 19:42.23 | kpfleming | rgagnon: nice! |
| 19:43.33 | kpfleming | putnopvut: i can't find anything either, quickly |
| 19:43.55 | kpfleming | but i know i have seen C code in environments before where the 'true' value for expressions was -1, not 1 |
| 19:45.25 | putnopvut | Right. It just feels wrong to include booleans in arithmetic. |
| 19:51.01 | Corydon76-home | I'm pretty sure for gcc, it's always 1 for truth, but I believe if you used g++, it would flag it as an attempt to use a boolean where an integer was expected. |
| 19:52.15 | Corydon76-home | No telling what llvm uses (mentioned only because it's now the default on Darwin) |
| 19:53.08 | putnopvut | Yay, reviewboard decided to double-post my review for rgagnon |
| 19:56.03 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:56.03 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:56.12 | Corydon76-home | Well, apparently, you cannot use g++ to compile Asterisk anyway. It complains about some of our compiler options |
| 19:57.28 | opticron | good points, I'll change it to explicitly add 1 or 0 |
| 19:58.08 | opticron | I wonder if there's a warning flag for gcc that yells about this kind of thing |
| 20:00.05 | rgagnon | kpfleming: thanks, but the function was easy.... it was finding the right spot in the code to put it ;-) |
| 20:00.40 | Corydon76-home | kpfleming: do you see any value in getting Asterisk to compile with g++? It complains about a ton of extra stuff. |
| 20:00.51 | kpfleming | that's how everthing is. fixing a nuclear reactor with a wrench is easy too, if you know where to apply the wrench. |
| 20:00.52 | kpfleming | Corydon76-home: no. |
| 20:01.19 | kpfleming | we write C, not C++. |
| 20:01.56 | Corydon76-home | Well, it complains about implicit conversions to and from void *, for example |
| 20:02.12 | Corydon76-home | and between signed and unsigned integer expressions |
| 20:02.17 | kpfleming | yes, and many other things that are legal C but not legal C++. |
| 20:02.30 | kpfleming | and compiling with g++ would provide *no* benefits that we are aware of. |
| 20:06.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:06.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:07.55 | rgagnon | question re: scheduled outage next week.... is this because the servers are being upgraded? or just moved? It would be nice if reviewboard was faster :-) |
| 20:08.38 | kpfleming | they are getting upgraded after the move |
| 20:08.57 | russellb | to ... THE CLOUD? |
| 20:09.05 | russellb | ( i just wanted to say CLOUD) |
| 20:09.08 | kpfleming | to a cloud, yes |
| 20:10.04 | Corydon76-home | Is the cloud... in the sky? |
| 20:14.29 | kpfleming | no, we keep ours under water |
| 20:14.54 | russellb | good plan |
| 20:15.08 | russellb | at a recent conference i got a bottle of cloud water |
| 20:15.17 | Corydon76-home | Speaking of which, you missed the tour of the Oak Ridge Supercomputing Lab last Friday |
| 20:15.23 | putnopvut | russellb: you misspelled "cold" |
| 20:15.37 | Corydon76-home | They use water-cooling for their racks |
| 20:15.43 | mjordan | nice |
| 20:15.47 | russellb | no sir, these bottles of water said cloud on them. |
| 20:16.03 | putnopvut | russellb: I was hoping that wasn't the case :( |
| 20:16.24 | putnopvut | notes that all water is cloud water at some point. |
| 20:16.38 | kpfleming | water is a great coolant, and if you can purify it enough, it's pretty safe too |
| 20:16.40 | Corydon76-home | putnopvut: what if it's water on the moon? |
| 20:16.56 | putnopvut | It came from some moon or other space cloud? |
| 20:17.13 | Corydon76-home | The moon doesn't have clouds |
| 20:17.30 | putnopvut | not anymore |
| 20:18.08 | Corydon76-home | ORNL is headed for an Exa-FLOP by the end of the decade. |
| 20:18.24 | kpfleming | when will they reach Hella-FLOP |
| 20:19.46 | Corydon76-home | And their fire suppression plan is pretty cool |
| 20:21.28 | Corydon76-home | All about fire prevention... water-based sprinklers only activate at 185F, as a last-ditch effort |
| 20:22.01 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:01.20 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:01.20 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:05.14 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 21:29.16 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 21:29.21 | *** part/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 22:00.52 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-wluqjwcjcysujgsz) |
| 22:10.24 | kpfleming | pabelanger: troublemaker :-) |
| 22:12.15 | pabelanger | hope not :D New user in #asterisk has been spinning his wheels looking at the wrong documentation. I can understand his frustration, so I put the request into the -dev mailing list |
| 22:26.02 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:26.02 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 23:02.16 | *** part/#asterisk-dev newtonr (~newtonr@nat/digium/x-yeduyesxxbinlcle) |
| 23:07.26 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 23:07.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:15.39 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 23:32.59 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |