| 00:11.44 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:11.44 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:15.12 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 00:35.11 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 01:37.58 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:2c69:3fe8:2e45:5737) |
| 01:37.58 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:55.09 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 01:55.09 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 01:59.08 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:11.25 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 02:11.25 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 03:11.24 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:8d9d:f14b:717:b0a6) |
| 03:11.24 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 04:15.46 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 06:08.53 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:35.29 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:35.29 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:43.33 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:43.33 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:47.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:43.56 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:58.46 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:16.17 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 09:52.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 09:52.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:19.41 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.cablep.bezeqint.net) |
| 11:19.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:22.25 | tsearle | waves to tzafrir |
| 11:37.19 | tsearle | is there a way to tell if a given ast_format is of type DTMF? |
| 11:50.33 | file | There is no format for DTMF |
| 11:50.50 | file | It is in its own frame types |
| 12:00.41 | tsearle | so if you have a payload_type=>rtp_code == AST_RTP_DTMF payload_type->format would be ast_format_none then? |
| 12:01.21 | file | Probably null, not none |
| 12:01.37 | file | There is a field which says if it is an Asterisk format or not |
| 12:02.58 | tsearle | you sure about the null? I see that ao2_replace(rtp->lastrxformat, payload_type->format); is done w/o a null check |
| 12:04.29 | file | That is null safe I believe anyway but I'm not near the code |
| 12:05.07 | tsearle | ok cool, then I guess I can simplify the code then |
| 12:05.33 | tsearle | the code == "my patch" |
| 12:44.58 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-138-222.dialup.adsl.anteldata.net.uy) |
| 12:57.30 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 12:57.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:19.44 | tsearle | it's quiet here today |
| 13:21.27 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-zuqjrpcvoacqsksg) |
| 13:21.27 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:33.05 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-189-147.dialup.adsl.anteldata.net.uy) |
| 13:33.50 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-xatsrppflkpeqhpy) |
| 13:33.50 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:44.30 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:44.30 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:49.55 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 14:05.39 | tsearle | waves to cresl1n |
| 14:05.48 | cresl1n | hi |
| 14:05.49 | cresl1n | :-) |
| 14:29.03 | cresl1n | How's the Parvis St Gilles coming along? |
| 14:30.12 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:30.12 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:30.14 | tsearle | it going, going to take awhile the first phase is getting rid of the road, though they are digging trenches in it a the moment |
| 14:52.08 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-tbtkuvmqnludrput) |
| 14:52.08 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:15.47 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 15:15.48 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 15:19.44 | seanbright | coreyfarrell: my issue wi the warning fix patch is that in some cases we are replacing magic numbers with other magic numbers |
| 15:43.45 | coreyfarrell | seanbright: agreed but not sure a better way to fix it. some of the stuff could be switched to 'struct ast_str' or stringfields but that seems higher impact / maybe better for master only? |
| 15:48.29 | coreyfarrell | seanbright: I could create a `#define AST_INT_LENGTH 16` to use for buffers that get "%d", that would get rid of a few of the magic numbers, but I'm guessing you're more bothered by things like: char monitor_dir[PATH_MAX + 8]; |
| 15:50.12 | coreyfarrell | I'd prefer to avoid setting -Wno-format-truncation as it did find a few legitimate issues where snprintf could be truncated. |
| 16:01.51 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-206-134.dialup.adsl.anteldata.net.uy) |
| 16:02.33 | seanbright | coreyfarrell: can you give a symbolic name to the "8" in that example? |
| 16:02.35 | seanbright | what is "8"? |
| 16:05.16 | coreyfarrell | 8 is strlen("/monitor"). we're appending that to spool_dir (a PATH_MAX buffer). |
| 16:05.58 | seanbright | so maybe: char monitor_dir[PATH_MAX + sizeof("/monitor") - 1]; |
| 16:06.33 | seanbright | still a compile-time constant |
| 16:07.03 | coreyfarrell | hmm I'm thinking `#define MONITOR_SUBDIR "/monitor"` then use sizeof(MONITOR_SUBDIR) and use that define in the snprintf |
| 16:32.07 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 17:04.39 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-qcnteodmiiaepiea) |
| 17:04.39 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:07.08 | *** join/#asterisk-dev jamesp_ (256efb42@gateway/web/freenode/ip.37.110.251.66) |
| 17:07.33 | jamesp_ | hey guys, gtjoseph/seanbright - i'm back (yay i hear you cry). |
| 17:08.31 | jamesp_ | sorry to ask but we have some horrible horrible issues here with corosync and i wanted to ask if you know of any reason. We're 13.17.0. When we make a small change in corosync and it's linked to res_corosync, we totally kill our network |
| 17:08.40 | jamesp_ | corosync goes totally radio rental |
| 17:08.51 | seanbright | no clue |
| 17:09.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 17:09.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:09.29 | jamesp_ | if there anyway to debug the communication between asterisk and corosync ? |
| 17:09.35 | seanbright | no clue |
| 17:09.37 | seanbright | heh |
| 17:09.41 | seanbright | i don't know anything about corosync |
| 17:10.03 | jamesp_ | oh... ok!! gtjoseph is the man? |
| 17:10.22 | seanbright | sure |
| 17:10.41 | jamesp_ | each machine generates like 800MB/sec - it's f**ing killing us |
| 17:11.27 | jamesp_ | B not b - yeah! |
| 17:11.34 | seanbright | have you turned on debugging? |
| 17:11.41 | jamesp_ | asterisk - yes |
| 17:11.50 | seanbright | ok, so that should show you what is getting sent to corosync |
| 17:12.01 | seanbright | from asterisk |
| 17:12.10 | jamesp_ | it's true |
| 17:13.30 | jamesp_ | we're going to try to recreat in the lab - see what's what. When is 'goes' it kills the network so bad you can't logon to stop it, and at the same time we're killing the customer calls (c. 800 concurrent) |
| 17:13.40 | jamesp_ | (not a popular place to be right now...!) |
| 17:14.01 | seanbright | sounds like some kind of amplification |
| 17:14.28 | seanbright | so if res_corosync is not loaded and you make a change in corosync, the issue doesn't occur? |
| 17:14.38 | jamesp_ | yes.. |
| 17:14.47 | jamesp_ | some kind of loop |
| 17:14.54 | seanbright | i guess asterisk is handling some kind of event from corosync and then genearting its own event which gets fed back |
| 17:15.05 | seanbright | but i know approximately squat about corosync so who knows |
| 17:15.37 | jamesp_ | it could be, but it seems when it's in a happy state, all is ok.. we can run happily for hours. Then we run a test, eg change the ring name and boom |
| 17:15.46 | jamesp_ | public enemy number 1 again!! |
| 17:16.01 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 17:16.01 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 17:16.01 | jamesp_ | (hating this shit on a friday night) |
| 17:16.06 | jamesp_ | (needs more beer) |
| 17:16.34 | jamesp_ | res_corosync question... |
| 17:16.39 | jamesp_ | ummm. don't know |
| 17:16.50 | jamesp_ | so if res_corosync is not loaded and you make a change in corosync, the issue doesn't occur? |
| 17:17.01 | jamesp_ | difficult to test atm tbh |
| 17:17.45 | jamesp_ | what we do know is as soon as corosync starts on the broken node it starts immediately. |
| 17:19.15 | jamesp_ | ..the problem |
| 17:24.45 | jamesp_ | we have 8 nodes in the cluster |
| 17:45.03 | gtjoseph | for the record, the only thing i know about corosync is "menuselect --disable res_corosync" |
| 19:03.05 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 19:38.21 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-tnlpnfeykwkecwdn) |
| 19:38.22 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:40.53 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mfclyschoiamdvfx) |
| 19:40.53 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:15.57 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-yjiqzkikakidrzbv) |
| 20:15.57 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:57.25 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-leaptbypackitzkr) |
| 20:57.25 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:08.33 | *** join/#asterisk-dev joshelson (~joshelson@c-68-33-77-218.hsd1.md.comcast.net) |
| 21:59.36 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 22:42.12 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |