| 00:17.29 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 00:17.29 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 00:25.50 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 00:36.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 00:59.35 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 02:11.13 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 02:25.14 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:38.17 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 02:38.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:09.59 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 03:09.59 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 04:46.10 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-15.wall.uls.co.za) |
| 05:49.11 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:58.46 | snuff-work | mmm.. why would I be able to 'set' cdr(userfield) but not read it back? |
| 05:58.51 | snuff-work | unless in hangup |
| 05:59.13 | snuff-work | yet core show channel PJSIP/xxxx has no trouble showing the output |
| 06:21.09 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 06:44.20 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 06:48.29 | *** join/#asterisk-dev jkroon (~jkroon@154.73.35.201) |
| 07:11.37 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 07:24.15 | *** join/#asterisk-dev ixyd (~denzs@b2b-46-252-133-250.unitymedia.biz) |
| 07:34.52 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:47.24 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:02.34 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 08:12.45 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:26.41 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:26.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:02.37 | *** join/#asterisk-dev danielyk (~danielyk@p5B21BC6C.dip0.t-ipconnect.de) |
| 11:10.13 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 11:20.02 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 12:11.40 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 13:01.09 | *** join/#asterisk-dev libardi (~kvirc@187.64.232.60) |
| 13:46.40 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 14:07.47 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hgxezaebuwgwaggl) |
| 14:07.47 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:08.46 | *** join/#asterisk-dev jkroon (~jkroon@154.73.35.201) |
| 14:19.27 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-bxtalosjzicmcjqu) |
| 14:19.27 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:20.36 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 15:08.36 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dsdiigsvxxxcyimm) |
| 15:08.36 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:14.10 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:37.11 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:37.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:13.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:22.02 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 16:55.15 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bkjrwmxkkuulrubb) |
| 16:55.15 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 17:41.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0060624b4d6aa367df.ipv6.abo.wanadoo.fr) |
| 19:01.42 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 19:04.10 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-bsakuceqimdbaolv) |
| 19:04.10 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:20.17 | rmudgett | gtjoseph: libasteriskpj cannot do much more than what it is doing right now. If you move the code in res_pjproject into libasteriskpj you will require bundled pjproject to be used |
| 19:20.52 | gtjoseph | why can't is simply read pjproject.conf and set the log level? |
| 19:21.35 | gtjoseph | actually i don't understand... res_pjproject doesn't depend on bunddled |
| 19:23.55 | rmudgett | Well maybe not. There are two defines HAVE_PJPROJECT and HAVE_PJPROJECT_BUNDLED that may alleviate the problem. |
| 19:24.23 | rmudgett | It may depend upon how libasteriskpj is actually built. |
| 19:24.27 | gtjoseph | yeah. the 1 thing you can't do is use sorcery from libasteriskpj |
| 19:24.47 | gtjoseph | you have to use the built-in config file stuff |
| 19:25.18 | rmudgett | Sorcery is already initialized before ast_pj_init() is called. |
| 19:25.43 | gtjoseph | yes but the wizards are in modules which may not be |
| 19:26.18 | gtjoseph | the libasterisk libraries are managed by the OS not our module laoder |
| 19:26.58 | rmudgett | That's because the main Asterisk program is referencing these functions directly. |
| 19:27.15 | rmudgett | But yeah. The wizards wouldn't be loaded yet. |
| 19:27.31 | gtjoseph | yep. |
| 19:27.44 | gtjoseph | it's not like pjproject.conf really needs sorcery anyway |
| 19:28.04 | rmudgett | Not a big loss that. |
| 19:28.12 | gtjoseph | nope |
| 19:28.45 | gtjoseph | can you confirm that with your patch that a 'pjproject show buildopts' shows the "6" for PJ_LOG_MAX_LEVEL? |
| 19:29.06 | rmudgett | When libasteriskpj is built will it link statically with pjproject when bundled and dynamically when bundled not enabled? |
| 19:29.38 | rmudgett | Yes I can confirm that 6 is shown. |
| 19:29.58 | rmudgett | You may not be using a bundled pjproject :) |
| 19:32.06 | gtjoseph | correct on the first question |
| 19:32.29 | gtjoseph | i HAVE to be using the bundled version. there is no other installed. |
| 19:32.34 | gtjoseph | weird |
| 19:33.20 | rmudgett | Putting all that code into libasteriskpj will force pjproject to be loaded even if you aren't going to use one of the modules that needs it. |
| 19:33.53 | gtjoseph | doesn't that happen anyway? |
| 19:34.10 | gtjoseph | wait, when you say "pjproject" what do you mean? |
| 19:35.31 | rmudgett | Not with current code. If you don't use bundled and don't load res_pjrpoject, res_pjsip, or res_rtp_asterisk then pjproject won't be loaded. |
| 19:36.13 | gtjoseph | libasteriskpj will load it though |
| 19:36.40 | rmudgett | Only if you have bundled enabled because it will be statically linked with it. |
| 19:37.16 | rmudgett | If bundled isn't enabled then it doesn't reference anything in pjproject. |
| 19:37.37 | gtjoseph | if its using shared, it still has to load from the shared libraries to run pj_init |
| 19:38.10 | rmudgett | Right but in libasteriskpj that call is conditional upon HAVE_PJPROJECT_BUNDLED being defined. |
| 19:38.16 | gtjoseph | ah, yeah |
| 19:39.14 | gtjoseph | still libasteriskpj loading pjproject isn't that bad is it? |
| 19:39.36 | gtjoseph | considering it's our official sip stack now |
| 19:39.43 | rmudgett | It just takes up memory if you aren't using anything with pjproject |
| 19:40.12 | gtjoseph | true but we want everyone off chan_sip anyway |
| 19:40.29 | gtjoseph | and there can't be very many folks running asterisk with onoly non-SIP protocols |
| 19:40.48 | rmudgett | chan_sip indirectly can use part of pjproject for ICE support |
| 19:41.06 | gtjoseph | see you just made my case |
| 19:41.46 | rmudgett | What you mean people cannot build Asterisk systems that just use legacy technology (chan_dahdi)? |
| 19:41.55 | rmudgett | tisk |
| 19:42.09 | file | hmmm? |
| 19:42.27 | gtjoseph | hands up... how many folks run asterisk without any SIP stack??? |
| 19:42.46 | gtjoseph | i'm sure there are some |
| 19:43.00 | file | would this make pjproject a required dependency? |
| 19:43.02 | gtjoseph | but in proportion to those running SIP?? |
| 19:43.06 | rmudgett | I do occasionally :) |
| 19:43.13 | gtjoseph | no because libasteriskpj doesn |
| 19:43.18 | gtjoseph | t get build if pjproject isn't installed |
| 19:43.36 | gtjoseph | or available via bundled |
| 19:43.46 | rmudgett | Yes it does because asterisk.c unconditionally references ast_pj_init(). |
| 19:44.12 | gtjoseph | well, that's an easy fix |
| 19:44.40 | rmudgett | ast_pj_init() does not do anything right now if you don't have bundled pjproject enabled. |
| 19:44.41 | file | what is the actual memory impact? |
| 19:45.26 | rmudgett | Right now libasteriskpj only has the one function and it is empty if bundled isn't enabled |
| 19:46.05 | gtjoseph | if you don't call pj_init, it should be none |
| 19:46.06 | rmudgett | If you have bundled enabled then it pulls in pjproject |
| 19:50.12 | rmudgett | Lets see. HAVE_PJPROJECT is defined if configure detects you have pjproject on your system. HAVE_PJPROJECT_BUNDLED gets defined if configure is told you want bundled. |
| 19:51.11 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 19:51.13 | gtjoseph | Does HAVE_PJPROJECT get defined for bundled? I forget. |
| 19:51.23 | rmudgett | With bundled you will always have pjproject loaded because it is statically linked with libasteriskpj. |
| 19:51.51 | gtjoseph | yep |
| 19:52.25 | gtjoseph | and HAVE_PJPROJECT is also always defined for bundled as well as HAVE_PJPROJECT_BUNDLED |
| 19:52.42 | rmudgett | HAVE_PJPROJECT has to also be defined with HAVE_PJPROJECT_BUNDLED because res_rtp_asterisk used HAVE_PJPROJECT to conditional in code |
| 19:52.58 | gtjoseph | i know. i just looked. :) |
| 19:56.03 | rmudgett | Moving res_pjproject into libasteriskpj would cause pjproject to always get pulled in if pjproject is detected by configure. Assuming that all of the res_pjproject code is made conditional upon HAVE_PJPROJECT. |
| 19:56.51 | rmudgett | It's getting very close to a required dependency. :) |
| 19:56.51 | gtjoseph | yes but what does "pulled in" mean? It's just library referneces. |
| 19:57.31 | gtjoseph | if HAVE_PJPROJECT isn't defined, we just don't build libasteriskpj |
| 19:57.39 | rmudgett | Pulled in as in dynamically or statically linked to the main asterisk program. |
| 19:58.19 | gtjoseph | pjproject is never dynamically or statically linked to the main asterisk program |
| 19:58.30 | rmudgett | libasteriskpj then |
| 19:58.50 | gtjoseph | yes but a dynamic link of pjproject to libasteriskpj costs nothing |
| 19:58.56 | rmudgett | Pulled into your running asterisk instance |
| 19:59.18 | rmudgett | Costs nothing as far as disk space |
| 19:59.40 | rmudgett | Load time and memory... |
| 19:59.49 | rmudgett | that's something else |
| 20:01.00 | rmudgett | Must always be built because ast_pj_init() is unconditionally called by the main asterisk program |
| 20:01.09 | gtjoseph | come to the meeting |
| 20:01.21 | file | yes, come to the meeting |
| 20:01.21 | rmudgett | Either that or if you have never built it you will have link errors. |
| 20:01.25 | rmudgett | k |
| 20:01.29 | file | or else your scrum master will have the door locked |
| 20:10.49 | *** join/#asterisk-dev joshelson (~jpe@64.55.128.243) |
| 20:15.45 | joshelson | Would anyone be willing to have a brief conversation about this issue I brought up on dev mailing list a couple months back? http://lists.digium.com/pipermail/asterisk-dev/2016-September/075774.html |
| 20:17.26 | joshelson | Willing to develop the solution here, but would like to align with community approach and ideally build something acceptable to the dev community as a whole |
| 20:20.31 | *** join/#asterisk-dev klow (~textual@static-82-85-143-26.clienti.tiscali.it) |
| 20:22.56 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:43.53 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-bziisjvzgxixlhqp) |
| 20:43.53 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:00.55 | gtjoseph | rmudgett: try a clean configure WITHOUT --enable-dev-mode and see if 'pjproject show buildopts' still works |
| 21:01.55 | rmudgett | What do you mean by clean? |
| 21:02.03 | gtjoseph | nevermind |
| 21:02.24 | gtjoseph | i think my issue was with distclean |
| 21:02.44 | gtjoseph | i'm at least showing the correct level in buildopts |
| 21:02.49 | rmudgett | Distclean not removing the build.mak and source directory? |
| 21:03.00 | gtjoseph | no, makeopts and menuselect.makeopts |
| 21:03.56 | file | joshelson: it should be possible to implement those things... but there's no knobs documented in the dialplan for ICE and such |
| 21:04.34 | rmudgett | Setting the level to 6 is really spammy since you get messages like I'm locking this now...I'm unlocking this now.... |
| 21:05.28 | file | joshelson: pre-dial hook and a dialplan function to set things would be fine |
| 21:06.47 | joshelson | There are actually just no knobs in the dialplan at all at the moment file ... and a couple of different approaches have been employed. |
| 21:07.01 | gtjoseph | rmudgett: ok, i'm getting output now so it at least works as is. what's the verdict on at least having libasteriskpj read pjproject.conf and set the level? Or I guess asterisk.c could read pjproject.conf. |
| 21:07.24 | gtjoseph | the option in asterisk.conf just seems out of place |
| 21:07.38 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 21:07.38 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:07.40 | rmudgett | It parallels the verbose and debug options. |
| 21:08.39 | gtjoseph | yes but it's specific to pjproject and we have a file for pjproject logging...pjproject.conf |
| 21:09.00 | joshelson | Some PJSIP only things (which I believe this would most likely be) have been done with PJSIP_* functions. Others have been done as Set(CHANNEL... options of various sorts. But the documentation and even logging on what channel types this would be expected to work on has been limited. |
| 21:09.18 | rmudgett | I'd rather leave it in asterisk.conf. Requiring pjproject.conf to exist just so you can specify that one options seems rather extreme. |
| 21:10.09 | gtjoseph | not following. why does this require pjproject.conf to exist? |
| 21:10.26 | file | joshelson: CHANNEL() stuff has to exist in chan_pjsip, while dialplan functions can exist outside of it which is why it was done in some cases |
| 21:10.36 | rmudgett | gtjoseph: That's where you are saying the option should exist. |
| 21:10.45 | gtjoseph | isn't there a default? |
| 21:11.09 | gtjoseph | again if you're using chan_pjsip, then pjproject.conf has to exist. |
| 21:11.12 | rmudgett | Yes there is a default. Only after you've complained that the conf file doesn't exist. |
| 21:11.24 | gtjoseph | and that's our recommended path forward |
| 21:11.52 | joshelson | file: Makes sense. Is there a preference in this case? A channel driven knob to mess with avpf or ICE makes little sense for all other channel types besides PJSIP |
| 21:12.09 | rmudgett | Use of pjproject is not required for all setups. |
| 21:12.21 | gtjoseph | it's required for chan_pjsip |
| 21:12.35 | gtjoseph | which is the only supported SIP stack |
| 21:12.43 | rmudgett | So it seems silly to require pjproject.conf to exist when you don't need it. |
| 21:12.46 | file | joshelson: I don't really have a preference either way but it could become clearer during implementation where it should live |
| 21:13.29 | file | joshelson: for example there's already a PJSIP_MEDIA_OFFER so maybe a dialplan function which controls attributes makes sense |
| 21:13.34 | gtjoseph | when would you NOT need it? only if you're using chan_sip |
| 21:13.50 | rmudgett | chan_dahdi setups |
| 21:14.10 | gtjoseph | so <.00001% of the installs |
| 21:14.34 | file | your conversation continues to confuse me |
| 21:14.42 | gtjoseph | me too |
| 21:14.44 | rmudgett | file whose? |
| 21:14.48 | file | yours |
| 21:15.16 | joshelson | file: I have prototype code for both approaches ... Set(PJSIP_USE_AVPF()=false) and Set(CHANNEL(use_avpf)=false). I tend to prefer the former, but that's possibly because I only care about the PJSIP case. |
| 21:16.32 | file | joshelson: neither really catch my attention as being "it should be like this" |
| 21:16.40 | file | putnopvut: your thoughts? |
| 21:19.34 | file | rmudgett: I agree with gtjoseph - it doesn't feel like it belongs in asterisk.conf |
| 21:21.23 | rmudgett | fine. I'll make it parse pjproject.conf. However, I won't be able to use the config framework or sorcery. If the file doesn't exist then it doesn't exist and I'll silently use the default. |
| 21:21.40 | file | ok |
| 21:23.28 | putnopvut | file: asking for my thoughts on which topic? As far as joshelson's convo goes, I agree with you that either approach is fine. Neither really seems "wrong" to me. |
| 21:24.23 | file | aye |
| 21:24.55 | gtjoseph | rmudgett: you could compile config.c into libasterskpj. |
| 21:25.03 | gtjoseph | and i'm off to the dentist. :) |
| 21:27.18 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-qoglmkrfludmmhfr) |
| 21:27.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:27.38 | joshelson | Cool... thanks guys. From a code hygiene and cleanliness of patch point of view, the PJSIP approach seems easiest to me, and avoids confusing this PJSIP specific function with a generic channel function. I'll get a reviewboard up on this as soon as I can. |
| 22:03.51 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 22:16.42 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 22:16.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:18.18 | snuff-work | mm so can any1 answer my question ? (why when CDR(userfield) is set during the dial plan can you not read the variable back? yet it works fine in the hangup exten) |
| 22:18.47 | snuff-work | trying on trunk atm or near enough to head |
| 22:29.24 | putnopvut | snuff-work: Only thing that sticks out to me is that if a CDR is considered "finalized" then the userfield can't be written to the "party A" side of the CDR any longer. I'm not that familiar with the CDR code, so I'm not sure what it means to be "finalized" |
| 22:30.00 | putnopvut | But it's something that stuck out as a reason the userfield wouldn't be written to the CDR. And if the userfield isn't written, then you wouldn't be able to read it back. |
| 22:32.11 | snuff-work | mm.. i know CDR are special etc.. (back in the 1.2 days i actually had to care more).. just thought since i'm the adding the userfield change it should be readable straight away |
| 22:32.33 | snuff-work | i got around my issue by using an inherited variable instead |
| 22:50.37 | snuff-work | i can put up a patch to make asterisk 14 build on solaris 11.. question is.. any1 likely to ever use it =) (x86.. i dont have sparc platform anymore).. |
| 22:51.13 | snuff-work | nevermind that sparc just complained a tad too much about alignment =) |
| 22:56.14 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 22:56.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:59.04 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:25.21 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 23:25.21 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:46.27 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 23:46.27 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |