| 01:44.15 | *** join/#asterisk-dev Ta^3 (n=tacvbo@189.146.189.241) |
| 02:29.23 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 03:45.22 | *** join/#asterisk-dev dlynes (n=daniel@bas5-hamilton14-1242444747.dsl.bell.ca) |
| 03:51.52 | dlynes | M15846 |
| 03:52.04 | MuffinMan | [new] [Asterisk] Core/Configuration 0015846: Asterisk is looking in the wrong location for the asterisk.pid (and probably asterisk.ctl) file. reported by dlynes (Karma: neutral) https://issues.asterisk.org/view.php?id=15846 |
| 04:23.08 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 04:45.50 | *** join/#asterisk-dev work|philipp64 (n=chatzill@mail.redfish-solutions.com) |
| 04:57.10 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 04:59.23 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-173-130.xd-dynamic.ctbcnetsuper.com.br) |
| 05:11.53 | work|philipp64 | seanbright: got a question for you if you're around... |
| 05:12.31 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 05:17.02 | work|philipp64 | mnicholson: got a minute? |
| 05:20.27 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 05:52.20 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 05:52.27 | jmls | morning all |
| 05:53.49 | snuff-work | ello jmls |
| 05:59.29 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:30.35 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:30.35 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:32.16 | work|philipp64 | morning. |
| 06:35.07 | work|philipp64 | anyone notice that the new stdexten in 1.6.1.6 behaves differently? |
| 06:36.20 | snuff-work | nope |
| 06:36.38 | snuff-work | not listed in CHANGES or UPGRADE docs that it was changing? |
| 06:37.03 | work|philipp64 | http://svn.digium.com/view/asterisk?view=rev&rev=152765 |
| 06:37.32 | work|philipp64 | I forget what bug this was supposed to be fixing. |
| 06:38.41 | work|philipp64 | it works in one context, but not another... and I can't figure out what the difference is that is breaking it. |
| 06:39.53 | snuff-work | mm so if u swapped which had the 'stdexten' policy does it work |
| 06:39.55 | snuff-work | ? |
| 06:40.52 | work|philipp64 | you lost me. |
| 06:42.06 | snuff-work | maybe i've forgotten how stdexten works :) |
| 06:43.51 | work|philipp64 | Gosub(stdexten(6000,SIP/office_2)) |
| 06:44.49 | snuff-work | so do both contexts include 'stdexten' |
| 06:45.05 | snuff-work | or is there a 'super context that includes stdexten |
| 06:45.19 | work|philipp64 | I think so... assuming that you can nest includes. |
| 06:45.29 | snuff-work | yes |
| 06:45.47 | work|philipp64 | redfish-pstn does a "include => redfish-extens" which does a "include => stdexten" |
| 06:46.38 | snuff-work | shld be ok then |
| 06:47.24 | work|philipp64 | but I'm seeing: |
| 06:47.50 | work|philipp64 | <PROTECTED> |
| 06:47.51 | work|philipp64 | [Sep 8 00:47:38] NOTICE[7493]: pbx.c:3233 pbx_extension_helper: No such label 'stdexten' in extension 's' in context 'redfish-pstn' |
| 06:47.53 | work|philipp64 | [Sep 8 00:47:38] WARNING[7493]: pbx.c:8998 pbx_parseable_goto: Priority 'stdexten' must be a number > 0, or valid label |
| 06:47.54 | work|philipp64 | [Sep 8 00:47:38] ERROR[7493]: app_stack.c:279 gosub_exec: Gosub address is invalid: 'stdexten(111,SIP/bedroom_1&SIP/office_2&SIP/remote_2&SIP/kitchen_1&Local/@follow-me&SIP/softphone,redfish)' |
| 06:49.21 | work|philipp64 | internally, it seems to work: |
| 06:50.03 | work|philipp64 | <PROTECTED> |
| 06:50.05 | work|philipp64 | <PROTECTED> |
| 06:50.07 | work|philipp64 | ... |
| 06:50.25 | work|philipp64 | it's just for external calls in a different context that it gets buggered up. |
| 06:50.40 | work|philipp64 | but both end up doing the "include => redfish-extens", so I'm boggled. |
| 06:51.02 | snuff-work | is the include above or below the calls to stdexten? |
| 06:51.12 | work|philipp64 | below. |
| 06:52.16 | snuff-work | mm that might be ur problem.. i say might.. generally from my very hazy memory includes should be at the top of a context |
| 06:56.46 | work|philipp64 | no change. |
| 06:57.52 | mvanbaak | mornin all |
| 06:58.16 | work|philipp64 | goude morgen |
| 07:00.11 | work|philipp64 | maybe I'll wait for tilghman to appear.. |
| 07:00.40 | work|philipp64 | it was working prior to his rewriting of [stdexten] |
| 07:01.10 | snuff-work | mm k ;) |
| 07:01.30 | work|philipp64 | unless you've got another idea... |
| 07:01.51 | work|philipp64 | it's 1am mountain, and I should be shuffling off... |
| 07:02.41 | snuff-work | mm it will be another 7hrs before that happens here :) |
| 07:03.00 | work|philipp64 | before you have another idea? |
| 07:06.50 | snuff-work | nope before its 1am |
| 07:07.08 | snuff-work | it will be 1am on the 9th of 9th 09 |
| 07:13.19 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:48.16 | work|philipp64 | snuff-work: where are you? |
| 07:49.06 | snuff-work | australia |
| 08:15.07 | mvanbaak | hhmm, 1.2.13 is not capable of doing video with the latest grandstream gxv3140 |
| 08:22.27 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 08:45.30 | fiddur | Wouldn't it be nifty to be able to set devstate for Local/... devices? |
| 08:49.28 | fiddur | ...that way, you can add Local devices to a queue, and easily set inuse etc on them :) |
| 09:01.58 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 11:25.38 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:25.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:35.23 | mvanbaak | meh, there we go again. |
| 12:35.40 | mvanbaak | for some reason my asterisk is not sending a PONG reply when it receives a POKE |
| 12:36.12 | mvanbaak | but it does send an ACK when it receives a PONG on a POKE |
| 12:36.42 | mvanbaak | does anyone know what can cause this behaviour ? |
| 12:37.02 | mvanbaak | it's not a deadlock (at least 'core show locks' does not show anything) |
| 12:49.38 | kpfleming | no obvious answer no |
| 12:53.02 | kpfleming | there won't be any locks associated with POKE/PONG, they aren't connected to channels |
| 13:00.24 | *** join/#asterisk-dev josh74 (n=chatzill@c-71-232-174-224.hsd1.ma.comcast.net) |
| 13:01.11 | tzafrir_laptop | Anybody still uses chan_phone? (it fails building here) |
| 13:01.45 | kpfleming | doubtful |
| 13:02.00 | josh74 | Hi - I was testing out the fix for issue 15109(the format_mp3 memory corruption bug) and I was getting distorted audio on all mp3 files. I took a closer look at the change and it looks like the switch to using theAST_FRAME_SET_BUFFER macro is causing an offset into the data by 64 bytes due to setting it to AST_FRIENDLY_OFFSET. When I looked at the description of the patch/fix, it seemed to... |
| 13:02.01 | josh74 | ...say that format_mp3 didn't use AST_FRIENDLY_OFFSET, so I'm wondering if simply changing the offset to 0 in the macro call will fix it or if there is something else that would need to be done? |
| 13:02.41 | kpfleming | can you just try changing that and report the results? |
| 13:03.05 | josh74 | i did - it fixes the issue. I'm just not sure if the resetting the offset to 0 will cause any other issues later. |
| 13:04.04 | kpfleming | it should not... but in any case, you need to open an issue to report the problem and the suggested solution |
| 13:04.14 | kpfleming | the developers can then determine whether it could cause any other problems |
| 13:04.29 | josh74 | alright - I'll do that. Thanks. |
| 13:06.35 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 13:06.58 | tzafrir_laptop | /usr/include/bits/string3.h:82: error: call to â__warn_memset_zero_lenâ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters |
| 13:07.12 | tzafrir_laptop | That's for channels/chan_phone.c:810 |
| 13:07.29 | tzafrir_laptop | basically it's a memset with a size 0 |
| 13:07.43 | tzafrir_laptop | Which is pointless |
| 13:07.50 | kpfleming | sounds like it needs to be fixed |
| 13:08.42 | kpfleming | that code is seriously broken |
| 13:08.47 | kpfleming | it's trying to memset beyond the end of the buffer |
| 13:09.36 | kpfleming | well, sort of. it's confusing, to say the least. |
| 13:10.37 | kpfleming | it's badly broken |
| 13:10.38 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 13:10.46 | kpfleming | i would just make it defaultenabled=no |
| 13:12.44 | *** join/#asterisk-dev c4rg (i=crg@lagoon.freebsd.lublin.pl) |
| 13:13.50 | c4rg | hello, is likely that sometimes asterisk will delay IAX packets because of some locking issue? |
| 13:14.40 | c4rg | lastest 1.4 |
| 13:15.53 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:15.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:30.00 | *** join/#asterisk-dev viraptor (n=viraptor@87-194-164-154.bethere.co.uk) |
| 13:30.34 | seanbright | interesting loader bug... running install of asterisk, rebuild app_queue.so, cp app_queue.so to asterisk modules directory, go back to asterisk CLI and type mo<tab> |
| 13:30.38 | seanbright | server goes bye bye |
| 13:30.44 | seanbright | (this is 1.6.1 svn) |
| 13:34.37 | kpfleming | really? that shouldn't be possible |
| 13:34.48 | kpfleming | well, wait |
| 13:34.51 | kpfleming | that depends |
| 13:34.51 | seanbright | which part shouldn't be possible? |
| 13:35.04 | kpfleming | did you copy over the existing file, or unlink the old file and create a new one in its place? |
| 13:35.24 | kpfleming | if you copy over an existing shared object file, then you'll get breakage... that is not asterisk's problem |
| 13:36.14 | seanbright | gotcha |
| 13:36.15 | seanbright | k |
| 13:36.19 | seanbright | i just copied over it |
| 13:36.28 | kpfleming | that's why 'install' always unlinks the old file and puts the new one there |
| 13:36.38 | kpfleming | so the old one is still around for existing programs to use, but new loads get the new one |
| 13:36.42 | seanbright | aha. i hadn't looked. i assumed it was a straight cp. |
| 13:36.59 | kpfleming | yeah, dynamic linking can be tricky business |
| 13:37.14 | kpfleming | try that with /lib/libc.so and watch your system explode :-) |
| 13:37.25 | kpfleming | sorry, /usr/lib/libc.so |
| 13:37.56 | seanbright | heh |
| 13:40.30 | tzafrir_laptop | res_limit.c:26:1: error: "_XOPEN_SOURCE" redefined |
| 13:41.19 | mvanbaak | hands leifmadsen a nice glass of chardonay |
| 13:41.19 | viraptor | I'm not sure if anyone will be interested, but I've created a module that solves some of our sip clustering needs (transfers to another node, where all nodes use the same from_domain, huntgroups and other nasty stuff)... I'd be happy to see something like that (maybe through dundi? or any other way really) added to the official releases at some point... |
| 13:41.19 | viraptor | I don't want to post the patch on -dev, because someone might want to use it in a more generic asterisk installation and will only get problems ;) |
| 13:41.35 | leifmadsen | mvanbaak: nice! It's a bit early here, but I'll save it for later :) |
| 13:43.26 | viraptor | anyone wants to have a look and see if that's possible to do in "main" one day? (1.8? ;) ) |
| 13:43.27 | tzafrir_laptop | ah, ok. it's "redefined" in res_limit.c |
| 13:44.12 | leifmadsen | viraptor: there will probably never be a 1.8 -- you mean trunk (which would become 1.6.latest+1.0 |
| 13:44.17 | leifmadsen | fyi |
| 13:44.54 | viraptor | s/1.8/${new version}/ ;) |
| 13:50.40 | tzafrir_laptop | M15851 |
| 13:50.42 | MuffinMan | [assigned] [Asterisk] Resources/res_limit 0015851: [patch] res_limit.c: refinition of _XOPEN_SOURCE reported by tzafrir (Karma: +121.50) https://issues.asterisk.org/view.php?id=15851 |
| 13:52.55 | *** join/#asterisk-dev mnt_real (n=sinan@bas12-montrealak-1167977240.dsl.bell.ca) |
| 13:54.54 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 13:54.54 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:01.23 | kpfleming | tzafrir_laptop: you can just fix stuff like that, there's no need to waste the time creating an issue for it |
| 14:01.35 | tzafrir_laptop | kpfleming, I can't |
| 14:01.45 | kpfleming | i can fix that |
| 14:08.40 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 14:31.00 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:31.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:31.59 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:32.02 | mvanbaak | The_Boy_Wonder: thank you |
| 14:34.22 | The_Boy_Wonder | mvanbaak: np :) i'm still confused on how any of my tests worked with that messed up |
| 14:34.41 | mvanbaak | The_Boy_Wonder: lol, I wonder as well |
| 14:40.57 | mvanbaak | ah well, it's fixed now |
| 14:45.38 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:45.38 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:46.12 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:46.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:52.01 | tzafrir_laptop | Why does res_limit.c set _XOPEN_SOURCE to 600 in the first place? |
| 14:53.53 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 14:58.03 | tzafrir_laptop | Does res_limit have any build dependency on something from later POSIX that is not available on some systems? |
| 15:00.33 | tzafrir_laptop | Corydon76-dig, ==^ |
| 15:03.58 | oej | putnopvut around? |
| 15:04.06 | putnopvut | oej: I am |
| 15:04.34 | oej | Time to discuss an issue? |
| 15:06.20 | putnopvut | oej: sure, it will be nice to look at SIP again for a few minutes. What's up? |
| 15:07.40 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:07.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:13.30 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:13.30 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:20.25 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:24.42 | oej | putnopvut: sorry, got sidetracked by that jtodd type. |
| 15:24.52 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 15:24.53 | oej | putnovput: It's about that stuff I wrote on the mailling list |
| 15:25.09 | putnopvut | oej: Is it the stuff about the REGISTER behavior? |
| 15:25.27 | oej | Yes, and the ugly code in sip_xmit() |
| 15:25.43 | oej | It causes a lot of issues and I can't simply understand that patch... |
| 15:26.02 | c4rg | anthm: neat quit reason ;) |
| 15:26.11 | putnopvut | oej: Let me find the issue that was fixed by that code. Hold on a second. |
| 15:26.17 | c4rg | avoiding initial deadlock.. mmm... |
| 15:26.29 | oej | In my second mail, I found the commit and the reviewboard URL |
| 15:26.37 | oej | SOmething about DNS failing |
| 15:28.01 | putnopvut | oej: Yeah, the problem, iirc, was that we would do an SRV lookup to find where to send the REGISTER to, but then when the REGISTER failed, we didn't do another SRV lookup in order to try sending to a new address. |
| 15:28.32 | putnopvut | The sentiment on that issue was that the problem was on the provider's end, but that it didn't hurt to do a new SRV lookup if the initial registration failed. |
| 15:28.48 | oej | But why do a retry in 1 millisecond, and why not read the return code from sip_xmit/sendrequest - but hack in the middle of sip_xmit? |
| 15:29.28 | putnopvut | The 1 millisecond thing is a hacky way of saying try retransmitting as soon as possible. |
| 15:29.28 | oej | Because this is activated when there's no route too and you keep trying forever... |
| 15:29.41 | oej | You need a counter - and don't dare adding that to sip_xmit () :-) |
| 15:30.20 | putnopvut | Yeah, if it's causing problems, I'm honestly all for ripping that entire commit out. |
| 15:30.27 | oej | I think we should try to move that code back to do_register and take it out of sip_xmit. Retransmission scheduling does not belong there. |
| 15:30.53 | putnopvut | Sure, and the counter idea makes perfect sense. |
| 15:30.54 | kpfleming | there shouldn't be any method-specific code in sip_xmit() at all unless it cannot be avoided |
| 15:30.57 | oej | If you want to schedule another try, do it in the do_register code, which btw does not read any return codes from sendrequest |
| 15:31.39 | oej | Well, it can. You should have spotted that the do_register functions does NOT read return values and handle retries. Move it there and make sure you only retry once! |
| 15:32.25 | oej | If you should retry at all... |
| 15:32.39 | oej | Which is an interesting issue. |
| 15:32.50 | oej | What DNS on the providers end would be fixed in that short interval? |
| 15:33.00 | oej | SIP register will retry anyway |
| 15:33.52 | oej | I guess we can just rip it out. |
| 15:34.14 | putnopvut | The problem was that the provider returned multiple records on an SRV lookup. |
| 15:34.37 | putnopvut | We only try the top weighted (or top priority or whatever it's referred to as) record. |
| 15:35.27 | putnopvut | The thing is that somehow, usually do to the way that gethostbyname works, we would end up trying the second record after the new lookup. |
| 15:35.33 | putnopvut | s/do/due |
| 15:37.40 | oej | Well, if that's the issue, we should backport soem proper DNS srv code. |
| 15:38.10 | putnopvut | There's nothing to backport, though. |
| 15:38.26 | putnopvut | In trunk, we still don't failover to lower priority SRV records. |
| 15:38.36 | oej | Well, there is code that sorts DNS SRV properly in 1.6 - which is a good start |
| 15:38.47 | oej | No, I was working on failover today... |
| 15:38.47 | putnopvut | That same code is in 1.4, too (I think). |
| 15:38.48 | kpfleming | sorting |
| 15:39.02 | kpfleming | it has sorting, but not failover to lower-weighted records |
| 15:39.14 | oej | No, the sorting code is nowhere in 1.4. I have a backport that I need to sort out. |
| 15:39.19 | kpfleming | oh, right |
| 15:39.20 | oej | Unless it was committed recently |
| 15:39.30 | putnopvut | oej: what about in main/srv.c::process_weights() ? |
| 15:39.44 | oej | Hmm. Interesting. |
| 15:39.55 | oej | needs to go back and check properly later |
| 15:39.59 | oej | Anyway, back to the issue. |
| 15:40.29 | oej | I don't think randomly retrying hoping that the resolver will give us another entry with 1 ms between tries will help. |
| 15:41.14 | putnopvut | And I think that is a perfectly valid thought process. |
| 15:42.20 | putnopvut | Like I said before, the original issue was that we were trying to bend our behavior due to a buggy provider. Really, though, I'm all for ripping that commit out completely since it seems to be causing more problems than it fixes. |
| 15:43.02 | oej | Then I am behind you in ripping it out! Deal is closed and we'll celebrate the decision next week in New Hampshire! |
| 15:43.13 | putnopvut | oej: I'm looking forward to seeing you there! |
| 15:43.29 | oej | We can have fun with a few of my branches :-) |
| 15:43.34 | putnopvut | oej: and thank you for your code cleanup over the weekend. It is very nice. |
| 15:43.52 | oej | Thanks... I gotta come back into chan_sip in trunk, have avoided it for a while. |
| 15:43.57 | oej | And it was cleaning-up time :-) |
| 15:44.13 | oej | The branch of the day is pinerequestpacket. |
| 15:44.27 | oej | I remember that I merged the sip_request and sip_pkt in chan_sip3/pineapple |
| 15:44.33 | oej | So I'm trying to do that again. |
| 15:45.11 | oej | It is confusing to have one structure for the incoming and another for outbound SIP messages |
| 15:45.37 | oej | I think there are things we can simplify by uniting them. |
| 15:46.19 | putnopvut | Yes, I have been bitten by that before, specifically trying to analyze a sip_request for an outbound message. |
| 15:46.27 | oej | dvossel: Now it's your time to laugh at this old man who made a fool of himself ... Sorry. |
| 15:46.48 | oej | I made a bit of an ugly hack right now for testing but it seems to work. |
| 15:47.43 | oej | Hmm. The bot for asterisk-commits seems to have a very long labour weekend... |
| 15:50.13 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:54.57 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:54.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:01.59 | oej | putnopvut: Issue #2 - where you involved in the call pickup for SNOM stuff in trunk? |
| 16:02.07 | oej | Maybe it's in 1.6.x as well... |
| 16:02.16 | putnopvut | I think that's still only in trunk. |
| 16:02.26 | putnopvut | I've fixed a bug in it, but I didn't write the initial code. |
| 16:02.31 | oej | Ok |
| 16:02.41 | oej | We need to discuss who can pickup what, as I wrote in the mail. |
| 16:02.46 | oej | Can you think about it? |
| 16:02.56 | oej | Right now, if you have proper auth, you can pickup any ringing call |
| 16:03.14 | oej | Which is a bit bad in multi-company pbxs or service provider environments |
| 16:03.31 | oej | We need an option to enable it and an authorization scheme -and we have two to pick from |
| 16:03.40 | kpfleming | shouldn't that only be true if you've subscribed to the dialog-info for the extension the call is ringing on? |
| 16:03.52 | oej | Good that it's only in trunk, then we can discuss it next week |
| 16:04.13 | oej | The code for pickup only checks for "pickup-kpfleming" the magic string and then you can pickup any call to extension "kpfleming" |
| 16:04.21 | kpfleming | hmm |
| 16:04.29 | kpfleming | ok, yeah, that needs some discussion |
| 16:04.34 | oej | We need to check the the person sending the invite can access "kpfleming" in the subscribe context |
| 16:04.49 | oej | And to be fair, we should consider callgroups/pickupgroups |
| 16:05.06 | kpfleming | no, i don't think we can |
| 16:05.09 | oej | I don't see why these pickups should work differently than *8 stuff |
| 16:05.11 | oej | Why not? |
| 16:05.33 | kpfleming | because doing that would require implicit subscriptions to send the dialog-info out to the phone so that it will know there is a call ringing on that group |
| 16:05.36 | oej | The first step, to check for exten in subscribecontext is easy |
| 16:05.39 | kpfleming | yes |
| 16:05.56 | oej | Well, you can still have permission to subscribe, but no permission to pickup |
| 16:06.08 | kpfleming | callgroups/pickupgroups really should go away, IMO |
| 16:06.36 | kpfleming | the same effect can be achieved by creating virtual extensions with properly constructed hints |
| 16:06.54 | oej | Well, then we need to do that. I feel it is bad architecture to have multiple auth systems for pickups... |
| 16:07.16 | kpfleming | does chan_sip even support pickup from callgroup/pickupgroups? |
| 16:07.26 | oej | Call groups doesn't scale, is not implemented in every channel and is not well understood. |
| 16:07.29 | oej | Yes, we have sir. |
| 16:07.31 | kpfleming | correct |
| 16:07.39 | kpfleming | it is not a good design at all |
| 16:07.46 | oej | And we're proud of it, sir! |
| 16:08.01 | kpfleming | so we should come up with example configurations for how to do it properly, and strongly suggest that people stop using the old method |
| 16:08.17 | oej | Ok, we have work to do next week :-) |
| 16:08.39 | oej | So we've decided to go for the subscribecontext scheme. Who did code that stuff anyway? |
| 16:09.21 | kpfleming | i don't remember |
| 16:11.36 | kpfleming | someone out there please ensure you can still access the bugtracker and svn.digium.com |
| 16:11.41 | kpfleming | i've just change the firewall config on that system |
| 16:11.55 | kpfleming | it looks OK from here |
| 16:12.40 | putnopvut | Hmm, I'm running tests in my CCSS branch and getting core dumps. I have selected DONT_OPTIMIZE in menuselect, but the backtraces I get show many values optimized out. Doing a noisy build shows -O0 being used in the utils dir, and both -O2 and -O6 being used elsewhere. |
| 16:13.06 | kpfleming | do you have dev-mode on? |
| 16:13.10 | putnopvut | kpfleming: yes. |
| 16:13.31 | kpfleming | dev-mode + DONT_OPTIMIZE means it compiles twice, and throws away the optimized binary |
| 16:13.31 | kpfleming | so you will see that |
| 16:13.36 | tzafrir_laptop | -O6? |
| 16:13.39 | kpfleming | you should not see values being optimized out |
| 16:13.47 | tzafrir_laptop | Whatever happened to -O3? |
| 16:13.49 | putnopvut | Yes, the initial .c -> .i uses -O2 but the .i ->.o is using -O6 |
| 16:14.01 | kpfleming | tzafrir_laptop: it's always been -O6 in the asterisk build system |
| 16:14.08 | kpfleming | putnopvut: weird |
| 16:14.10 | kpfleming | let me test it |
| 16:14.18 | putnopvut | kpfleming: sure thing. I imagine trunk is the same. |
| 16:14.36 | kpfleming | it better be |
| 16:14.41 | putnopvut | heh :) |
| 16:15.18 | ccesario | hello... somebody can say me is this is "correct" ... http://pastebin.com/m2908a007 |
| 16:15.49 | tzafrir_laptop | Another gcc 4.4 error: res_phoneprov.c:500: error: dereferencing pointer 'name.103' does break strict-aliasing rules |
| 16:16.00 | tzafrir_laptop | This is basically something like http://www.redhat.com/archives/libvir-list/2009-February/msg00257.html |
| 16:16.26 | tzafrir_laptop | The workaround there is to replace the cast with a union that holds both structs |
| 16:16.56 | tzafrir_laptop | I wonder if this isn't too ugly |
| 16:17.59 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:18.02 | kpfleming | putnopvut: this bug was introduced when i modified the build system to allow the user to specify CFLAGS to the configure script |
| 16:18.09 | putnopvut | kpfleming: Okay, taking a closer look at the noisy build, it appears that I mixed up the -Os being used. .c -> .i is -O6 AND -O2, and .i -> .o is using -O2 |
| 16:18.10 | kpfleming | working on a solutionf |
| 16:18.12 | *** part/#asterisk-dev viraptor (n=viraptor@87-194-164-154.bethere.co.uk) |
| 16:18.16 | putnopvut | kpfleming: Thank you. |
| 16:18.19 | kpfleming | for now, you can ./configure CFLAGS="" |
| 16:18.26 | putnopvut | kpfleming: thanks for the workaround too. |
| 16:37.31 | kpfleming | putnopvut: fixed |
| 16:37.51 | putnopvut | kpfleming: Thanks, I'll try it out soonly. |
| 16:37.57 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.227) |
| 17:08.55 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 17:09.04 | seanbright | so how goes the viewvc stuff? |
| 17:09.39 | kpfleming | almost there |
| 17:09.47 | seanbright | eggcellent |
| 17:13.36 | tzafrir_laptop | stupid question: if two modules are loaded "at the same time, will loader.c:load_dynamic_module indicate that loading the first one has failed? (but ast_module_unregister() won't get called) |
| 17:15.31 | tzafrir_laptop | heads home |
| 17:15.54 | kpfleming | loader.c does not support two modules loading at the same time |
| 17:16.01 | kpfleming | and due to an internal lock, it should not be possible |
| 17:22.28 | oej | Hmm. chan_sip doesn't like me removing req->data :-) |
| 17:22.37 | tzafrir_laptop | two 'module load NN' commands running from two different places? |
| 17:22.54 | tzafrir_laptop | Or is there locking at a higher level? |
| 17:23.09 | kpfleming | there is locking in loader.c |
| 17:23.20 | kpfleming | the second command will wait for the first one to finish |
| 17:27.56 | tzafrir_laptop | right. Anyway, there's also the global (static) resource_being_loaded there, so I guess no point worrying about such a race |
| 17:28.05 | kpfleming | yep |
| 17:29.41 | *** join/#asterisk-dev work|philipp64 (n=chatzill@mail.redfish-solutions.com) |
| 17:32.11 | *** join/#asterisk-dev xpot-mobile (n=james@mx0.synergyconsultant.net) |
| 17:41.38 | work|philipp64 | Corydon76-dig: Is there a chance that http://svn.digium.com/view/asterisk?view=rev&rev=152765 introduced some unexpected behavior? I'm having issues with it. |
| 17:42.21 | leifmadsen | #define issues |
| 17:52.45 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.227) |
| 17:57.23 | work|philipp64 | leifmadsen: I posted to asterisk-dev... but in short, in one context the Gosub works fine, and in another it claims: |
| 17:57.25 | work|philipp64 | gosub_exec: Attempt to reach a non-existent destination for gosub: (Context:stdexten, Extension:s, Priority:0) |
| 17:58.06 | work|philipp64 | which would be true: stdexten no longer *does* have an 's' extension. |
| 18:01.44 | *** join/#asterisk-dev tamiel (n=tamiel@ip-7.net-81-220-254.rev.numericable.fr) |
| 18:09.54 | work|philipp64 | I guess tilghman must be on vacation still.... |
| 18:10.31 | work|philipp64 | this was with 1.6.1.6.... |
| 18:10.54 | work|philipp64 | wonders if Mark is around. |
| 18:12.46 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:19.05 | leifmadsen | work|philipp64: he's not |
| 18:19.13 | leifmadsen | he's just in a meeting, and has been working on the bug tracker today |
| 18:35.46 | Corydon76-lap | Which Mark? |
| 18:42.39 | Qwell | Corydon76-lap: the one that's on IRC occasionally :p |
| 18:44.47 | Corydon76-lap | Qwell: occasionally and not often? |
| 18:44.54 | work|philipp64 | Corydon76-lap: Nicholson. |
| 18:45.33 | work|philipp64 | so... what changed behavior could one expect from your modification to stdexten? |
| 18:45.42 | work|philipp64 | wonders if it was something he said. |
| 18:46.48 | Qwell | Corydon76-lap: more than none. |
| 18:49.08 | Corydon76-lap | Mark S is occasionally on IRC |
| 18:53.46 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:54.15 | Qwell | Corydon76-lap: no he's not. his account got deleted in the big idle-nick purge that happened about 3 months ago. |
| 18:55.45 | Qwell | let it be known that cold coffee is really gross |
| 18:55.59 | kpfleming | Qwell: cold, but not iced? |
| 18:57.25 | Qwell | correct, iced coffee is quite good |
| 18:57.48 | work|philipp64 | well, I guess I'm going to have to make the 480 mile drive back and hope I can fix things remotely. |
| 18:58.13 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-jgfiejifbdrpaeuz) |
| 19:00.04 | *** join/#asterisk-dev josh74 (n=chatzill@c-71-232-174-224.hsd1.ma.comcast.net) |
| 19:16.45 | *** join/#asterisk-dev korihor (n=korihor@190.77.83.180) |
| 19:27.16 | oej | kpfleming: Issue #14297 is for you. A change you did changed the behaviour which affected the reporter's platform... |
| 19:27.26 | kpfleming | darn |
| 19:27.48 | kpfleming | M14297 |
| 19:27.50 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0014297: Inband DTMF not working between asterisk servers reported by remiq (Karma: neutral) https://issues.asterisk.org/view.php?id=14297 |
| 19:28.03 | kpfleming | it's closed |
| 19:28.05 | kpfleming | i'm confused |
| 19:28.46 | oej | https://issues.asterisk.org/view.php?id=14927 |
| 19:29.06 | oej | I was the confused one... I reserve that position. |
| 19:29.13 | kpfleming | lol |
| 19:30.39 | kpfleming | oej: so what change did i make that affected that situation? it doesn't come to mind |
| 19:40.44 | oej | Didn't I add a pointer to the list? |
| 19:41.20 | oej | http://lists.digium.com/pipermail/svn-commits/2009-March/045311.html |
| 20:01.12 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 20:01.12 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:10.05 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:35.53 | leifmadsen | Marquis42: ping! |
| 20:37.55 | Marquis42 | leifmadsen: pong |
| 20:38.17 | leifmadsen | Marquis42: I have a possible implementation idea w/r to your XMPP implementation |
| 20:38.26 | leifmadsen | (that was redundant...) |
| 20:38.55 | Marquis42 | heh... OK, I'm happy to hear suggestions. |
| 20:39.56 | leifmadsen | anyways, would your platform be useful for distributed queues in such a way that you had the ability for people to join a queue on multiple machines, but to keep the positions in sync? For example. Caller 1 joins Queue XYZ on box B @ position 1, Caller 2 joins Queue XYZ on box F @ Position 2, etc.... (whereas now, Caller 2 would be Position 1 on Queue XYZ on box F) |
| 20:40.48 | work|philipp64 | Corydon76-dig: got a minute to look at the stdexten issue? |
| 20:41.02 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 20:41.02 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 20:43.06 | Marquis42 | Hrm... I think the technology is fundamentally up to the task, but it would likely require some pretty significant app_queue changes. I do like the idea, however.... |
| 20:43.52 | leifmadsen | ok cool -- I was just curious if your XMPP stuff would be a good basis for such a task, even if it wasn't trivial |
| 20:44.35 | Marquis42 | There are definitely some building blocks upon which this would need to be built, so it's the right direction anyway. But yes, it's definitely a non-trivial addition the current scope of the work. |
| 20:47.23 | Marquis42 | Actually, the more I think about it the work isn't quite as hard as I originally thought (maybe, or maybe I'm wrong... ;) ). It would require defining a new type of event, and making app_queue subscribe to it (and do something useful). Plus, the addition of that event type to the supported events for res_jabber. But all in all, not rocket science. |
| 20:48.06 | Marquis42 | Still not *easy*, exactly, but it doesn't require as much TNT and heavy equipment as I was first imagining. |
| 20:52.15 | jsmith | We've talked about a so-called "distributed" app_queue for a while now |
| 20:52.51 | jsmith | Essentially, app_queue listens for events saying "I've got a free queue member/agent", and routes the call to the proper box |
| 20:54.39 | Marquis42 | I was thinking about hitting it from the other side, the callers. So the events would be "I've got a caller to queue XYZ", and then app_queue can handle that accordingly. To me, it's a parallel of how distributed device state works. |
| 20:55.33 | Marquis42 | But perhaps I'm not thinking my cunning plan all the way through. To be fair, I just started thinking about it a few minutes ago. :) |
| 21:12.19 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) |
| 21:12.31 | Kobaz | i think BASE64_DECODE is broken |
| 21:12.49 | Kobaz | <PROTECTED> |
| 21:12.49 | Kobaz | <PROTECTED> |
| 21:13.17 | Kobaz | member=SIP/203... and after that executes, foo=SIP/203ÿw== |
| 21:13.31 | Kobaz | missing a null pointer at the end of the string? |
| 21:14.13 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 21:18.22 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 21:29.10 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.243.11) |
| 21:44.52 | Kobaz | there's something definitly very very wrong with BASE64_DECODE |
| 21:45.28 | kpfleming | http://76.164.171.234/svn |
| 21:45.42 | kpfleming | give it a try, before i make this live |
| 21:45.51 | Kobaz | me? |
| 21:46.01 | kpfleming | no, anyone in the channel who has been wanting to use viewvc |
| 21:46.06 | Kobaz | oh |
| 21:46.07 | Kobaz | aww |
| 21:46.13 | Kobaz | i thought you fixed base64decode |
| 21:46.26 | seanbright | kpfleming: it's so... beautiful |
| 21:46.28 | Kobaz | i replaced ast_base64decode() with my own version, and it works much better |
| 21:49.01 | Kobaz | i found the problem... ast_base64decode doesn't null-terminate the result |
| 21:49.08 | Kobaz | ...submitting bug |
| 21:50.20 | Kobaz | ah. already a bug |
| 21:50.22 | Kobaz | https://issues.asterisk.org/view.php?id=15271 |
| 22:08.21 | *** topic/#asterisk-dev by kpfleming -> Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 22:08.35 | seanbright | oh happy day |
| 22:08.41 | seanbright | it's like christmas in september |
| 22:15.01 | kpfleming | where do you end up if you follow this link: http://svn.digium.com/svn-view/asterisk?view=rev&rev=182527 |
| 22:15.12 | seanbright | http://76.164.171.234/svn/asterisk?view=revision&revision=182527 |
| 22:15.18 | kpfleming | excellent |
| 22:15.34 | kpfleming | will get a hostname for that box shortly |
| 22:15.40 | kpfleming | well... 'box', since it's a VM |
| 22:15.52 | seanbright | won't be svn.digium.com? |
| 22:15.55 | seanbright | err |
| 22:15.57 | seanbright | i guess it can't be |
| 22:16.05 | kpfleming | svnview.digium.com |
| 22:16.12 | seanbright | cool |
| 22:16.15 | kpfleming | you'll get redirected |
| 22:16.19 | kpfleming | you are now :_) |
| 22:18.12 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 22:22.08 | seanbright | thanks for getting it up and running |
| 22:22.13 | kpfleming | you are welcome |
| 22:22.14 | seanbright | i know lots of people will appreciate it |
| 22:22.18 | work|philipp64 | kpfleming: works for me. |
| 22:22.26 | kpfleming | good |
| 23:02.53 | work|philipp64 | damnation. our phones are going to be down until I figure this one out... |
| 23:36.11 | work|philipp64 | well, I'm going to file a bug against this change. I think it's introduced a regression., |
| 23:39.52 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 23:39.52 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 23:49.46 | work|philipp64 | Hmm... mantis only goes up to 1.6.1.4 for Asterisk bugs... no way to file against 1.6.1.6... |
| 23:50.15 | snuff-work | just file against 1.6.1.4 |
| 23:50.22 | ZX81 | :) Maybe cos 1.6.1.6 has no bugs :D |
| 23:50.33 | snuff-work | and mention in bug report ur using 1.6.1.6 |
| 23:50.50 | snuff-work | i dont recall if there is an option for 1.6.1.x |
| 23:55.45 | ccesario | Hello! |
| 23:56.26 | ccesario | somebody know say me if to each atxfer the asterisk create one channel ? |
| 23:56.43 | *** part/#asterisk-dev ZX81 (n=Matt_Rid@121.74.243.11) |