| 00:42.44 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 00:42.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 04:27.15 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 05:49.29 | *** join/#asterisk-dev jpepper (~jpepper@c-71-207-179-69.hsd1.al.comcast.net) |
| 06:33.33 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 06:33.33 | *** mode/#asterisk-dev [+o ChanServ] by zelazny.freenode.net |
| 06:48.21 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:48.23 | schmidts | good morning |
| 06:54.05 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:03.52 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:03.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:21.30 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 08:21.30 | *** mode/#asterisk-dev [+o ChanServ] by zelazny.freenode.net |
| 08:37.06 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 10:52.59 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 11:18.34 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 11:28.36 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 11:28.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:15.03 | acidfoo | mooorning |
| 12:17.38 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 12:25.32 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:25.32 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:38.19 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:38.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:44.30 | *** join/#asterisk-dev spditner (~simon@206-248-134-101.dsl.teksavvy.com) |
| 12:48.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:48.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:56.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:56.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:13.19 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-saeiuuaaggyrwdnb) |
| 13:13.19 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:13.59 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:3cea:536e:bdaf:ceff) |
| 13:28.18 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ojstiragumcfwhpw) |
| 13:30.58 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:31.09 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:35.00 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-sgkklxhjhcfxdhpv) |
| 13:35.00 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:22.34 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:22.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.21 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 15:08.55 | kpfleming | pretty quiet in here |
| 15:09.33 | mjordan | Monday morning |
| 15:29.27 | jsmith | Too quiet, indeed |
| 15:29.46 | WIMPy | Too hot to do anything. |
| 15:29.55 | jsmith | So, I just found out that a friend (and fellow Fedora contributor) is moving from Kosovo to Huntsville |
| 15:30.03 | jsmith | so that he can go to high school there |
| 15:30.13 | jsmith | I'd love to get him tied into the local Linux community |
| 15:30.35 | jsmith | Anybody want to volunteer to help him get to know the LUGs and what not in the area? |
| 15:32.54 | opticron | lets see...there's the local hacker/maker space (makers local 256) the local 2600 group (mostly defunct, but still meets monthly) and a LUG that I think meets on saturdays at a sporting goods store in the north part of town |
| 15:33.51 | opticron | gander mountain |
| 15:37.26 | kpfleming | interesting place for a LUG to meet |
| 15:37.50 | opticron | I thought, so too |
| 15:38.05 | opticron | I haven't actually been to one, but many other ML256 members have been |
| 15:49.49 | rgagnon | Here's a probably simple question for those in the fax-gateway business.... Why is it that fax gateway detect is only set to watch SLIN and G711, and not other codecs like G729? (I'm guessing it has to do with bandwidth and quality issues, but I'm looking for a more official sounding response from an expert) |
| 15:51.24 | rgagnon | I ask here because I was thnking of adding G729 to the switch-case in the code just to see what happens, but wondering if its even worth trying |
| 15:52.49 | WIMPy | Voice optimized low bandwidth codecs aren't able to transport modem signals in a way that makes them decodable at the other end. |
| 15:53.25 | rgagnon | so basically you probably wouldnt even be able to get the CNG tone to us over 729 in order to switch to T38 |
| 15:53.56 | WIMPy | The single tone might work. |
| 15:56.03 | rgagnon | we had an oddball request from a customer carrier of ours to detect CNG over their inbound g729 to us, and then do T38 gateway... After of course, a reinvite down to G711... Sounded like they might be smoking something but I didnt know if this is something other softswitches even support. |
| 15:57.25 | WIMPy | Erm, I haven;t ever cared about the fax stuff, but doesn't T38 completely replace the audio path? |
| 15:57.50 | rgagnon | yup. The trick is to detect it and have gateway kick in to do that |
| 15:58.18 | WIMPy | So what's that about the reinvite to G.711? |
| 15:58.21 | Qwell | rgagnon: detecting tones in a low quality codec is unreliable, at best |
| 16:00.32 | rgagnon | wimpy: This customer believes they would send us everything they have as g729, but SOME calls are fax. They wanted us to detect Fax, switch to G711, so that fax gateway code would detect the tone (which seems dumb) and then switch again from G711 audio over to T38 fax. ---all of this sounded a bit like they are overcomplicating something that isn't intended to be done in the first place. |
| 16:01.15 | WIMPy | Ah, this os for faxes from you to them? |
| 16:01.36 | rgagnon | no. from them, through us to another vendor on our outbound routing side |
| 16:01.52 | rgagnon | we're just being a tandem carrier in the middle in this case |
| 16:01.54 | WIMPy | No, the sensible way is to know what it is before trying to set up a connection. |
| 16:02.06 | rgagnon | Thats what I told my boss :-) |
| 16:02.36 | rgagnon | I was hoping the room would confirm my suspicion... looks like it did |
| 16:03.44 | WIMPy | I guess, it might work, but even if it does, I wouldn't put much (any?) trust in it. |
| 16:04.39 | kpfleming | fax tones can't be detected in a G.729 stream without decoding it. CED probably can be transported cleanly by G.729, but it still needs to be decoded to be detected. |
| 16:07.49 | kpfleming | but even then, the call would be switched to T.38, not G.711 |
| 16:08.43 | rgagnon | winpy: I'm glad we're on the same page. kpfleming: thanks. That probably sums up about what I was thinking would happen as well, but its handy to have someone else on paper when I explain it back up the chain. |
| 16:09.45 | WIMPy | To be clear: The intermediate change to G.711 is the thing about it I find most interesting. |
| 16:10.04 | rgagnon | so, the transcoding in the frame trapping part of T38gateway code that converts the codec from 711 to SLIN in order to see if the CNG/CED tones are in there just would not be able to see a transcoded G729 frame right? |
| 16:11.43 | rgagnon | Wimpy: I think they were trying to find a work-around. We told them they would have to send G711 for us to be their gateway. So they responded by asking if we could detect the tone in 729, and then re-invite to 711 in order for the gateway to work. I think their idea is a bit weird, and there is either: 1) no way to do that, or 2) A better way to do it |
| 16:12.32 | WIMPy | 1: Maybe, 2: Certainly |
| 16:13.46 | rgagnon | I still don't understand why the person that is the 1st mile carrier wouldn't have already converted the fax from TDM to T38 anyhow |
| 16:14.29 | WIMPy | Yes, that would be a good solution. |
| 16:29.52 | kpfleming | if the CED tone comes in on G.729, and it is decoded to SLIN, then there is a good chance it would be detected. it's a single-frequency tone, so it should be OK. |
| 16:30.02 | kpfleming | but then the gateway code would attempt to switch to T.38. |
| 16:35.43 | putnopvut | I'm working on a hypothesis on ASTERISK-20212 here, and I'd like to get some input from people if they think I might be onto something. On that issue, there is a call to fgets() that is blocking forever. The fgets() is in a TCP client thread in chan_sip.c. fgets() follows a call to ast_poll() and a potential call to ast_wait_for_input() on the FILE pointer's underlying file descriptor. Presumably, since poll() and ast_wait |
| 16:35.43 | putnopvut | _for_input() have both stated there is data to be read, then there should in fact be data to be read. |
| 16:36.05 | putnopvut | However, the thing that throws me here is that we poll for both POLLIN and POLLPRI events. |
| 16:36.27 | putnopvut | Since our polls are followed by fgets() and not read() calls, I'm curious to know if fgets() does not play nicely with POLLPRI data. |
| 16:37.35 | putnopvut | Does anyone here have prior knowledge of whether an fgets() call will block if the data that the underlying file descriptor has is priority data, such as out-of-band TCP data? |
| 16:40.24 | putnopvut | Also, for the record, I have attempted to google this, but I've not come up with anything useful. |
| 16:46.35 | mjordan | putnopvut: I wonder if we should be checking whether or not the event on the file descriptor really is POLLPRI or POLLIN |
| 16:48.08 | putnopvut | Well, that may be something we should do. I just don't know how fgets() plays with POLLPRI data. I suppose I could hack together a test program and try it out. I'd have to figure out how to construct a TCP packet with the "urgent" bit set though. |
| 16:49.16 | putnopvut | Similarly, if the poll returns stating that there is POLLPRI data and we should be reacting differently, I"m not sure how we should be reacting. Perhaps call read() directly instead of fgets()? But then what about TLS connections? |
| 16:49.21 | mjordan | putnopvut: while I wouldn't call it a sound test case, googling for fgets/POLLPRI pulled up a reasonable number of code samples that do that |
| 16:50.10 | seanbright | poll() works on an fd, and fgets works on a FILE * |
| 16:51.01 | seanbright | it's bad mojo to mix the two |
| 16:51.10 | putnopvut | no kidding |
| 16:51.18 | seanbright | there was a bug in manager (that probably still exists) that was caused by that |
| 16:51.48 | putnopvut | seanbright: any idea on the details of that manager bug? |
| 16:51.49 | seanbright | something with mmap, i hacked in something but i doubt it's 100% reliable |
| 16:51.58 | seanbright | putnopvut: let me find it |
| 16:52.41 | seanbright | process_output in main/manager.c |
| 16:53.26 | seanbright | basically it writes a byte using buffered i/o and then fflush()s and then mmap() based on the assumption that the underlying fd is good to go |
| 16:53.40 | putnopvut | ugh |
| 16:53.41 | seanbright | which based on my understanding is follhearty |
| 16:53.49 | seanbright | foolhearty too |
| 16:54.05 | putnopvut | The only reason we're using FILE * at all for these TCP connections is because of OpenSSL |
| 16:55.14 | seanbright | openssl doesn't have any lower level routines that work on fds? |
| 16:55.21 | seanbright | so lame |
| 16:56.17 | opticron | there was another problem that came up with this kind of thing, but I think fgets was returning NULL in that case |
| 16:56.20 | putnopvut | I'm not going to say it doesn't. I think the original writer of our TLS code realized it would be an ass pain to have to call a bunch of SSL stuff every time we wanted to read data vs. using fopencookie() to remap read/write/etc. operations. |
| 16:57.00 | file | it's not *horrible* |
| 16:57.00 | putnopvut | opticron: yeah, I have that issue open as well. |
| 16:57.04 | file | (calling the SSL stuff) |
| 16:57.51 | seanbright | have something that fails .01% of the time is horrible |
| 16:58.04 | seanbright | because a FILE * and an fd are "out of sync" |
| 16:58.15 | putnopvut | So what I may do is offer a patch for the reporter where I replace the fgets (and similar FILE * operations) in chan_sip with direct calls on the fd and see if that makes a difference. |
| 16:58.29 | seanbright | i would venture a guess that it would |
| 16:58.41 | seanbright | but only based on decades of experience |
| 16:58.47 | seanbright | that i'm sure someone here has |
| 16:58.50 | putnopvut | Since he's not using TLS, it might help. If it does, then a larger effort should be made to get rid of FILE * stuff altogether in TCP/TLS code. |
| 16:58.58 | mjordan | putnopvut: agreed. |
| 16:59.04 | seanbright | janitor project |
| 16:59.07 | seanbright | (kidding) |
| 16:59.07 | putnopvut | heh |
| 16:59.22 | mjordan | that would probably tie in well with the other issues opticron found as well with the tcptls code |
| 17:00.03 | putnopvut | Yeah, that's the one where fgets is returning NULL presumably because there is some SSL metadata on the socket but no actual data to read |
| 17:00.05 | putnopvut | or something like that. |
| 17:01.18 | *** join/#asterisk-dev jpepper (~jpepper@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 17:13.43 | opticron | putnopvut, correct |
| 17:13.54 | opticron | SSL transaction data but no end-user data |
| 18:32.57 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 18:32.57 | *** mode/#asterisk-dev [+o ChanServ] by zelazny.freenode.net |
| 18:47.31 | *** join/#asterisk-dev GameGamer43 (users.5533@id-5533.hampstead.irccloud.com) |
| 19:02.41 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 19:02.41 | *** mode/#asterisk-dev [+o ChanServ] by zelazny.freenode.net |
| 19:08.35 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 19:25.08 | putnopvut | jpepper: Hey I was wondering if you'd had any more issues since you tried the patch on ASTERISK-20237? |
| 19:29.27 | jpepper | Nothing yet! Well, I've had issues, but elsewhere. Still pinning down what's going on there though. |
| 19:32.44 | putnopvut | Okay, would you be willing to say that the patch I've provided has fixed the issue you reported then? Trying to figure out if it's ready for commit or if I haven't given it long enough. |
| 19:39.56 | jpepper | Yes, definitely |
| 19:40.19 | jpepper | I've made thousands of calls with it without the issue recurring |
| 19:48.37 | putnopvut | Okay, excellent. Then in that case I'm going to commit it to 11 and trunk (minus the "Oh crap" comment and the other spammy one) |
| 19:52.04 | mjordan | putnopvut: more oh crap comments plz |
| 20:11.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 20:38.47 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 20:38.47 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:59.37 | jsmith | Random question of the day -- what's the runtime performance penalty (roughly) for turning on DEBUG_THREADS? |
| 20:59.49 | jsmith | Is it significant? |
| 20:59.59 | jrose_atDigium | I'm pretty sure it's supposed to be pretty heavy |
| 21:00.07 | jsmith | That's what I was afraid of :-( |
| 21:01.55 | jrose_atDigium | I don't have any kind of percentage unfortunately. I think it hurts having lots of simultaneous calls more than anything. |
| 21:02.22 | jsmith | Unfortunately, I *do* have lots of concurrent calls on my systems |
| 21:19.00 | *** join/#asterisk-dev jpepper (~jpepper@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 21:21.51 | kpfleming | yes, it's pretty heavy. every time a mutex is locked or unlocked, a single master data structure has to be updated, which requires a global lock/unlock. |
| 21:30.44 | jsmith | That's what I was afraid of |
| 21:31.04 | jsmith | So I can turn it on and get better debugging for deadlocks, but then I have have too much load on the system :-( |
| 21:39.03 | mjordan | jsmith: alas for no free lunches :-( |
| 21:39.15 | jsmith | mjordan: No kidding, right? |
| 21:39.20 | jsmith | Oh well -- we'll figure this out |
| 21:39.37 | jsmith | Had two more segfaults this morning (both with similar backtraces to the ones from last week) |
| 21:39.49 | jsmith | and a report of a deadlock over the weekend :-( |
| 21:41.13 | jsmith | mjordan: Would it be helpful at all to include the latest backtrace, or would you agree with me that there's still too little information in the backtraces to make them worthwhile? |
| 21:43.35 | mjordan | jsmith: I'm curious - have you tried running with just DONT_OPTIMIZE? That should help with the gdb backtraces |
| 21:43.53 | mjordan | even if you can't turn on DEBUG_THREADS, that would still improve the backtraces obtained |
| 21:43.54 | jsmith | I thought we were running with that, but I'll confirm |
| 21:44.06 | jsmith | (and I'm asking them to turn on BETTER_BACKTRACES as well, fwiw) |
| 21:44.12 | mjordan | yay :-) |
| 21:45.06 | jsmith | I'll go ahead and upload the backtrace anyway -- someone else can delete it from the ticket if they so choose |
| 22:03.11 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-sgkklxhjhcfxdhpv) |
| 22:06.01 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 22:15.52 | *** join/#asterisk-dev jpepper (~jpepper@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 22:23.35 | *** join/#asterisk-dev sjennings (~sjennings@2001:470:1f0f:87d:546f:3f9c:a786:2e7e) |
| 22:23.53 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 22:23.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:25.29 | sjennings | hi, i was wondering if there was any known issue with chan_motif and google voice. i followed the documentation it won't create the Motif channel because it can't find my xmpp endpoint. I ask here because chan_motif is in beta right now afaik. |
| 22:26.45 | sjennings | i'm running Asterisk 11.0.0-beta1 compiled from the source tarball |
| 23:02.18 | *** join/#asterisk-dev lathama (62ce5875@gateway/web/freenode/ip.98.206.88.117) |
| 23:21.58 | lathama | Question about large patches. eg... 1237 lines in 69 files |
| 23:22.06 | lathama | anyone on? |
| 23:23.44 | sruffell | Yikes..no way to break it up? |
| 23:26.52 | lathama | https://issues.asterisk.org/jira/browse/ASTERISK-20259 |
| 23:27.20 | lathama | I can break it up, I just wonder if I should do it per file or per folder? |
| 23:29.13 | lathama | s/folder/directory/ |
| 23:34.08 | sruffell | Can you break it up logically? I think it's ok to touch that many files if what is being changed is very self contained. That should make reading the patch relatively easy…but that's just my opinion. |
| 23:34.53 | sruffell | I.e….still might touch 69 files…but one patch wouldn't necessarily need to be 1237 lines. |
| 23:34.57 | lathama | I agree |
| 23:36.04 | lathama | I can do it by directory, by file and the whole diff and attach the files. Let the committer decide. |
| 23:37.23 | sruffell | Or…you could break it up by doxygen warning type... |
| 23:37.58 | sruffell | empty tags in one…xml escape issues in another, etc.. |
| 23:37.59 | lathama | I could do it by developer listed as author... that would be fun... |
| 23:38.01 | sruffell | across the entire tree. |
| 23:38.20 | sruffell | eh, don't mind me..perhaps I'm not following. |
| 23:39.10 | lathama | its ok, spend several hours fixing other peoples tags for doxygen and you have a sour opinion.... |
| 23:39.12 | lathama | other topic |
| 23:39.13 | lathama | https://wiki.asterisk.org/wiki/display/AST/Modules |
| 23:39.36 | lathama | I would like to clean this up, I talked with Matt about it. |
| 23:39.39 | sruffell | I take it you don't use git either? |
| 23:39.55 | sruffell | Makes creating patch series less infuriating. |
| 23:40.05 | lathama | I can use git, the Asterisk Development guidelines point at SVN |
| 23:40.06 | sruffell | ..at least for me. |
| 23:40.25 | sruffell | true….but nothing prevents you from using git as a front-end. I need to write up how I do that sometime, for Asterisk specifically. |
| 23:40.41 | sruffell | I'm not suggesting you go out and do that now by the way… |
| 23:41.12 | lathama | Example of load_modules issue, res_config_ldap attempts to connect to a server even when set to null, so during a default install and startup there is an error |
| 23:41.52 | lathama | So I am looking at cleaning it up, I look for the gold standard and find a mess. |
| 23:42.19 | lathama | is the wiki page an ok start for a guide or am I missing some underlying logic? |
| 23:42.20 | sruffell | heh |
| 23:42.52 | sruffell | I'm not heavily involved in Asterisk, so I can't really give you good advice. Now if you wanted to know about DAHDI in the kernel I could hook you up. |
| 23:43.39 | lathama | Ok, on DAHDI are you using doxygen or any other docs? When will we add a Wiki section for DAHDI? |
| 23:44.16 | kpfleming | lathama: ping mjordan about config stuff... twilson just built a new config framework, and the only modules that have been converted are main/udptl.c apps/app_skel.c |
| 23:44.32 | kpfleming | so there is a new 'best practice' for how to handle parsing and validating configs |
| 23:44.52 | lathama | app_skel.c had one of the problems I am trying to fix.... |
| 23:45.09 | lathama | I did my homework first |
| 23:45.29 | sruffell | Those functions that are documented would use kernel-doc, and not doxygen. The coding guidelines likewise follow the kernel conventions. As far as a wiki section, that's a good question. Someone would need to create a space for it. But otherwise, the docs are included in the source currently. |
| 23:46.33 | lathama | cool on the docs sruffell |
| 23:47.41 | lathama | ok, I will carry on with my tree. |
| 23:52.59 | kpfleming | lathama: i was referring to trunk/asterisk-11 |
| 23:53.08 | lathama | yup |
| 23:54.18 | lathama | I already talked to mjordan and he suggested the IRC to get other dev's thoughts |
| 23:56.12 | file | sjennings, not being able to find your XMPP endpoint would be a configuration issue probably - it needs to be configured in xmpp.conf and the name of it used in the motif.conf entry as the connection |