| 05:59.22 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 05:59.22 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:30.01 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:52.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:53.49 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:44.35 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-106-97.hsd1.co.comcast.net) |
| 07:53.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:34.43 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.173) |
| 11:38.15 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:29.21 | *** join/#asterisk-dev dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 14:22.52 | tsearle | good morning all, I have a quick question ref res_pjsip_nat |
| 14:23.09 | tsearle | for every message received, I see the method nat_on_rx_message gets invoked multiple times |
| 14:23.21 | tsearle | first w/o a dlg reference then with a dlg reference |
| 14:23.31 | tsearle | is there a reason for this multiple invokation? |
| 14:23.57 | tsearle | it's causing issue with the dlg->is_routeset_frozen logic |
| 14:24.32 | file | that's a PJSIP module, so it occurs based on logic inside the PJSIP core and UA layer, why it gets called like that specifically don't know |
| 14:25.54 | tsearle | ok, any objections if I add a if (!dlg) return PJ_FALSE so the nat handler only gets performed when the dialog is properly set? |
| 14:27.04 | tsearle | from my analysis, even an inital invite gets called twice, the 2nd time with a dlg pointer correctly set |
| 14:27.20 | tsearle | so I don't see adding the dlg check breaking anything... |
| 14:28.29 | file | I don't know of the repercussions of that, it may still work as it should or in some scenario it may cause ripples |
| 14:47.41 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-mdfgwpugxtzeacmm) |
| 14:47.41 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:54.22 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-swbkuougumtuweyx) |
| 14:54.22 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:57.28 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.172) |
| 15:00.59 | *** join/#asterisk-dev jkroon__ (~jkroon@165.16.204.168) |
| 16:33.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00780268262962c712.ipv6.abo.wanadoo.fr) |
| 17:34.42 | jameswf | I want be next vonnage, you write k? |
| 17:35.00 | jameswf | You will be paid in exposure.... |
| 17:48.48 | rmudgett | coreyfarrell: I thought preload no longer had a special meaning in v16 |
| 17:52.23 | coreyfarrell | rmudgett: in theory nobody should need to use it. it's not needed for main/*.c to use realtime config. |
| 17:54.01 | coreyfarrell | it can still be used to force a module to load early compared to the load_priority. doing that will force dependent modules to preload but will not force non-dependent modules of earlier priority to preload. |
| 17:56.44 | rmudgett | coreyfarrell: Looks like module_vector_cmp() has the preload comparison backwards. |
| 17:59.15 | coreyfarrell | rmudgett: have you tested it? the higher flags.preload (1) belongs first in the vector vs the lower load_pri goes first. |
| 18:00.34 | rmudgett | Yeah. It just looked backwards "b - a" rather than "a - b". But in preload's case the higher value needs to sort first. |
| 18:20.47 | rmudgett | modules.conf.sample is a bit misleading now because it still talks about preload for realtime configuration. |
| 18:26.47 | coreyfarrell | rmudgett: true. I'm not sure the best way to update that, maybe document that preload is a legacy option and generally should not be used? likely no harm would be caused by preloading a realtime module as they are very early priority anyways. |
| 18:54.23 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 18:54.23 | *** 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 |
| 19:57.33 | leifmadsen | jsmith: ping? |
| 20:01.05 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 20:41.26 | leifmadsen | jsmith: ping retracted, I figured it out I think :) (building stuff out of git.centos.org) |
| 21:04.57 | jsmith | leifmadsen: pong (to your semi-retracted kind of ping) |
| 21:05.08 | jsmith | leifmadsen: (and sorry for the latency -- just got back from lunch, finally |
| 21:05.15 | leifmadsen | all good, np |
| 21:05.20 | jsmith | leifmadsen: Get it figured out? |
| 21:05.27 | leifmadsen | yep, kernel-rt is building :) |
| 21:05.37 | leifmadsen | the answer was "centos-common-tools" |
| 21:06.00 | jsmith | Eeeew... -rt? We don't talk about such things in the Asterisk dev channel :-p |
| 21:06.13 | leifmadsen | haha we do in the real telco world :) |
| 21:06.35 | leifmadsen | not only am I building the RT kernel, I'm also going to be patching it... |
| 21:06.38 | leifmadsen | and then rebuilding it |
| 21:06.47 | leifmadsen | UGH |
| 21:06.55 | leifmadsen | and my build just failed because I ran out of disk space |
| 21:31.39 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5361-63.w90-105.abo.wanadoo.fr) |
| 22:38.32 | snuff-work | kernel RT isn't terrible.. if you have well behaved apps that dont abuse their power =D |
| 23:03.12 | *** join/#asterisk-dev FrankyCyborg (~FrankyCyb@p54849217.dip0.t-ipconnect.de) |
| 23:55.18 | tm1000 | jsmith: some guy got drunk at Astricon and told me the secret to voip is kernel-rt |
| 23:55.45 | tm1000 | So I deflected to GameGamer43 |
| 23:55.47 | tm1000 | :) |
| 23:55.58 | leifmadsen | tell no one |
| 23:56.31 | file | I thought the secret was running a call center on Google Voice trunks |
| 23:57.06 | tm1000 | file: that's AFTER you build a real time kernel. Second step is use Google voice. Third is??? Fourth is profit. |
| 23:57.30 | leifmadsen | I store all my voicemail in gmail via imap |