| 00:08.10 | *** join/#asterisk-dev jkroon (~jkroon@2c0f:f720:1:0:fcb3:e235:8b0a:1f6b) |
| 00:19.59 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-mrsuttumimfhhzxo) |
| 00:34.12 | snuff-work | mm.. when i try to compile in dev mode.. (trunk) i get following errors in cdr.c |
| 00:34.27 | snuff-work | cdr.c:2744 / 2789: warning: dereferencing type-punned pointer will break strict-aliasing rules |
| 00:34.37 | snuff-work | maybe because its openbsd.. ? |
| 00:34.43 | file | probably |
| 00:37.24 | snuff-work | i mean i do see casting happening there.. but doubt its stopped working on a linux build.. (haven't tested one recently |
| 00:39.03 | file | every submitted change is verified on Linux for build and unit tests |
| 00:39.10 | file | it hasn't stopped working on Linux |
| 00:41.32 | snuff-work | mm.. still interesting to wonder why the hate under obsd |
| 00:41.42 | snuff-work | gcc = 4.2.1 |
| 00:46.17 | snuff-work | they have the same data type right? |
| 00:47.30 | snuff-work | also if its global.. why require it to be passed in? |
| 00:47.56 | snuff-work | is missing something i'm sure |
| 00:58.37 | gtjoseph | snuff-work: it's passed in because the functions can be called with the backend list or the modifier list. |
| 00:59.00 | gtjoseph | they're both global but the functions don't know that |
| 01:00.39 | snuff-work | but are the lists not of the same data inside in actuality (cdr_beitem) ? |
| 01:01.49 | gtjoseph | they're the same type, kinda. |
| 01:02.07 | gtjoseph | bot they don't have the same data (at i think they don't) |
| 01:03.34 | gtjoseph | they do have the same structure format but they're declared independently |
| 01:03.58 | gtjoseph | i'm not sure why it's causing the error you see |
| 01:04.21 | gtjoseph | but strictly speaking, they don't share the same type |
| 01:07.17 | snuff-work | mm.. basically |
| 01:07.22 | snuff-work | return cdr_generic_register((struct be_list *)&mo_list, name, desc, be); == failed |
| 01:07.40 | snuff-work | return cdr_generic_register(&be_list, name, desc, be); == pass |
| 01:08.26 | gtjoseph | probably because cdr_generic_register takes be_list as the argument |
| 01:08.29 | snuff-work | the generic register of course is defined to like the 'struct be_list' as its proto |
| 01:19.18 | snuff-work | debates fixing / importing new obsd compat for dns.. |
| 01:56.34 | coreyfarrell | snuff-work: the strict-aliasing rules might be related to some kind of binary hardening enabled by default for gcc in bsd |
| 02:00.21 | snuff-work | possibly |
| 02:35.16 | snuff-work | mm.. it 'almost' compiles now.. but getting error about '-lsrtp-x86_64-unknown-openbsd6.0' when generating the libasterisk.pj.so.2 |
| 02:35.56 | snuff-work | i believe its because we do not compile the srtp.. least in my case with bundled pjproject |
| 04:20.24 | *** join/#asterisk-dev jkroon (~jkroon@2c0f:f720:1:0:fcb3:e235:8b0a:1f6b) |
| 05:55.19 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 05:55.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 06:57.48 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:20.17 | *** join/#asterisk-dev pnlarsson (~niklas@2a02:760:1000:6:8e89:a5ff:fe60:f5f0) |
| 07:24.39 | snuff-work | omg.. i think i got asterisk to compile on openBSD again |
| 07:35.04 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 07:37.30 | snuff-work | soo close +( |
| 07:37.41 | snuff-work | asterisk: can't load library 'libasteriskpj.so' |
| 07:37.59 | snuff-work | file does exist.. |
| 07:37.59 | snuff-work | # find / -name libasteriskpj.so |
| 07:38.00 | snuff-work | /root/asterisk/main/libasteriskpj.so |
| 07:39.55 | *** join/#asterisk-dev matsk (~matsk@vpnbl.borderlight.net) |
| 07:43.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:57.28 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:15.21 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:15.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:54.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:07.04 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 10:28.12 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 10:55.28 | snuff-work | mm some reason had to set ld lib path.. but it seems to be getting closer |
| 11:00.26 | snuff-work | seems rather unhappy.. had issue with pjsip getting it to build all req dependencies.. |
| 11:00.50 | snuff-work | i manually went into third-party/pjproject/src and did gmake |
| 11:01.14 | snuff-work | this made the 2 missing pjsipsdp and pjsipsua2 |
| 11:01.45 | snuff-work | well as bunch of other stuff.. but i feel that it may have also partially caused my linking / lazy loading issue |
| 11:06.00 | snuff-work | asterisk:/usr/local/lib/asterisk/modules/res_pjproject.so: undefined symbol 'pj_init' |
| 12:11.29 | *** join/#asterisk-dev kpjim (~kpjim@46-122-126.static.cyta.gr) |
| 12:21.30 | *** join/#asterisk-dev jkroon (~jkroon@2c0f:f720:1:0:fcb3:e235:8b0a:1f6b) |
| 12:23.37 | *** join/#asterisk-dev kpjim (~kpjim@46-122-126.static.cyta.gr) |
| 12:42.19 | *** join/#asterisk-dev ixyd (~denzs@b2b-46-252-133-250.unitymedia.biz) |
| 13:04.23 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-sdehfljtgqxxucij) |
| 13:04.23 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:04.41 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-wkcihjozoguauiir) |
| 14:04.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:22.12 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 14:31.44 | kpjim | quit |
| 14:32.31 | *** join/#asterisk-dev kpjim (~kpjim@46-122-126.static.cyta.gr) |
| 14:43.25 | *** join/#asterisk-dev pnlarsson (~niklas@2a02:760:1000:6:8e89:a5ff:fe60:f5f0) |
| 14:48.27 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:06.42 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dsukevpwidjtaeoc) |
| 15:06.42 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:14.12 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:14.12 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:15.54 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:15.54 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:16.48 | *** join/#asterisk-dev sarumjanuch (bce62f22@gateway/web/freenode/ip.188.230.47.34) |
| 15:17.09 | sarumjanuch | Hi anyone alive here? |
| 15:19.01 | sarumjanuch | i have a bit specific questions about icesupport in asteriks 11.. |
| 15:19.43 | sarumjanuch | anyone familiar with it implementation here? |
| 15:22.38 | file | a few people are |
| 15:22.46 | file | the actual ICE/STUN/TURN implementation is third party, from PJSIP |
| 15:22.55 | sarumjanuch | and yes and no |
| 15:23.41 | sarumjanuch | i see a bit weied implementation of it in res/res_rtp_asterisk.c |
| 15:24.20 | sarumjanuch | <PROTECTED> |
| 15:24.37 | sarumjanuch | that flag is global and is taken from rtp.conf |
| 15:26.08 | file | yes |
| 15:26.58 | sarumjanuch | and seems like it can't be overridden on peer level |
| 15:27.17 | sarumjanuch | if sunaddr is specified along with icesupport then, asterisk will do stun binding for each call leg even if endpoint don't need any ice |
| 15:27.23 | file | correct |
| 15:27.51 | file | you can disable it on a per-peer basis, but it does still do that at the start |
| 15:28.04 | sarumjanuch | that what i am telling about |
| 15:29.01 | sarumjanuch | it initialize ICE structs, stur stun binding, and only if everything is ok , it check do i catualy need support for it on peer level |
| 15:29.52 | sarumjanuch | if stun server is not available or DNS resolution failure or any network issues, that call thread will be blocked until timeout or response, and will not provide invite response ~= 5-7 seconds |
| 15:30.12 | sarumjanuch | if asterisk plays with some SBC this will lead to creepy shit with retransmits of invites and potentially other issues... I don't know what will be the behaviour with TURN server but I suspect just the same problem. |
| 15:30.50 | sarumjanuch | i came here to ask is there is a reson for such implementation? |
| 15:31.04 | sarumjanuch | why not to pass flag for ice support from chan_sip? |
| 15:34.07 | file | there is no reason explicitly, but the API itself does not allow that specific behavior as of this time |
| 15:34.10 | file | and noone has changed it |
| 15:36.46 | sarumjanuch | so in theory if i will provide a patch there is no potetial issues to do it this way? |
| 15:36.59 | sarumjanuch | i do realize that API is not ready right now for this... |
| 15:37.03 | file | correct |
| 15:37.38 | sarumjanuch | who is behind file nickname?:) |
| 15:38.15 | file | http://blogs.asterisk.org/author/jcolp/ |
| 15:38.56 | sarumjanuch | i was curious is it Matt or Joshua |
| 15:38.57 | sarumjanuch | :) |
| 15:39.29 | sarumjanuch | i belive only few persons do give a f...k in asterisk ice support |
| 15:39.49 | file | we don't get that many issue reports about it |
| 15:40.10 | sarumjanuch | not a lot persons users it heavily in production |
| 15:41.17 | sarumjanuch | https://issues.asterisk.org/jira/browse/ASTERISK-24146 i made a patch for this one. |
| 15:42.44 | sarumjanuch | Joshua, i have one more specific question not related to this problem |
| 15:42.53 | file | okay |
| 15:43.20 | sarumjanuch | pvt_set_needdestroy vs sip_scheddestroy |
| 15:43.33 | file | I honestly don't remember chan_sip much |
| 15:43.45 | sarumjanuch | ohhh.. :( |
| 15:43.55 | sarumjanuch | that's fine :) |
| 15:44.07 | sarumjanuch | it's pretty big one |
| 15:44.09 | file | if you have a specific question about them you can still ask and others might know |
| 15:45.38 | sarumjanuch | guys pvt_set_needdestroy vs sip_scheddestroy which one should i use to initaily destroy sip session? |
| 15:53.43 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-lxpbwmzwszhksslq) |
| 15:53.43 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:07.10 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 16:26.24 | coreyfarrell | sarumjanuch: I think in most cases you want sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT). be sure to test your change with REF_DEBUG enabled to make sure you're not over-releasing or leaking sip dialogs. |
| 16:32.44 | sarumjanuch | I want silently reject and kill certian dialogs just on handle_incoming |
| 16:32.52 | sarumjanuch | on the bare begining |
| 16:33.43 | sarumjanuch | in most lightweight way |
| 16:34.10 | sarumjanuch | without any responses timers etc. |
| 16:34.18 | sarumjanuch | kill and forget |
| 16:35.51 | sarumjanuch | won't pvt_set_needdestroy will be more lightweight for this? |
| 16:39.49 | coreyfarrell | not sure. if the remote end might still send SIP requests or responses for to the dialog then destroying too quick will cause warnings when those SIP packets are received. |
| 16:41.23 | sarumjanuch | there will be no other messages |
| 16:41.51 | sarumjanuch | i am protecting system from unwanted register messages based on regex rules |
| 16:41.59 | sarumjanuch | *we are |
| 16:43.05 | sarumjanuch | and it's only the matter of warnings or potentionaly other issues? |
| 16:47.15 | rmudgett | sarumjanuch: For chan_sip there is always the potential for other issues. |
| 16:47.49 | sarumjanuch | :) |
| 16:48.01 | coreyfarrell | sarumjanuch: not sure, you're going to need to test your change. |
| 16:50.31 | sarumjanuch | anyway thanks a lot |
| 17:19.29 | *** join/#asterisk-dev sarumjanuch (bce62f22@gateway/web/freenode/ip.188.230.47.34) |
| 17:43.45 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:49.55 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00ec565607bc5a5967.ipv6.abo.wanadoo.fr) |
| 18:31.45 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 19:01.40 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:17.30 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:17.30 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:17.35 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-edkowxvyayrbpgrr) |
| 19:17.35 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:18.11 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ugzkslcqzzhwvrfz) |
| 19:18.11 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:20.00 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:20.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:20.08 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bhajkgsntxmxilym) |
| 19:20.08 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 19:21.34 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zdrgzjjrzhnvpqee) |
| 19:21.34 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 20:13.52 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 20:52.37 | newtonr | If someone can't answer this guy's question easily, then I'm going to refer him to the lists for discussion before investigating as a bug: https://issues.asterisk.org/jira/browse/ASTERISK-26599 |
| 20:52.55 | newtonr | I feel like it is more of an "information request" at this point. |
| 20:53.59 | newtonr | Basically, is this increased startup time expected? I'm thinking whoever looks into it will need more information to tell. |
| 21:04.38 | *** join/#asterisk-dev ipengineer (~zconkle@71.252.134.63) |
| 21:41.04 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 21:41.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:54.33 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00ec565607bc5a5967.ipv6.abo.wanadoo.fr) |
| 22:22.15 | *** join/#asterisk-dev rah (rah@verain.settrans.net) |
| 22:22.34 | rah | it would appear that asterisk is calling the wrong function; ERR_get_error() instead of SSL_get_error() |
| 22:22.37 | rah | https://github.com/asterisk/asterisk/blob/master/main/tcptls.c#L634 |
| 22:23.32 | rah | this causes asterisk to report the utterly useless message "Problem setting up ssl connection: error:00000000:lib(0):func(0):reason(0)" |
| 22:24.11 | rah | rather than the heart-warmingly helpful message "Problem setting up ssl connection: error:00000005:lib(0):func(0):reason(5)" |
| 22:31.59 | snuff-work | anyone have ideas on my issue from 8-10 hrs ago with BSD and crashing on startup due to 'ast_pjsip_init()' not being found ? |
| 22:33.00 | file | rah: I'd suggest filing an issue |
| 22:33.02 | file | snuff-work: nope |
| 22:33.43 | snuff-work | i also found an 'errant' -lrt in the building of pjsip |
| 22:33.50 | snuff-work | within the main/Makefile |
| 22:36.26 | snuff-work | (using pjsip bundled) |
| 22:37.27 | snuff-work | one other thing.. how can i track down why certain modules in pjsip was not built under openBSD by the normal 'make' process, but seemed to create them just fine under linux |
| 22:37.49 | snuff-work | (these i later built by going into the pjsip/source folder and manually running make |
| 22:42.17 | rah | file: where? |
| 22:42.25 | file | https://issues.asterisk.org/jira |
| 22:44.21 | rah | ugh |
| 22:44.23 | rah | jira :_/ |
| 22:44.25 | rah | :-/ |
| 22:45.39 | rah | file: who are my JIRA administrators? |
| 22:45.48 | file | look to the left |
| 22:45.52 | rah | apparently, I need to contact my JIRA administrators if I don't have an account |
| 22:46.07 | file | you don't, just look to the left :D |
| 22:46.18 | rah | ETOOBIG |
| 22:46.22 | rah | thanks |
| 22:48.10 | rah | like, if you can make that big link on the left, surely you can just put that link in the box on the right? |
| 22:48.46 | file | not without modifying JIRA. |
| 22:49.36 | rah | is that a bad thing? |
| 22:49.53 | file | it means maintaining an effective fork of JIRA |
| 22:50.01 | file | and is extra work |
| 22:50.07 | rah | I see |
| 23:04.33 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:40.10 | rah | https://issues.asterisk.org/jira/browse/ASTERISK-26606 |