| 00:00.19 | rmudgett | gtjoseph: I tried the following combinations: configure with no chan_sip or pjsip, configure with chan_sip and pjsip, configure --with-pjproject-bundled with chan_sip and pjsip. |
| 00:00.41 | gtjoseph | and? |
| 00:01.07 | rmudgett | When I didn't have pjproject bundled and without chan_sip or pjsip loaded, I got pjproject init messages on startup |
| 00:01.26 | rmudgett | It seems to be the only oddity |
| 00:01.50 | gtjoseph | well, you still have pjproject installed system wide right? So res_pjproject picked that up. |
| 00:02.22 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-nfmyibbtgcamfgpp) |
| 00:02.23 | gtjoseph | and did yo do an uninstall between tries? |
| 00:02.30 | rmudgett | make distclean |
| 00:02.38 | gtjoseph | if not, libasteriskpj.so is probably still there |
| 00:05.08 | rmudgett | Yeah. make distclean does not remove the libasteriskpj or libasteriskssl files |
| 00:05.16 | rmudgett | installed files |
| 00:05.44 | gtjoseph | it should remove them from main, just not your system library. :) |
| 00:09.44 | rmudgett | ah I should be using make uninstall as well |
| 00:18.47 | gtjoseph | thanks file :) |
| 00:31.39 | gtjoseph | file: another question on expected blond transfer behavior if you've got a minute... |
| 00:45.15 | file | if it can be answered in a half unconscious state, maybe! |
| 00:53.21 | gtjoseph | we'll chat tomorrow. :) |
| 01:02.54 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-xghohxshpijahzyu) |
| 02:24.49 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |
| 05:35.37 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 05:41.20 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 06:34.53 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 06:34.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:19.05 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-irisbnmxumksdnzb) |
| 07:22.23 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 07:50.49 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 07:55.32 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:13.30 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:13.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:16.22 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:49.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:48.01 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |
| 12:55.59 | hexanol | wdoekes: thanks, I'll test it out |
| 12:56.22 | hexanol | in theory, I think there might still be an issue with the reference to the channel |
| 12:56.43 | hexanol | i.e. the code might hold a pointer to a channel that has no reference left (i.e. that has been ast_channel_unref'ed) |
| 12:57.16 | wdoekes | I hope not, but I did not check the code ref/unref paths |
| 12:57.31 | hexanol | in ast_autochan_channel_lock, the code gets the value of autochan->chan |
| 12:57.46 | hexanol | and then try to lock that channel, and then test it ifautochan->chan has changed |
| 12:57.53 | hexanol | if it does has changed |
| 12:58.16 | hexanol | then that means that |
| 12:58.23 | hexanol | the previous value of autochan->chan |
| 12:58.28 | hexanol | has been unreffed |
| 12:58.39 | hexanol | by the ast_autochan_new_channel function |
| 12:58.50 | wdoekes | yes, at least once. but I can't say for sure that it was decremented to 0 |
| 12:58.50 | hexanol | when it updated the autochan->chan pointer (I believe) |
| 13:01.56 | hexanol | and then, in ast_autochan_channel_lock, when ast_channel_unlock is called, it might be on channel that has been freed (in the case the channel ref count did reach 0 between this time, which I guess might not happen in practice, but the problem might exist in theory, if my understanding is correct) |
| 13:02.54 | wdoekes | correct. not only ast_channel_unlock, it could even be on the first ast_channel_lock. |
| 13:03.47 | hexanol | yep |
| 13:04.29 | wdoekes | it depends on whether that unref might be the last. which I don't know right now. but it's certainly a possibility that should be examined |
| 13:05.30 | wdoekes | I thought I'd poke rmudgett about this when he gets in. if you can share results about the workings of the suggested patch, that'd be nice |
| 13:07.00 | hexanol | ok, I'll try it out |
| 13:07.17 | hexanol | your patch was done on the master branch ? |
| 13:07.22 | wdoekes | no, on 11 |
| 13:07.26 | hexanol | alright |
| 13:14.13 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |
| 13:20.06 | hexanol | wdoekes: so I just did a few tests with a patched Asterisk 11, and before the patch, I was able to make it freeze systematically (by adding a sleep(1) in ast_do_masquerade, just before the call to ast_autochan_new_channel), and once the patch is applied, I can't reproduce it |
| 13:30.46 | wdoekes | good to know, thanks :) |
| 13:58.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:09.47 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-oddlnszywbnztzum) |
| 14:09.47 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:32.39 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:32.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:10.12 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zqpjrtaeatxhdqek) |
| 15:13.33 | *** part/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 15:24.03 | *** join/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:24.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:30.51 | *** part/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:31.01 | *** join/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:31.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:45.04 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:45.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:54.41 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bazvefoxswwiehkh) |
| 15:57.08 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:57.08 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:04.44 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 16:10.35 | wdoekes | rmudgett: I'd appreciate it if you could take a look at ASTERISK-25321. I think it might be up your alley |
| 16:12.17 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ajiecpzehxuemsgb) |
| 16:23.14 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:23.14 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:46.23 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:46.23 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:50.41 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qirrpkolfqubhzif) |
| 17:21.34 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:22.39 | gtjoseph | ok you python experts... why does 'sys.path.append("lib/python")' result in 'ImportError: No module named version' but sys.path.insert(0, "lib/python") works? |
| 17:23.19 | gtjoseph | why would having lib/python at the beginning on the path work but not at the end? |
| 17:33.00 | wdoekes | shouldn't. you have something more insidous going on. possibly with a version somewhere that itself raises an importerror? |
| 17:33.39 | file | gtjoseph, if you find out do tell me... cause I have that problem |
| 17:33.58 | gtjoseph | it an import of 'from asterisk.version import AsteriskVersion' |
| 17:34.13 | gtjoseph | and there's no other 'asterisk' in my path. |
| 17:34.17 | gtjoseph | it's weird. |
| 17:34.27 | file | yes, it's very weird |
| 17:34.33 | file | I explicitly set PYTHONPATH to work around it |
| 17:34.58 | gtjoseph | yep that's what I have to do. |
| 17:35.52 | gtjoseph | makes it hard to test new modules though because i don't know if it's going to be found in othe renvironments. |
| 17:42.09 | wdoekes | and if you also append sys.path.append('lib/python/asterisk') ? |
| 17:49.39 | gtjoseph | nope |
| 17:51.11 | gtjoseph | it must be something in my system path because it works on another machine |
| 17:51.55 | file | gtjoseph, what distro and version? |
| 17:52.21 | gtjoseph | Fedora 23, python 2.7.10 |
| 17:52.30 | gtjoseph | looking through my path now |
| 17:52.32 | file | Ubuntu 15...10? I think, here |
| 17:52.42 | file | also python 2.7.10 |
| 17:52.44 | gtjoseph | lots of old junk |
| 17:52.51 | gtjoseph | including RBTools :) |
| 19:14.33 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |
| 19:14.54 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-oiaulpwuemyfdtxq) |
| 20:55.32 | *** join/#asterisk-dev klow (~klong@73.53.31.109) |
| 20:58.25 | klow | gtjoseph - in the pjproject TLS fix , is the decision to make a new TLS transport connection or not based solely on if an existing TLS connection exists to the endpoint, or is it based on the endpoint's responsiveness to an "OPTIONS" command or some other availability check .. ? |
| 20:59.07 | gtjoseph | solely on a connection currently being open |
| 20:59.40 | klow | got it . OK still trying to figure this out on my end |
| 20:59.48 | gtjoseph | try this... |
| 20:59.54 | klow | thanks for your help on the mail list. if any other info I can give please let me know |
| 21:00.50 | gtjoseph | no problem. if you just cloned asterisk 13, run ./configure --with-pjproject-bundled <and any other options you normally use> |
| 21:01.16 | klow | ok. have not passed any options to asterisk 13 configure script |
| 21:01.18 | klow | previously |
| 21:01.21 | gtjoseph | that will automatically pull down pjproject 2.4.5 and apply the patches and statically link it to asterisk |
| 21:01.29 | gtjoseph | this one is new |
| 21:02.18 | gtjoseph | with this option, you don't have to worry about compiling or installing pjproject separately |
| 21:03.14 | klow | ah that is nice |
| 21:03.56 | klow | did you up the IOQUEUE value whatever that was.. for more connections |
| 21:03.57 | gtjoseph | the best part is that when you ask questions, I know exactly how it was configured and built. :) |
| 21:04.05 | gtjoseph | yes |
| 21:04.31 | gtjoseph | and changed the polling mechanism from select to epoll. 5000 connections now allowed |
| 21:05.00 | klow | compiling now |
| 21:06.28 | klow | [pjproject] Compiling python bindings |
| 21:06.28 | klow | Makefile:83: recipe for target 'source/pjsip-apps/src/python/build/_pjsua.so' failed |
| 21:06.52 | gtjoseph | weird |
| 21:07.27 | gtjoseph | what distro? do you have python-devel (or equivalent) installed? |
| 21:08.15 | klow | debian jessie 8.2 |
| 21:08.36 | hexanol | (I'm out. Thank you for the help on chanspy/autochan issue wdoekes!) |
| 21:08.50 | klow | got python stuff installed but nothing that says -dev or -devel |
| 21:09.41 | gtjoseph | i think you need python-dev. |
| 21:10.00 | gtjoseph | i'll have to add a check for that and disable those apps if it's not found. |
| 21:10.33 | klow | k trying again thanks. |
| 21:21.01 | klow | gtjoseph: first test calls are working :) |
| 21:21.09 | gtjoseph | yay! |
| 21:24.03 | klow | awesome. thanks again. this has been tricky. trying to develop a simple pbx system and wanted to use pjsip , but my deployment scenario is mobile apps .. cannot control the NAT at all so these fixes are a big help. |
| 21:24.18 | gtjoseph | excellent. |
| 21:39.58 | *** join/#asterisk-dev doome_ (~doome@94-21-148-183.pool.digikabel.hu) |
| 21:49.22 | gtjoseph | file: check to see if you have a /usr/lib/python2.7/site-packages/asterisk directory :) |
| 21:51.53 | file | let's see |
| 21:52.17 | file | I don't |
| 21:52.31 | gtjoseph | check other places in sys.path |
| 21:52.35 | gtjoseph | that was my problem |
| 21:52.52 | file | ack |
| 21:53.06 | gtjoseph | PYTHONPATH gets processed first so that's why it works. |
| 22:01.45 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:09.52 | *** join/#asterisk-dev acidfoo_ (~acidfoo@108.175.228.140) |