| 00:26.06 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 00:26.06 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 00:39.19 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:39.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:04.06 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 03:05.28 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:ecdd:7e61:c51f:2f86) |
| 03:05.28 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:22.54 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:36.45 | *** join/#asterisk-dev Garoupa (~saddestha@179-236-102-106.user.veloxzone.com.br) |
| 06:43.19 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:52.26 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:00.47 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:03.43 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:08.35 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:24.14 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:24.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:07.11 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:37.36 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-vnzduutpnxldpknr) |
| 12:38.33 | *** join/#asterisk-dev ggo (~quassel@37.19.10.33) |
| 12:47.24 | tsearle | hey, is there a method in asterisk to convert a size in samples into size in bytes for a given format? |
| 12:48.33 | tsearle | e.g. if I have a format of slin24, and want to create a frame of 100 samples, know that I need to make a buffer of 300 bytes |
| 12:53.18 | file | there's nothing built in for that afaik but slin is usually defined using short, so just having an array of shorts of the sample size works |
| 12:54.06 | tsearle | well slin could be anywhere between 1 to 4 bytes per sample right? |
| 12:56.15 | file | don't think so? it's still 2 bytes per sample, there's just more of them |
| 12:56.20 | seanbright | correct |
| 12:56.29 | seanbright | to file's statement |
| 12:56.50 | tsearle | hrm... so slin32 is still 16bit per sample? |
| 12:56.54 | seanbright | yes |
| 12:56.57 | tsearle | ok |
| 12:57.07 | file | seanbright: you validated me! <3 |
| 12:57.09 | tsearle | then I guess my issue just fanishes :-P |
| 12:57.13 | tsearle | vanishes |
| 12:57.39 | seanbright | the trailing number is the number of samples per second (times 1000) |
| 12:58.24 | seanbright | the 'slin' == 'slin8' = 8kHz |
| 12:59.53 | *** join/#asterisk-dev Bordr (~Bordr@c-24-9-55-138.hsd1.co.comcast.net) |
| 13:06.05 | file | Tuesday, the day after Monday |
| 13:17.12 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-oucveuypxyesmuqt) |
| 13:17.12 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:36.21 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:58.39 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tmdtumpfjvfsuyze) |
| 13:58.39 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:08.00 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:11.44 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:11.44 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:12.11 | file | cresl1n: it's you again! you keep showing up |
| 14:13.37 | cresl1n | I do on occasion :-) |
| 14:20.07 | cresl1n | gtjoseph: for https://gerrit.asterisk.org/#/c/5986/ should we make the new behavior optional? |
| 14:20.22 | gtjoseph | hmmmm |
| 14:20.29 | cresl1n | i.e. use killpg by default, and use kill if option is specified |
| 14:20.36 | gtjoseph | the only real behavior change is kill vs killpg |
| 14:20.36 | cresl1n | particularly in a release branch |
| 14:20.43 | cresl1n | Yep |
| 14:20.55 | file | 'tis still a behavior change |
| 14:20.58 | cresl1n | yeah |
| 14:21.02 | gtjoseph | well, we could |
| 14:21.07 | cresl1n | particularly within a release branch |
| 14:21.34 | cresl1n | and a behavior that someone explicitly added |
| 14:21.42 | gtjoseph | probable be better to make it a separate option "kill_api" |
| 14:21.49 | file | cresl1n: indeedy |
| 14:21.50 | cresl1n | yeah |
| 14:21.52 | gtjoseph | or "kill_method" |
| 14:21.58 | cresl1n | gtjoseph: I'd be ok with that |
| 14:22.02 | cresl1n | sorry to make it more complicated |
| 14:22.11 | cresl1n | I'll post that to the code review |
| 14:22.12 | gtjoseph | it's simple enough |
| 14:22.24 | cresl1n | wanted to preflight it with you before putting it up there |
| 14:22.26 | gtjoseph | especially since i pulled th ecode into a common function. |
| 14:24.45 | bford | To change AMI version, is manager.h the only file that I need to be concerned with? Just changing the constant for version? Or is it more complicated than that? |
| 14:25.51 | file | I want to say that is it. |
| 14:26.29 | bford | That it is the only file, or that it is more complicated? |
| 14:26.35 | file | only file |
| 14:26.39 | file | is the only one |
| 14:26.40 | seanbright | cresl1n: gtjoseph: re: moh kill thingy |
| 14:27.02 | seanbright | can we not do the config in master and just use 'kill'? |
| 14:27.03 | gtjoseph | yes? |
| 14:27.16 | seanbright | i hate config options that adjust behavior like that |
| 14:27.35 | seanbright | hate is a strong word... i dislike them |
| 14:27.36 | bford | gotcha, thanks! |
| 14:27.42 | cresl1n | seanbright: if we just use kill in 13 and 14 we'll change behavior in a release branch |
| 14:27.45 | gtjoseph | I suppose but I hate modules that get out of sync for non-functional reasons :) |
| 14:28.05 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:28.05 | gtjoseph | he's saying use the option in 13,15 |
| 14:28.09 | gtjoseph | s/15/14 |
| 14:28.14 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 14:28.25 | gtjoseph | but just change it in master |
| 14:28.27 | seanbright | use the option in 13 & 14, don't have it in 15 |
| 14:28.32 | cresl1n | So make it optional in 13/14 and mandatory in master? |
| 14:28.42 | gtjoseph | yep |
| 14:28.44 | seanbright | i might be bike shedding |
| 14:28.51 | cresl1n | I'm gonna say I'd rather it be consistent |
| 14:29.08 | gtjoseph | the problem always comes in when we have to make further changes that now can't be cherry-picked |
| 14:29.09 | cresl1n | also, don't want to change default behavior in master |
| 14:29.32 | cresl1n | IMHO |
| 14:29.37 | seanbright | i've never quite understood that position, but you're the boss |
| 14:29.44 | seanbright | in my mind, master is where shit gets broken |
| 14:29.48 | cresl1n | Well |
| 14:30.07 | cresl1n | The previous behavior was a deliberate contribution by someone a pile of years ago |
| 14:30.16 | cresl1n | it's been like this for 8 yrs or something |
| 14:30.24 | seanbright | the number of people that are actually affected by the killpg vs. kill thing is infinitesimally small |
| 14:30.37 | gtjoseph | but that also was when we didn't allow arbitrary commands. only mpg123 |
| 14:30.54 | cresl1n | gtjoseph: good point |
| 14:31.13 | seanbright | whatever, i'm not going to lose sleep either way |
| 14:31.35 | seanbright | but everytime a configuration option or command line flag is added, i die a bit inside |
| 14:31.48 | seanbright | so please keep that in mind moving forward |
| 14:31.51 | seanbright | :-) |
| 14:32.01 | file | pros and cons, pros and cons |
| 14:32.22 | file | tomato and tomato |
| 14:32.24 | file | er wait that's wrong |
| 14:33.44 | file | seanbright: I also die a bit inside too - but personally if it's reasonable and it help keeps things in sync (so people can more easily cherry pick) I err on the side of doing it |
| 14:33.47 | tsearle | remember that progress is the opposite of congress |
| 14:35.54 | tm1000 | Hey guys.. so https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+ManagerEvent_ContactStatus says it will return the UserAgent, however in 14 thats not there. There's no UserAgent, RegExpire, ViaAddress or CallID. Is there something I'm missing? |
| 14:35.55 | gtjoseph | cresl1n: i'd rather not have divergence so if we add the option, i'd like to make the branches consistent |
| 14:36.01 | cresl1n | so, seanbright, would you be ok with another small part of you dying for patching and branch consistency? |
| 14:36.03 | seanbright | well, if the requirement is that all branches can easily be cherry picked from, then all branches will evntually converge and we can just have 1 version |
| 14:36.15 | cresl1n | YES!!!!! |
| 14:36.17 | gtjoseph | it's not a requirement |
| 14:36.21 | cresl1n | There can be only one! |
| 14:36.26 | cresl1n | pulls his highlander sword out |
| 14:36.31 | gtjoseph | but we can make it one :) |
| 14:36.35 | cresl1n | heh |
| 14:36.36 | file | I treat it as a goal when reasonable and possible |
| 14:36.51 | file | as it reduces the burden not just for us, but for any potential contributors |
| 14:37.40 | gtjoseph | yeah, changes that actually add functionality that should only be in the "next release" are "good"diverges |
| 14:37.41 | cresl1n | gtjoseph: My preference would be consistency across branches |
| 14:37.45 | seanbright | cresl1n: i don't need a vote, just expressing my disdain |
| 14:37.57 | gtjoseph | cresl1n: make the call |
| 14:37.58 | cresl1n | seanbright: You're a member of the dev team, so your vote matters |
| 14:38.19 | seanbright | ok, then i strongly disagree |
| 14:38.21 | seanbright | (kidding) |
| 14:38.28 | cresl1n | troublemaker :-P |
| 14:39.20 | seanbright | every new config option - in my opinion - is technical debt, no matter how well designed it is |
| 14:39.54 | seanbright | (i am not objecting to this particular change, just expressing my thoughts in general) |
| 14:40.11 | file | you aren't wrong, yo |
| 14:40.14 | seanbright | and now i am going to smoke a cigarette |
| 14:40.20 | cresl1n | I won't argue with your reasoning |
| 14:40.32 | cresl1n | we just found a bug that needs to be fixed that requires a new option |
| 14:41.45 | cresl1n | Ok, so we've got to merge it while seanbright is taking a smoke break. gtjoseph - move out, fast, fast, fast, fast! |
| 14:41.52 | cresl1n | seanbright: j/k of course :-) |
| 14:41.54 | gtjoseph | already coding :) |
| 14:42.21 | cresl1n | in all seriousness though, I think we need to be consistent across branches with patches for our own work load |
| 14:42.27 | cresl1n | so let's go forward with that decision |
| 14:42.42 | cresl1n | at least when we can |
| 14:43.46 | tsearle | coding style question, do you prefer short or uint16_t ? (I see both being used for frame buffers) |
| 14:45.59 | cresl1n | I'm an old kernel man, and I like uint16_t because you know what it is on whatever platform you're on |
| 14:46.06 | cresl1n | what do you think file? |
| 14:46.19 | file | I don't have a preference, 'nor do we dictate one |
| 14:46.39 | tsearle | ok, well I'm old school too so I used uint16_t |
| 14:47.03 | cresl1n | code quickly |
| 14:47.08 | cresl1n | we have 9 days until feature freeze |
| 14:47.10 | cresl1n | :-P |
| 14:47.20 | cresl1n | Sorry, 8 now |
| 14:47.26 | cresl1n | Yesterday was 9 |
| 14:47.27 | tsearle | well approve my gerrits quickly :-P |
| 14:47.36 | cresl1n | Good point, actually |
| 14:47.51 | file | in the past as long as the feature was up in gerrit before then it was fine |
| 14:48.13 | cresl1n | excellent |
| 14:48.41 | cresl1n | That'll help a lot then |
| 14:48.41 | tsearle | I have another gerrit on the way for ast14, file is already aware it's coming, heh |
| 14:48.41 | file | cresl1n: I've been meaning to tell you that but kept forgetting :P I was busy or something |
| 14:48.44 | cresl1n | I'd forgotten actually |
| 14:48.50 | cresl1n | we did it last year, and I just forgot |
| 14:49.48 | tsearle | but this is a freeze for 13.17.0 or a more major freeze? |
| 14:49.59 | file | cresl1n is referring to the feature freeze for 15 |
| 14:50.09 | file | 13.17.0 is already in RC status |
| 14:50.11 | tsearle | ha |
| 14:50.54 | cresl1n | thanks file |
| 14:51.10 | tsearle | the only features I put in 15 are the ones I cherrypick from 13 ;-) |
| 14:55.15 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-uagapuevxjkmgwtj) |
| 14:55.15 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:15.59 | cresl1n | Ok, so question 2 |
| 15:16.00 | cresl1n | https://gerrit.asterisk.org/#/c/5924/1/apps/app_queue.c |
| 15:16.13 | cresl1n | Well, more generally, https://gerrit.asterisk.org/#/c/5924/ |
| 15:16.25 | cresl1n | Should we have bumped AMI minor version for that? |
| 15:16.48 | file | I don't... know... |
| 15:16.54 | seanbright | it's not breaking |
| 15:16.58 | cresl1n | yeah |
| 15:17.04 | cresl1n | so no major version bump for sure, right? |
| 15:17.08 | seanbright | correct |
| 15:17.15 | seanbright | at least from a semver standpoint |
| 15:17.27 | cresl1n | yeah |
| 15:22.18 | coreyfarrell | cresl1n: IMO we should just ensure that Asterisk 15 is AMI 4.x.x (since Asterisk 14 is AMI 3.x.x). I don't think it's possible to be fully compliant with semver for AMI/ARI. |
| 15:22.36 | cresl1n | That was the plan |
| 15:22.39 | cresl1n | I think from the -dev list |
| 15:22.46 | cresl1n | is reading back over the version discussion |
| 15:23.28 | cresl1n | So for master, I think https://gerrit.asterisk.org/#/c/5924/ is ok |
| 15:23.55 | cresl1n | Assuming we're going to bump master/15 to 4.0.0 when we cut the branch |
| 15:24.09 | cresl1n | but for 13/14 we need to bump the least significant digit |
| 15:24.16 | cresl1n | at least if I'm reading our discussion correctly |
| 15:24.25 | coreyfarrell | I would agree with that. |
| 15:25.43 | coreyfarrell | this leaves a question about https://gerrit.asterisk.org/5929 - do we want that commit to bump the AMI major version or do it separately before branching 15? |
| 15:26.34 | cresl1n | I was thinking we've got to set it to 4.0.0 when we cut the 15 branch anyways, right? |
| 15:27.22 | cresl1n | So part of the work of cutting 15 will require setting the AMI/ARI versions to 4.0.0 was what I was thinking |
| 15:27.33 | coreyfarrell | yes. my only question is when that should happen. |
| 15:27.40 | cresl1n | in 9 days? |
| 15:27.41 | cresl1n | :-) |
| 15:27.47 | cresl1n | 8 days I guess |
| 15:30.32 | coreyfarrell | I meant should it be done as part of https://gerrit.asterisk.org/5929 or as a separate commit while cutting 15.. |
| 15:30.39 | coreyfarrell | doesn't matter that much I guess |
| 15:30.47 | cresl1n | I think a separate commit after cutting 15 |
| 15:30.55 | cresl1n | in case something else comes up :-) |
| 15:31.06 | cresl1n | but for the 13/14 changes, they need to be bumped by those commits |
| 15:49.18 | gtjoseph | the new moh review for 13 is back up for review. i'm not going to push to the other branches until the 13 version gets the OK since there are CHANGES changes that have to be done manually. |
| 15:49.27 | cresl1n | thanks gtjoseph |
| 15:50.58 | gtjoseph | dammit already see a formatting issue :) |
| 15:53.13 | gtjoseph | there we go, that's better |
| 16:20.04 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.167) |
| 16:20.53 | bford | For https://jira.digium.com/browse/SWP-9836, I did some grep searching with variations of packet, max, size, etc. but am not sure what is relevant. I saw PJMEDIA_MAX_MRU/MTU - is this responsible for determining pjsip max packet size? |
| 16:21.08 | gtjoseph | look in config_site.h |
| 16:21.26 | gtjoseph | third-party/pjproject/patches/config_site.h |
| 16:21.32 | bford | thanks |
| 16:22.00 | gtjoseph | it's a fixed buffer because there's no way to tell how big of a packet you're going to get untill you get it |
| 16:23.11 | file | a discussion yesterday reminded me, websockets have a fixed size for packet size too - having them match if possible maybe the answer? 'tis 32k |
| 16:23.18 | file | erm may be |
| 16:23.28 | bford | Ah, I see it - PJSIP_MAX_PKT_LEN |
| 16:23.35 | file | yup |
| 16:23.37 | bford | discussion in here or swdev? |
| 16:23.46 | bford | for the websocket thing |
| 16:23.46 | file | here |
| 16:24.01 | file | may have been before or after people left |
| 16:24.07 | kharwell | any reason to not make the max packet length as large as it can be? |
| 16:24.20 | gtjoseph | memory overhead for every packet allocated |
| 16:24.48 | kharwell | so pjproject just allocates the max packet size of each packet? |
| 16:24.55 | gtjoseph | yeah it has to |
| 16:24.57 | file | yes |
| 16:25.06 | gtjoseph | there's no way to know how big the next packet will be |
| 16:25.12 | gtjoseph | until you get it |
| 16:26.35 | gtjoseph | every rdata has a buffer allocated |
| 16:26.35 | kharwell | I was thinking that was just the size of the read/write buffers and then from there one should be able to determine the size of the packet once fully read |
| 16:26.52 | kharwell | but ya if that is not the case then I can see why you'd want to make it smaller |
| 16:26.57 | gtjoseph | no because it's a reconstruction of the entire packet |
| 16:27.12 | gtjoseph | actually "message" |
| 16:28.26 | seanbright | 6k is pretty big for a sip message |
| 16:28.26 | gtjoseph | not with ice, etc |
| 16:28.29 | file | seanbright: WebRTC. |
| 16:28.33 | gtjoseph | or webrtc |
| 16:28.41 | seanbright | what is the pathological case you've seen? |
| 16:29.06 | file | my laptop hits 6k easy because of all the ICE candidates |
| 16:29.07 | file | throw in the addition of more streams, even with bundle, and it goes even higher |
| 16:29.13 | seanbright | "easy" |
| 16:29.21 | seanbright | how many interfaces do you have? |
| 16:29.37 | file | ethernet and wifi, and whatever else it considers as a viable interface |
| 16:29.42 | file | IPv4+IPv6 |
| 16:29.46 | file | TCP + UDP |
| 16:29.51 | file | and relay candidates |
| 16:30.06 | seanbright | a candidate line is what? 100 bytes or so? |
| 16:30.18 | file | depends, hold |
| 16:30.46 | gtjoseph | I "suppose" we may be able to add logic to pjproject to capture just the headers in a fixed size buffer, then get content-length, then allocate a dynamic buffer. for the entire message |
| 16:30.50 | seanbright | you would think that pjsip would maintain a thread local buffer for reads and then allocate only what is necessary |
| 16:31.02 | seanbright | i guess if you allocate for each packet you save the memcpy |
| 16:31.27 | gtjoseph | but that would require the logic i just outlined |
| 16:31.57 | gtjoseph | the fixed buffer is also easier to garbage collect |
| 16:31.58 | gtjoseph | because it's part of the rdata allocation |
| 16:32.24 | file | glares at Tim Horton's wifi |
| 16:34.54 | gtjoseph | too bad the packet array is right in the middle of the rdata structure |
| 16:35.20 | file | seanbright: https://pastebin.com/q6vguYB6 |
| 16:36.29 | seanbright | nice. well under 6k. |
| 16:36.29 | seanbright | "well under" |
| 16:36.29 | seanbright | but under nonetheless |
| 16:36.37 | file | unless you add more streams |
| 16:36.37 | seanbright | is assuming that sublime is counting EOLs |
| 16:37.05 | file | here, lemme do a thing |
| 16:39.31 | seanbright | heh |
| 16:39.31 | seanbright | i believe you |
| 16:39.31 | seanbright | what are you bumping it to? |
| 16:39.31 | seanbright | 16k? |
| 16:39.31 | file | ha no |
| 16:39.31 | file | I'm going to see what my current StreamEcho produces |
| 16:39.31 | seanbright | 65536 is the max that i will allow |
| 16:39.31 | gtjoseph | i think 32k will probably have to be the minimum |
| 16:39.31 | seanbright | jeebus |
| 16:39.31 | file | the answer is: too much to have it show up on screen |
| 16:39.31 | file | 8k of SDP in it |
| 16:39.31 | bford | So other than memory constraints, are there any other repercussions to changing the max packet size? Changing to match websocket value seems to be the consensus right now |
| 16:39.31 | seanbright | nutty |
| 16:40.14 | gtjoseph | well, let's say 32k then the question becomes, how many rdata structures could there be allocated at any one time on a heavily used system. |
| 16:41.04 | gtjoseph | if you're a service provider, a lot. |
| 16:41.04 | gtjoseph | although they should last the lifetime of the transaction (not call) |
| 16:42.02 | file | seanbright: https://pastebin.com/cZEx1XgY if you're curious |
| 16:43.54 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 16:43.54 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 16:44.48 | gtjoseph | so i guess if we want this in 2.6, our only option is to just increase the fixed buffer. |
| 16:44.48 | gtjoseph | so there are no actual pjproject changes |
| 16:44.49 | file | I think bumping it up to match the websocket limit is acceptable, but bford - spend a bit of time seeing the repercussions of making it dynamic and if it's possible |
| 16:44.50 | rmudgett | Asterisk gets into the act of a fixed sized buffer: struct subscription_persistence has a packet[] of that size. |
| 16:45.14 | file | if it's possible we can approach Teluu in the future and go from there |
| 16:45.22 | gtjoseph | yeah, the ripple effect might be a bit "much" |
| 16:45.30 | gtjoseph | yep |
| 16:45.47 | file | but the immediate bump will help others (tm1000 had to bump it up) and it'll stop me from having to bump it up for multistream, win! |
| 16:46.27 | gtjoseph | yep |
| 16:46.27 | bford | ok, I'll take a look |
| 16:47.09 | *** join/#asterisk-dev joshelson (~joshelson@75.104.70.10) |
| 16:47.27 | file | bford: and we'd all like ice cream |
| 16:47.41 | gtjoseph | I'll shoot a note to Teluu tonight broaching the issue and seeing if they have any ideas |
| 16:47.58 | file | CC in Ben, yada yada |
| 16:48.16 | gtjoseph | yep |
| 16:50.39 | tm1000 | file: gtjoseph yay! I helped make you do a thing sort of kind of |
| 16:50.47 | gtjoseph | :) |
| 16:50.56 | file | sure |
| 16:51.26 | bford | ice cream actually does sound good... being healthy sucks |
| 16:52.13 | gtjoseph | mmmm. maybe a trip to dairy queen after tacos |
| 17:17.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 17:30.50 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-gexuharxligzoljn) |
| 17:30.50 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:59.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 17:59.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:00.52 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-gsoipjxzoasvjvhc) |
| 18:00.53 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:06.36 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pbnjnokmxpsgutwn) |
| 18:06.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:22.39 | *** join/#asterisk-dev newtonr (~newtonr@99-104-129-136.lightspeed.brhmal.sbcglobal.net) |
| 18:22.39 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:58.13 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 18:58.31 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-zzxkwfhveusruiqh) |
| 18:58.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:07.59 | rmudgett | gtjoseph: I just thought of something. The moh patch uses a function pointer for the kill and killpg calls. Since these are the only references, they are treated as data by the linker and may not be setup correctly. |
| 19:08.50 | gtjoseph | hmmmmm |
| 19:09.04 | rmudgett | We've had that problem in the past when the only reference to a function outside of the module never got setup. |
| 19:09.26 | rmudgett | If it were a parameter passed to a function. |
| 19:09.44 | gtjoseph | got s reference? |
| 19:09.59 | rmudgett | looking |
| 19:11.06 | gtjoseph | I guess I can just make it a macro. after I take a break. |
| 19:12.20 | rmudgett | Either that or use local wrapper functions to explicitly call kill and killpg |
| 19:12.44 | rmudgett | Example in res_pjsip_endpoint_identifier.c:my_cli_traverse_objects() |
| 19:12.44 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 19:13.54 | gtjoseph | will look in a few |
| 19:14.22 | seanbright | res_pjsip_endpoint_identifier_ip.c* |
| 19:14.47 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 19:14.47 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 19:46.26 | file | mmm muffin |
| 20:09.01 | bford | https://gerrit.asterisk.org/#/c/5929/ I've bumped AMI version up, but that won't actually happen until the cut for 15 - should I remove the version level changes in the commit and let that get taken care of when we release 15? |
| 20:09.51 | rmudgett | leave it till 15 |
| 20:10.18 | bford | ok, I'll update the review |
| 20:25.28 | gtjoseph | @rmudgett: i think the issue in res_pjsip_endpoint_identifer_ip was that ast_sip_cli_traverse_objects was defined in res_pjsip which is opened with dlopen rather than a system library. |
| 20:26.17 | gtjoseph | kill and killpg are calls resolved by the system |
| 20:26.17 | rmudgett | It would be the same mechanism though. |
| 20:26.22 | gtjoseph | not really |
| 20:26.37 | gtjoseph | in the former case, we control when res_pjsip is loaded |
| 20:27.05 | gtjoseph | not the system |
| 20:27.37 | gtjoseph | res_pjsip_endpoint_identifier_ip isn't linked with res_pjsip |
| 20:27.39 | rmudgett | Are kill and killpg referenced by asterisk's core so they would already be available for resolution? |
| 20:27.50 | gtjoseph | it doesn't matter |
| 20:28.00 | gtjoseph | res_musiconhold IS linked with them directly |
| 20:30.08 | rmudgett | res_musiconhold is a dynamically linked library loaded at an arbitrary time. I'm not sure that those symbols would always be resolved. |
| 20:31.06 | gtjoseph | i'll change them to be safe but i think it's not necessary. |
| 20:32.25 | gtjoseph | if you do a readelf on res_musiconhold.so you'll see them as kill@GLIBC_2.2.5 |
| 20:37.15 | rmudgett | Are they that way with the patch? |
| 20:38.03 | gtjoseph | yeah |
| 20:38.03 | gtjoseph | too late though, i've already started changing them |
| 20:38.40 | rmudgett | Probably better to wrap the calls with a local stub to be safe. |
| 22:45.47 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 22:45.47 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 23:07.17 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-tmdtumpfjvfsuyze) |