| 03:56.49 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.167) |
| 06:58.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:18.04 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:26.42 | *** join/#asterisk-dev hajekd (~hajekd@81.90.251.91) |
| 07:34.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:34.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:35.40 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:26.19 | *** join/#asterisk-dev hajekd (~hajekd@212.24.153.186) |
| 09:13.47 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:48.06 | seanbright | jira down? |
| 10:48.08 | seanbright | or just me? |
| 12:01.06 | gtjoseph | seanbright: it does appear to be non responsive |
| 12:01.26 | gtjoseph | opens an internal issue |
| 12:56.35 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-ebbskhcjkssznhqk) |
| 12:56.35 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:58.32 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 13:06.24 | seanbright | cherry picking to 15.0 is now meaningless, correct? |
| 13:06.36 | file | correct |
| 13:35.18 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cdtsttperhbvojco) |
| 13:35.18 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 13:45.37 | seanbright | so jira is up now but my credentials aren't working - known issue? |
| 13:45.46 | file | yes |
| 13:45.51 | seanbright | k |
| 14:16.37 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:16.37 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:17.13 | *** join/#asterisk-dev hajekd (~hajekd@212.24.153.186) |
| 14:34.46 | gtjoseph | seanbright, file: did you guys discuss the possibility of a loop if forwarding messages back to the recipient? |
| 14:35.35 | file | no |
| 14:51.57 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:51.57 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:58.49 | seanbright | gtjoseph: how would it loop? |
| 15:00.09 | gtjoseph | party a -> asterisk conf br -> asterisk conf br -> party b |
| 15:00.15 | gtjoseph | oops, stand-up time |
| 15:01.44 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bnxcxhzbvzbiphjt) |
| 15:01.44 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:12.53 | coreyfarrell | is digium working today or on holiday? |
| 15:15.19 | gtjoseph | we're working |
| 15:15.26 | gtjoseph | except for file :) |
| 15:15.49 | coreyfarrell | cool if you get a chance can you make time for https://gerrit.asterisk.org/6647 ? |
| 15:19.31 | *** join/#asterisk-dev dtascom (~circuser-@static-47-180-162-26.lsan.ca.frontiernet.net) |
| 15:19.39 | gtjoseph | yeah, we're trying to make a big gerrit push today since everyone's back |
| 15:28.43 | coreyfarrell | doesn't look like anyone announced to asterisk-dev mailing list that 14 is security only, wiki says sept 26th. are we still fixing bugs for 14 until a final non-security release or is it closed? |
| 15:29.25 | coreyfarrell | cresl1n: ^^ probably directed your way. |
| 15:29.49 | gtjoseph | ity's october something but cresl1n forgot to update the wiki |
| 15:29.52 | file | did not take kindly to the shift from Orlando back home and has a not great cold which is impacting all the things |
| 15:32.14 | *** join/#asterisk-dev hajekd (~hajekd@81.90.251.91) |
| 15:34.15 | gtjoseph | ok, we're back, kinda. |
| 15:34.28 | gtjoseph | newtonr is working the current jira issue |
| 15:34.43 | gtjoseph | cresl1n is gonna clarify the 14 thing |
| 15:35.19 | gtjoseph | and opticron is going to explain the comment he had about the message echo, right opticron? :) |
| 15:35.49 | opticron | I thought richard had already taken care of explaining that? |
| 15:35.52 | cresl1n | coreyfarrell: I missed it - I'll see if I can get a reminder out about it |
| 15:35.56 | newtonr | IT has mostly taken it over from me. JIRA is being nuts |
| 15:36.06 | opticron | which is why I didn't respond |
| 15:36.57 | gtjoseph | seanbright and file had a conversation about turning it back on last week so i though you might be able to explain why not to seanbright |
| 15:39.01 | seanbright | is it in the IRC backlog? i can just scroll back if necessary |
| 15:39.26 | gtjoseph | i don't remember it being |
| 15:39.52 | seanbright | ok |
| 15:42.40 | opticron | it was on the review |
| 15:43.25 | opticron | but the rationale for not having the echo in place is that if you ever have two conferences attached to each other both sides get spammed repeatedly as soon as any text frame rolls through |
| 15:44.24 | opticron | either conf-conf within asterisk or conf-PJSIP-conf between two instances |
| 15:45.28 | gtjoseph | We could add an X-header that'd be added by bridge_softmix that says "No Echo" or something |
| 15:46.46 | opticron | that doesn't help the situation where the remote end is a non-asterisk conference forwarding text frames |
| 15:47.07 | opticron | even if the other side doesn't echo, there are situations where a duplicate text frame would get delivered |
| 15:48.02 | seanbright | k |
| 15:48.44 | rmudgett | seanbright: Does the testsuite use sqlite cdrs? |
| 15:49.10 | gtjoseph | ok, we could an X-header that says "Echo" that a client could use if they want |
| 15:49.39 | rmudgett | I'm thinking not since the tests I know about use the cdr_csv module. |
| 15:50.11 | rmudgett | gtjoseph: Why echo the message back to the sender? |
| 15:50.24 | rmudgett | Not everyone is going to be testing all the time. |
| 15:50.26 | gtjoseph | ./tests/cdr/sqlite3/cdr_sqlite3.py:73: sqlite_config_file = ("%s/%s/cdr_sqlite3_custom.conf" % |
| 15:50.27 | gtjoseph | ./tests/cdr/sqlite3/test-config.yaml:142: - asterisk : 'cdr_sqlite3_custom' |
| 15:50.51 | seanbright | sqlite <> sqlite3 |
| 15:50.53 | seanbright | thankfully |
| 15:50.59 | gtjoseph | oh duh |
| 15:51.50 | gtjoseph | rmudgett: you could check iof anything links to libsqlite |
| 15:52.11 | seanbright | interestingly i used the SQL not equals operator there without meaning to |
| 15:52.26 | gtjoseph | and the echo was to allow the client to have a record of the real conversion, maybe to print of as email |
| 15:52.35 | gtjoseph | :) |
| 15:52.38 | rmudgett | Was just trying to think of potential consequences to the testsuite by disabling sqlite cdrs by default in the sample files. |
| 15:52.59 | seanbright | i can test |
| 15:53.00 | file | tests shouldn't rely on sample behavior, so if there were an issue it'd be test side |
| 15:53.50 | rmudgett | file: Tests do rely on sample behavior. |
| 15:54.17 | file | see above. |
| 16:14.41 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-eemkqsghvtkigvmf) |
| 16:14.41 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:19.22 | coreyfarrell | has it been considered to delete minor release branches after we are done with them? talking about 13.15, etc. the head of that branch should be tagged as a point release and it would make cherry-picking in gerrit ui easier (typing 15 would usually give us 15, not 13.15). |
| 16:27.11 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 16:31.51 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:52.38 | danjenkins | @seanbright that tls key thing we were talking about the other day - I found something similar in the chromium flags to turn off WebRTC media encryption but the flag isnt enabled for stable and beta builds as its meant to be only used for debugging. I could see a tls key flag being set in the same way - if you think about it, the admin (or compromised admin) has the ability to set all encryption keys used by chromium |
| 16:52.38 | danjenkins | <PROTECTED> |
| 17:08.54 | seanbright | danjenkins: you can add an RTCCertificate to indexeddb apparently... not sure how that helps |
| 17:21.57 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 17:21.57 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 17:35.04 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 17:57.37 | rmudgett | gtjoseph: Ok. Updated remove_existing to use vectors. With the small number of contacts involved a heap really wasn't necessary. Now the vector only contains the number of contacts that get pushed out instead of all remaining contacts. |
| 18:00.08 | cresl1n | wow, the -dev list has gotten a lot of traffic in the last day or so |
| 18:00.49 | file | cresl1n: just a bit |
| 18:07.46 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.169) |
| 18:14.00 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.169) |
| 18:15.23 | *** part/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:17.24 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:17.25 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 18:26.42 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 18:26.42 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 19:37.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0005782d1b0a3d2942.ipv6.abo.wanadoo.fr) |
| 19:40.13 | gtjoseph | @kharwell: not understanding your question on session dependency. pjsip_session.c is compiled into res_pjsip and doesn't depend on res_pjsip_session. res_pjsip_session does depend on res_pjsip as it should. |
| 19:40.32 | gtjoseph | what did I miss? |
| 19:43.33 | kharwell | right it gets compiled into res_pjsip, so with those changes res_pjsip now requires res_pjsip_session as it needs that to find the definition to ast_sip_session |
| 19:44.23 | coreyfarrell | it requires the header for the type definition but it doesn't link to any symbols in res_pjsip_session.so. |
| 19:44.45 | gtjoseph | ^^ |
| 19:44.50 | coreyfarrell | actually this patch fixes a problem where res_pjsip is currently linking to global symbols exported by res_pjsip |
| 19:45.04 | gtjoseph | that too :) |
| 19:45.10 | coreyfarrell | and I'm still confused about how that's even possible :) |
| 19:46.01 | file | symbol resolution works in mysterious ways |
| 19:47.01 | gtjoseph | for someone who's sick you're awfully chatty today. |
| 19:47.36 | file | gtjoseph: magic |
| 19:47.41 | gtjoseph | ah |
| 19:47.56 | file | or I'm sitting on the couch with nothing else to do, well, I need to cobble together something to consume |
| 19:47.59 | gtjoseph | been doing a harry potter marathon? |
| 19:48.23 | file | I should have |
| 19:49.48 | kharwell | gtjoseph coreyfarrell: ya it doesn't create a symbol problem unless something moves later (which is doubtful). But thought I'd mention it as circular references generally aren't the best. But I can live with it if others are fine with it |
| 19:50.13 | gtjoseph | it's the lesser of 2 evils circular reference wise |
| 19:50.18 | file | much lesser |
| 19:50.39 | coreyfarrell | but it's not referencing a symbol, it's referencing a definition. |
| 19:50.57 | gtjoseph | the next step would be to just take all of res_pjsip_session and dump it into pjsip_session. |
| 19:51.20 | coreyfarrell | I didn't get the impression that was wanted.. |
| 19:51.27 | coreyfarrell | but I agree. |
| 19:52.08 | gtjoseph | i didn't say when the next step would be :) |
| 20:07.03 | coreyfarrell | apparently someone did hit the symbol resolution failure between res_pjsip and res_pjsip_session - ASTERISK-26518. |
| 20:09.49 | coreyfarrell | should I modify the commit msg to include that ticket so the release notes associate it or not bother? |
| 20:09.54 | coreyfarrell | gtjoseph: ^^ |
| 20:10.21 | gtjoseph | nah, it's already +2'd |
| 20:10.41 | gtjoseph | if you want to close that issue at least that's be ok |
| 20:10.47 | coreyfarrell | that what I figured but just wanted to make sure. |
| 20:11.09 | coreyfarrell | yeah I'll close it once the merges go through. |
| 20:11.15 | gtjoseph | kk |
| 20:23.43 | gtjoseph | seanbright: question on the dtls cert type patches... it looks like you're only setting the ephemeral flag if there's no certfile AND webrtc is selected. was that intentional? |
| 20:23.57 | seanbright | yes |
| 20:24.06 | seanbright | the default is 'file' which is current behavior |
| 20:24.55 | gtjoseph | yeah but maybe an additional comment in the xmldoc and sample that webrtc will automatically do an ephemeral if certfile isn't specified. |
| 20:25.11 | gtjoseph | would be good |
| 20:25.16 | seanbright | k |
| 20:26.12 | gtjoseph | actually, hmmmmm. |
| 20:26.42 | gtjoseph | the webrtc option was meant to be a shortcut to other options, not a driver of functionality |
| 20:27.24 | rmudgett | gtjoseph: Answered your cdr assert question. |
| 20:27.32 | gtjoseph | if i set the parameters manually but don't set webrtc, then i don't get ephemeral cert |
| 20:27.45 | gtjoseph | even though i actually get webrtc functional;ity |
| 20:27.56 | gtjoseph | file: opinion? ^^ |
| 20:28.28 | gtjoseph | rmudgett: thanks |
| 20:28.55 | file | I think webrtc should be a shortcut to allow a working WebRTC configuration in the end |
| 20:29.28 | gtjoseph | but should it also drive functionality not exposed by otyhert parameters? |
| 20:30.15 | file | I don't understand the question |
| 20:30.19 | kharwell | I believe it does so already in a couple of spots. For instance it doesn't add some sdp attributes if not set. |
| 20:30.26 | file | yes |
| 20:30.47 | gtjoseph | oh really? |
| 20:30.52 | file | msid |
| 20:30.56 | file | which is a WebRTCIsm |
| 20:31.17 | kharwell | otherwise those options would always be added to the sdp when they didn't need to be. Maybe could have keyed off another option for those? dunno for sure |
| 20:31.26 | gtjoseph | ok, then seanbright how about a comment added to the webrtc parameter docs to say that it also allows automatic ephemeral certs if a file isn't specified. |
| 20:32.07 | gtjoseph | regardless of the setting of dtlscerttype |
| 20:33.21 | gtjoseph | also, no 13/14 even without the webrtc option? |
| 20:34.45 | rmudgett | The webrtc option wasn't supposed to do anything other than act like a macro config of setting other options for webRTC. |
| 20:35.00 | rmudgett | That was my understanding of what that option was supposed to do. |
| 20:35.04 | gtjoseph | well, that's what I shought but apparently not |
| 20:36.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:36.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:43.20 | seanbright | gtjoseph: i've moved on to something else at the moment. can you add a note to the review with the changes that you want? |
| 20:43.28 | gtjoseph | no prob |
| 21:30.59 | seanbright | so i'm just now getting around to starting my profiling |
| 21:31.26 | seanbright | big offender appears to be pjsip_tpmgr_find_local_addr2 |
| 21:32.13 | seanbright | well, one of the big offenders |
| 21:57.39 | rmudgett | file: Was one of the failing testsuite tests tests/rtp/strictrtp? |
| 21:57.50 | file | no? |
| 21:58.47 | rmudgett | Ok. It was failing on my local box because it is looking for exactly 250 rtp frames in the RTCP report. My box sometimes reports 251. |
| 22:33.44 | seanbright | so, everytime we transmit a message we call pjsip_tpmgr_find_local_addr2 |
| 22:34.15 | seanbright | and by setting the prm.local_if to true, we are creating a socket, connecting it, and closing it for every transmitted message |
| 22:39.56 | seanbright | i'm not sure how we fix that. potentially caching the local address? |
| 22:40.32 | gtjoseph | ew |
| 22:40.44 | seanbright | agreed. |
| 22:40.48 | gtjoseph | it's have to be updated by stun at least |
| 22:41.25 | gtjoseph | maybe stun or a reload of the transport |
| 22:41.43 | seanbright | i'm tracing the implementation of pjsip_tpmgr_find_local_addr2 now |
| 22:41.57 | gtjoseph | good luck |
| 22:42.46 | seanbright | yeah, as expected. |
| 22:42.50 | seanbright | lots of syscalls |
| 22:43.00 | gtjoseph | iirc the stun module chucks a message on stasis |
| 22:43.17 | gtjoseph | besides that and a reload of the transport, what else could cause the address to change? |
| 22:43.28 | file | it figures out what interface a message will go out on, so things can be updated accordingly if I recall |
| 22:43.34 | file | in particular if you bind to 0.0.0.0 |
| 22:43.38 | seanbright | right |
| 22:43.46 | seanbright | but it does it on every transmitted message |
| 22:43.50 | seanbright | and it doesn't appear to be cheap |
| 22:44.14 | seanbright | socket()/connect()/getsockname()/close() |
| 22:44.29 | seanbright | i'm wondering if we optimize for the common case (not-multihomed) |
| 22:44.48 | seanbright | that doesn't help multihomed users though |
| 22:45.05 | gtjoseph | common-case is kinda relative |
| 22:45.05 | seanbright | gtjoseph: someone adds an interface, removes one |
| 22:45.18 | seanbright | that's fair |
| 22:45.18 | gtjoseph | true but you'd expect a disruption in that case |
| 22:45.30 | coreyfarrell | if it's unavoidably expensive it would be nice to be able to set a config option for static single-interfaced environments |
| 22:45.48 | gtjoseph | the multihomed environment is common for both pbxes and service providers |
| 22:45.55 | gtjoseph | hell, my pbx is multihomed |
| 22:46.02 | seanbright | you are not the common case |
| 22:46.19 | seanbright | but either way, optimizing for it doesn't help the non-multihomed |
| 22:46.30 | gtjoseph | ok, most pbxes I've set up in the past 6 years have been multihomed. |
| 22:46.44 | gtjoseph | an option in globals would be very inexpensive |
| 22:46.52 | seanbright | https://stackoverflow.com/questions/2261759/get-notified-about-network-interface-change-on-linux |
| 22:46.55 | seanbright | for the linux case |
| 22:47.10 | seanbright | can we call that the common case? |
| 22:47.12 | seanbright | :P |
| 22:47.20 | gtjoseph | so I would say linux _is_ the overwhelmingly common case. |
| 22:47.52 | gtjoseph | if we don't make things worse for non-linux then i'd be fine with optimnizing the linux case |
| 22:48.34 | seanbright | ok, so maybe it's two-fold: a config option to turn off multihomed support, and something magical on linux to watch network change events |
| 22:48.59 | file | what would the network change events stuff do when they occur? |
| 22:49.07 | seanbright | clear a cache |
| 22:49.10 | seanbright | i think? |
| 22:49.17 | gtjoseph | is the linux event method supported on older kernels? |
| 22:49.23 | file | a cache of what? |
| 22:49.43 | seanbright | dst ip -> local ip |
| 22:49.54 | seanbright | to elminate to the call to pjsip_tpmgr_find_local_addr2 |
| 22:50.04 | file | and would that cache be configurable in size? (another config option) |
| 22:50.11 | seanbright | fair enough |
| 22:50.15 | seanbright | what are your thoughts? |
| 22:50.48 | file | if it's that expensive then a cache may help, but you can't let it go unbounded |
| 22:51.10 | seanbright | i will test the common case tomorrow |
| 22:51.20 | file | you would also need to be careful about synchronization there |
| 22:51.21 | seanbright | well, what i deem the common case (single-homed) |
| 22:51.24 | seanbright | right |
| 22:51.34 | seanbright | so replacing a syscall with a lock/unlock |
| 22:52.26 | file | chan_sip did a similar thing |
| 22:53.09 | seanbright | well chan_sip is the bee's knees |
| 22:53.14 | seanbright | as we all know |
| 22:53.54 | file | I like trains. |
| 22:54.09 | seanbright | another option would be to find another method to do the same thing - choose the local IP based on the destination IP |
| 22:54.25 | seanbright | but i think getsockname() is the defacto method of doing that |
| 22:55.18 | gtjoseph | could also add an option to transport for "source_address" |
| 22:56.36 | file | seanbright: ye ol' test shall be enlightening |
| 22:56.43 | seanbright | agreed |
| 22:57.22 | coreyfarrell | gtjoseph: that's what I meant when I suggested a config option.. allow it to be configured so it never checks for the local ip. |
| 22:57.32 | gtjoseph | ah gotcha |
| 22:58.32 | coreyfarrell | I would use that on a few deployments where the system is sitting in a datacenter with a single static IP address.. |
| 22:59.08 | gtjoseph | but in that case would you not bind to that single address instead of 0.0.0.0? |
| 22:59.45 | seanbright | it still calls pjsip_tpmgr_find_local_addr2 |
| 23:00.14 | gtjoseph | but that could be an optimization no? if bound to a specific address, use it for the source? |
| 23:00.30 | seanbright | yeah |
| 23:00.34 | file | most normal people 0.0.0.0 because you can be a bit lazier in deployment |
| 23:00.53 | gtjoseph | then you get the lazy result :) |
| 23:00.56 | coreyfarrell | if that worked I would use it. I'm not normal. |
| 23:01.39 | gtjoseph | normalcy is relative :) |
| 23:05.49 | file | hrm I'm missing an email |
| 23:06.41 | file | and it's not in my gmail |
| 23:06.42 | file | cute |
| 23:06.51 | seanbright | file: want me to send you one? |
| 23:07.00 | file | you COULD, but no :P |
| 23:07.02 | file | it's a -users post |
| 23:12.37 | file | inbound texts on my phone are also broken, so that's cool too |
| 23:12.58 | coreyfarrell | looks like the testsuite crashed on https://gerrit.asterisk.org/6649 but it was during the pjsip tests.. should I regate? |
| 23:13.12 | file | probably wise |
| 23:24.17 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-eemkqsghvtkigvmf) |
| 23:58.31 | seanbright | is is_ao2_object() just a sanity check? |