| 00:05.27 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-smyftwngfbtbabda) |
| 00:06.36 | tm1000 | gtjoseph: when I run pjsip show endpoints it shows it as unavalible. |
| 00:06.46 | tm1000 | but EXTENSION_STATE(1000) shows NOT_INUSE |
| 00:07.28 | gtjoseph | what does core show hints say? |
| 00:07.30 | tm1000 | and yes it's >0 |
| 00:08.18 | tm1000 | 1000@ext-local : PJSIP/1000&SIP/90100 State:Idle Presence:available Watchers 3 |
| 00:08.20 | tm1000 | what.... |
| 00:09.05 | tm1000 | SIP/90100 is offline as well |
| 00:09.21 | gtjoseph | but it's a composite hint |
| 00:09.29 | gtjoseph | so i'm not sure we can figure that out |
| 00:09.49 | tm1000 | gtjoseph: its always worked for sip? |
| 00:09.54 | tm1000 | is this a limitation of pjsip? |
| 00:10.05 | gtjoseph | for multiple peers in a hint? |
| 00:10.16 | tm1000 | yeah |
| 00:10.27 | gtjoseph | then it should work here |
| 00:10.30 | gtjoseph | hmmm |
| 00:11.45 | gtjoseph | give me a sec to test something |
| 00:11.48 | tm1000 | gtjoseph: ok maybe I thought it did |
| 00:12.01 | tm1000 | 1008@ext-local : PJSIP/1008&SIP/99100 State:Unavailable |
| 00:12.06 | tm1000 | that one is correct |
| 00:12.14 | tm1000 | 1008@ext-local : PJSIP/1008&SIP/991008 State:Unavailable |
| 00:13.30 | tm1000 | the entire hint is |
| 00:13.30 | tm1000 | PJSIP/1000&SIP/901000&SIP/991000&Custom:DND1000,CustomPresence:1000 |
| 00:15.18 | tm1000 | freepbxdev1*CLI> core show hint 1000 |
| 00:15.18 | tm1000 | 1000@ext-local : PJSIP/1000 State:Idle Presence:available Watchers 3 |
| 00:15.22 | gtjoseph | i wonder if it's the presence info. with just pjsip, it works correctly |
| 00:15.24 | tm1000 | I cleared everything out |
| 00:15.36 | tm1000 | and only have PJSIP/1000 then did a dialplan reload. still shows idle?? |
| 00:15.41 | gtjoseph | why does presence show available? |
| 00:16.04 | tm1000 | gtjoseph: we do set that |
| 00:16.17 | tm1000 | gtjoseph: is that messing with it? |
| 00:16.27 | gtjoseph | possibly. i'm testing |
| 00:17.23 | tm1000 | strangely when I use EXTENSION_STATE(1000) now it works! |
| 00:17.31 | tm1000 | it says its unavailable |
| 00:17.41 | tm1000 | freepbxdev1*CLI> core show hint 1000 |
| 00:17.42 | tm1000 | 1000@ext-local : PJSIP/1000 State:Idle Presence:available Watchers 3 |
| 00:17.42 | tm1000 | 1 hint matching extension 1000 |
| 00:17.46 | tm1000 | yet that remains... |
| 00:18.20 | gtjoseph | so what's the hint now? |
| 00:18.38 | tm1000 | it was still idle |
| 00:18.44 | file | hopes you are just leaving out the context from both the EXTENSION_STATE and core show hint on purpose |
| 00:19.02 | tm1000 | file: it should be default but I will humor you |
| 00:19.07 | gtjoseph | i meant the full specified hint |
| 00:19.40 | file | just making sure that you realized that |
| 00:19.58 | tm1000 | I dont know where to put the context on core show hint. I guess 1000@default |
| 00:20.14 | tm1000 | gtjoseph: it's just "PJSIP/1000" |
| 00:20.22 | tm1000 | hold on i know what you want |
| 00:20.24 | tm1000 | going to get it |
| 00:21.00 | tm1000 | it was |
| 00:21.00 | tm1000 | exten => 1000,hint,PJSIP/1000&SIP/901000&SIP/991000&Custom:DND1000,CustomPresence:1000 |
| 00:21.03 | gtjoseph | ok, i think it's the custom presence because when I try just PJSIP/1000&PJSIP/1001 it works as expected |
| 00:21.03 | tm1000 | now its |
| 00:21.07 | tm1000 | exten => 1000,hint,PJSIP/1000 |
| 00:21.18 | tm1000 | ah |
| 00:21.20 | tm1000 | let me remove that |
| 00:22.13 | tm1000 | EXTENSION_STATE: NOT_INUSE |
| 00:22.32 | gtjoseph | core show hints? |
| 00:23.09 | file | should get the DEVICE_STATE of the PJSIP endpoint to confirm the device state |
| 00:23.14 | tm1000 | freepbxdev1*CLI> core show hint 1000 |
| 00:23.14 | tm1000 | 1000@ext-local : PJSIP/1000&SIP/90100 State:Idle Presence:available Watchers 3 |
| 00:23.26 | file | same for anything else |
| 00:23.31 | tm1000 | so when I removed "Custom:DND1000" EXTENSION_STATE started working |
| 00:23.33 | gtjoseph | still showing presense available |
| 00:23.48 | gtjoseph | oh |
| 00:23.50 | gtjoseph | ok |
| 00:24.13 | tm1000 | So I guess thats overriding it. which is technically correct. |
| 00:24.25 | tm1000 | I think? |
| 00:24.27 | file | yes, it's an aggregate of all components |
| 00:24.37 | tm1000 | yeah |
| 00:24.43 | tm1000 | I dont know why I never noticed this before |
| 00:24.53 | tm1000 | thanks guy |
| 00:24.55 | tm1000 | guys* |
| 00:25.00 | gtjoseph | no problem |
| 01:06.07 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 01:30.27 | *** join/#asterisk-dev pnlarsson (~niklas@2a02:760:1000:6:8e89:a5ff:fe60:f5f0) |
| 06:29.32 | *** join/#asterisk-dev file__ (uid178970@asterisk/developer-and-muffin-lover/file) |
| 06:29.32 | *** mode/#asterisk-dev [+o file__] by ChanServ |
| 07:02.23 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:20.05 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 07:39.06 | *** part/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 07:43.52 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:52.42 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:55.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:00.29 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:00.50 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:06.04 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:35.21 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::10de) |
| 09:51.35 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:25.58 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 10:56.16 | *** join/#asterisk-dev libardi (~libardi@187.64.235.241) |
| 14:06.27 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 14:06.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:18.19 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-32-120-188.hsd1.al.comcast.net) |
| 14:18.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:21.37 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 14:28.09 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-sbqocbzdywcqfjih) |
| 14:28.09 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:34.18 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:34.18 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:35.23 | file | A wild cresl1n appears. |
| 14:35.30 | cresl1n | runs |
| 14:35.45 | file | throws pokeball |
| 14:35.53 | cresl1n | darn. |
| 14:35.58 | cresl1n | You got me |
| 14:36.16 | file | cresl1n: sup |
| 14:36.25 | cresl1n | Good morning to you sir |
| 14:36.40 | cresl1n | How do you do? |
| 14:36.49 | file | I do. You? |
| 14:37.11 | tsearle | good afternoon :-) |
| 14:37.20 | cresl1n | tsearle!!!!!!! |
| 14:37.27 | cresl1n | Good to see you again :-) |
| 14:37.34 | tsearle | I'm having troube getting PJSIP rtcp stats... |
| 14:37.43 | cresl1n | In what way? |
| 14:38.05 | tsearle | from the docs it seems for pjsip I should do CHANNEL(rtcp,audio,statistic,all,rtt) |
| 14:38.19 | tsearle | but I get [Feb 9 14:37:03] WARNING[28011][C-00000017]: func_channel.c:450 func_channel_read: Unknown or unavailable item requested: 'rtcp,audio,statistic,all,rtt' |
| 14:38.51 | cresl1n | goes to remember how that works |
| 14:39.16 | tsearle | https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_CHANNEL |
| 14:39.20 | tsearle | looking there as a reference |
| 14:39.53 | tsearle | ha, I see what I'm doing wrong |
| 14:40.04 | tsearle | rtt isn't a field in the return |
| 14:40.18 | tsearle | not something you directly specify if you do all |
| 14:41.14 | file | indeedy |
| 14:44.26 | cresl1n | shakes his fist at sudo |
| 14:45.10 | file | cresl1n: Permission Denied. |
| 14:45.19 | tsearle | [Feb 9 14:45:02] WARNING[28056][C-00000019]: func_channel.c:450 func_channel_read: Unknown or unavailable item requested: 'rtcp,audio,statistic,all' |
| 14:45.23 | cresl1n | too late |
| 14:45.24 | tsearle | hrm... still hates me |
| 14:45.28 | cresl1n | this is gonna happen permission or not |
| 14:45.51 | file | tsearle: and you're executing it on a PJSIP channel, not a Local channel? and what's the full execution? |
| 14:46.51 | tsearle | I'm doing a call from pjsip to pjsip |
| 14:47.22 | tsearle | then I am trying to get the stats after the hangup |
| 14:47.57 | tsearle | <PROTECTED> |
| 14:47.57 | tsearle | <PROTECTED> |
| 14:47.57 | tsearle | <PROTECTED> |
| 14:47.57 | tsearle | [Feb 9 14:45:02] WARNING[28040]: pjsip/dialplan_functions.c:551 channel_read_rtcp: Unknown media type field 'statistic,all' for 'rtcp' information |
| 14:47.59 | tsearle | [Feb 9 14:45:02] WARNING[28056][C-00000019]: func_channel.c:450 func_channel_read: Unknown or unavailable item requested: 'rtcp,audio,statistic,all' |
| 14:48.05 | tsearle | so I'm in a pjsip channel |
| 14:48.10 | tsearle | that's invoking agi |
| 14:48.17 | tsearle | and trying to get the info from agi |
| 14:48.51 | file | interesting, it doesn't see the audio part |
| 14:49.25 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:49.38 | tsearle | hrm... I'm using sipp |
| 14:49.44 | file | no I mean in the string |
| 14:50.52 | cresl1n | tsearle: |
| 14:50.55 | file | oh |
| 14:50.56 | cresl1n | I got it working just now |
| 14:50.58 | cresl1n | on my box |
| 14:51.01 | cresl1n | don't use 'statistic' |
| 14:51.18 | cresl1n | I'll show you what i got working |
| 14:51.24 | cresl1n | 'statistic' is a placeholder |
| 14:51.29 | cresl1n | for whatever statistic you want |
| 14:51.32 | tsearle | ha ok |
| 14:51.41 | cresl1n | This worked for me: |
| 14:51.42 | cresl1n | exten => 1,n,Noop(${CHANNEL(rtcp,all,audio)}) |
| 14:51.45 | tsearle | wiki missleading, heh |
| 14:51.48 | cresl1n | yeah... |
| 14:52.05 | cresl1n | if you read the beginning where it talks about the channel function with the value 'item' it becomes clear |
| 14:52.10 | cresl1n | item is not the value itself |
| 14:52.22 | cresl1n | just the placeholder for what you substitute in |
| 14:52.41 | cresl1n | 'statistic' is similar |
| 14:54.21 | tsearle | cool working |
| 14:54.24 | cresl1n | tsearle: did that work? |
| 14:54.29 | cresl1n | EXCELLENT |
| 14:54.50 | tsearle | so one last Q, the all_loss is that # packets lost or % ? |
| 14:55.23 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hlbajfigyxnvxexl) |
| 14:55.23 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:55.25 | cresl1n | docs say packets, no? |
| 14:55.52 | tsearle | all_loss - Retrieve a summary of all RTCP packet loss statistics. |
| 14:56.03 | tsearle | for me that isn't clear |
| 14:56.16 | cresl1n | yeah, but it says "The following data items are returned in a semi-colon delineated list:" |
| 14:56.23 | cresl1n | Ooops |
| 14:56.25 | cresl1n | wrong line |
| 14:56.48 | file | cresl1n: you are correct - or the documentation is wrong |
| 14:56.59 | cresl1n | Anyways, docs look like it says it's a semicolon deliminated list of: |
| 14:57.04 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:57.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:57.09 | cresl1n | â¢minrxlost - Our minimum lost packets |
| 14:57.14 | cresl1n | says packets? |
| 14:57.37 | file | putnopvut: you have returned for another day! |
| 14:57.53 | tsearle | so what does min and max mean in the context of all? X packets lost out of an interval of how many packets? |
| 14:58.24 | putnopvut | file: so you think... |
| 14:58.40 | cresl1n | My guess would be an absolute measurement of the duration of the call, as reported by RTCP? |
| 14:59.20 | cresl1n | coupled with rxcount you could figure out percentages |
| 14:59.25 | tsearle | then min/max/average doesn't make sense there should be only 1 value then |
| 14:59.37 | cresl1n | yeah, good point |
| 15:00.43 | tsearle | brb, switching to wifi |
| 15:01.56 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 15:02.06 | cresl1n | tsearle it looks like it's calculated from the last time that an RTCP packet was expected |
| 15:02.27 | cresl1n | in res/res_rtp_asterisk.c |
| 15:02.52 | cresl1n | from calculate_lost_packet_statistics() |
| 15:03.28 | tsearle | back |
| 15:03.37 | tsearle | back |
| 15:04.02 | cresl1n | I'm guessing you didn't see my message |
| 15:04.06 | cresl1n | tsearle it looks like it's calculated from the last time that an RTCP packet was expected |
| 15:04.06 | cresl1n | 9:02 |
| 15:04.06 | cresl1n | in res/res_rtp_asterisk.c |
| 15:04.06 | cresl1n | 9:02 |
| 15:04.07 | cresl1n | from calculate_lost_packet_statistics() |
| 15:04.37 | tsearle | so it's per rtcp interval |
| 15:04.48 | cresl1n | presumably |
| 15:04.52 | tsearle | so it will be a bit tricky to convert to % I guess :S |
| 15:05.11 | cresl1n | that's the way Asterisk calculates in in the report it sends I think |
| 15:05.52 | cresl1n | s/in in/it in/ |
| 15:07.47 | cresl1n | tsearle: you should check the RTCP specs for more detailed info |
| 15:08.17 | cresl1n | IMHO |
| 15:11.11 | cresl1n | nevermind |
| 15:11.21 | cresl1n | we do try to be smart and make stuff up it seems |
| 15:12.01 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rkpjhrxufjrmonkj) |
| 15:12.01 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:12.41 | cresl1n | minlost is the rtcp report interval that has the fewest lost packets |
| 15:12.54 | cresl1n | that's the way the code seem to read at least |
| 15:12.58 | cresl1n | in update_lost_stats() |
| 15:13.50 | tsearle | but there is no way of knowing how many packets there were in that given report interval right? |
| 15:14.13 | cresl1n | don't know - haven't had to try this before and didn't write the code :-) |
| 15:14.32 | file | legacy code is legacy |
| 15:16.33 | tsearle | if this is legacy code? there is a better way of getting the info? |
| 15:16.59 | file | the RTCP stack is old old old code |
| 15:17.27 | file | so generally when understanding it you have to go back and reread the code |
| 15:17.35 | cresl1n | That's what I've been doing ;-) |
| 15:18.16 | cresl1n | tsearle: ast_rtp_get_stat() is the top end function that extracts the stats you're looking for |
| 15:18.44 | cresl1n | you can trace the data structure members within res/res_rtp_asterisk.c to answer a lot of your quesitons |
| 15:19.27 | cresl1n | Actually, I've mucked around in res_rtp_asterisk.c a few times over the years |
| 15:19.40 | cresl1n | but every time I do I have to remember things |
| 15:20.05 | cresl1n | i.e. go look at the code |
| 15:21.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:24.20 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-giqxzkshzlfzhash) |
| 15:24.20 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:27.56 | tsearle | hint taken :-) (even if the math there scares me, heh) |
| 15:30.51 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 15:31.31 | cresl1n | tsearle: looks like a field for it in the data structure |
| 15:31.35 | cresl1n | expected_prior |
| 15:41.24 | tsearle | ok, so then it can be exposed by a simple patch |
| 15:41.53 | cresl1n | I'd test and verify that it shows what you need though |
| 15:42.01 | cresl1n | like you said, the math's a bugger in that file |
| 15:42.07 | cresl1n | :-) |
| 15:59.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 16:24.29 | danjenkins | 2ho reads documentation?! I just go to code samples :D |
| 16:24.50 | danjenkins | was reading back the tsearle & creslin & file convo |
| 16:29.40 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 17:02.44 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.17.177) |
| 17:14.34 | file | rmudgett: you may be correct in regards to AST_FLAG_BLOCKING |
| 17:15.29 | file | there is thread overlap specifically with that in the bridge leave process |
| 17:19.24 | rmudgett | It is a more general problem because the flags should not be set without having the channel lock first. |
| 17:20.00 | file | I'm specifically targeting just this unit test for now |
| 17:20.07 | rmudgett | That just happens to be the instance causing this problem. |
| 17:34.03 | seanbright | so i've been doing some debugging and i'm not sure if this is an asterisk problem or a sip client problem (experienced it on both bria 4 & pjsua sample UAC) |
| 17:35.10 | seanbright | if you pass the 'p' (play tone) option to Bridge(foo), it will play a tone on foo |
| 17:35.48 | seanbright | but at least 50% of the time, the tone sounds like garbage |
| 17:35.56 | seanbright | and sometimes you don't hear it at all |
| 17:36.01 | *** join/#asterisk-dev tuxd00d (~tuxd00d@98.180.132.25) |
| 17:36.51 | seanbright | it looks like the briding framework is generating RTP packets with a different SSRC than the original channel audio |
| 17:36.58 | seanbright | which makes sense |
| 17:37.39 | seanbright | and if i listen to the RTP through wireshark it sounds fine |
| 17:37.52 | seanbright | but via the phone in realtime it sounds choppy as hell |
| 17:42.34 | file | hum |
| 17:42.58 | file | did we set the marker bit on the media? is the stream going out at a constant rate? |
| 17:44.23 | seanbright | yes on your first question |
| 17:45.01 | seanbright | there are two marks |
| 17:45.13 | seanbright | while the tone is playing, i am still getting frames from the original SSRC |
| 17:46.09 | seanbright | so while the tone is playing, i am getting packets for both SSRCs and the frames for each are ariving ~20ms after the previous ones |
| 17:46.26 | file | you shouldn't be receiving two streams |
| 17:46.27 | seanbright | then i get another marked packet |
| 17:46.32 | file | wonders where this app is |
| 17:46.47 | seanbright | then just the SSRC for the bridge stream |
| 17:46.54 | seanbright | would the capture be helpful to you? |
| 17:47.15 | file | capture? no |
| 17:47.18 | seanbright | k |
| 17:47.48 | file | ah features |
| 17:49.48 | seanbright | yeah, sorry, i could have told you that sooner, sorry |
| 17:49.54 | seanbright | two times the sorry |
| 17:50.37 | file | you shouldn't be getting packets for both SSRCs at the same time |
| 17:50.42 | file | that will make stuff sad |
| 17:50.43 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@196.52.18.55) |
| 17:50.52 | file | it'd be a bug |
| 17:51.00 | seanbright | alrighty |
| 17:51.06 | seanbright | will creating one |
| 17:52.42 | seanbright | well... i will spend 10 minutes trying to figure out how to fix it myself |
| 17:52.47 | seanbright | then report an issue |
| 17:53.57 | file | I could never find the right way to tell you, your issue reports are the best |
| 17:53.59 | file | grooves |
| 17:54.14 | file | and it's a long way far in JIRA now... so trust in me, I'll triage it asap |
| 17:54.26 | seanbright | alrighty |
| 17:56.14 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-188-173-39.ph.ph.cox.net) |
| 18:06.04 | seanbright | ASTERISK-26781 |
| 18:06.43 | file | couldn't attach a debug log too? :P |
| 18:06.57 | seanbright | hmmm |
| 18:06.59 | seanbright | i can |
| 18:07.05 | seanbright | give me a few minutes |
| 18:18.16 | file | I think it's because native bridging isn't broken |
| 18:19.51 | file | JIRA has decided that it wants to default me to the "All" view for issues instead of Comments |
| 18:20.14 | seanbright | file: should the native bridging be broken? |
| 18:20.17 | seanbright | my assumption is yes |
| 18:20.19 | file | yes |
| 18:23.39 | file | hum - thoughts on https://issues.asterisk.org/jira/browse/ASTERISK-26779 ? |
| 18:53.29 | seanbright | file: i have no thoughts |
| 18:53.38 | file | I have no cookies |
| 18:53.52 | seanbright | getting/setting headers should work transparently across compact and not |
| 18:53.57 | seanbright | is that a thought? |
| 18:54.01 | file | yes |
| 19:38.34 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 19:43.27 | seanbright | stares blankly at the bridging code |
| 19:44.00 | file | gives seanbright some vodka |
| 19:44.05 | seanbright | wonders if 'blankly' is a word |
| 19:44.26 | file | I think so |
| 19:46.21 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 19:49.43 | Demon_VoIP | PJproject is installed not bundled. Where are a lot of debug messages from sip_endpoint.c and some others in syslog. How can i disable it? What compile option? |
| 19:50.56 | seanbright | Demon_VoIP: https://raw.githubusercontent.com/asterisk/asterisk/master/third-party/pjproject/patches/config_site.h |
| 19:51.41 | Demon_VoIP | #define NDEBUG 1 ? |
| 19:51.45 | seanbright | one of them |
| 19:52.03 | Demon_VoIP | PJ_LOG_MAX_LEVEL ? |
| 19:52.05 | seanbright | i don't know |
| 19:52.19 | seanbright | those are the options the bundled pjproject use |
| 19:52.40 | Demon_VoIP | i know. Ok. i'll try some of them. Thank you. |
| 19:53.00 | seanbright | try all of them. just go crazy |
| 19:54.36 | Demon_VoIP | i use some old version with ast 13.7. Any new version crashed after 5-10 mins of work. 13.7 with pjproject-2.4.5 works 5-7 hours before crash :) |
| 19:55.08 | Demon_VoIP | i am not ready to change all of defines :) |
| 19:55.27 | seanbright | #define PJ_CRASHINESS 0 |
| 19:55.30 | seanbright | that is what i use |
| 19:55.47 | seanbright | it's set to rand() by default |
| 19:56.47 | Demon_VoIP | i guess it's joke. |
| 19:57.47 | seanbright | yes |
| 20:22.11 | Demon_VoIP | gtjoseph, why default PJ_LOG_MAX_LEVEL is 6? I think... it is too "big". |
| 20:23.09 | gtjoseph | if it's set lower at compile time, then you can't raise it from inside asterisk |
| 20:23.24 | gtjoseph | you can only raise it by compiling again |
| 20:24.01 | Demon_VoIP | ok. why my syslog is spammed by pjsip? What is raised level? |
| 20:24.02 | gtjoseph | when it's set to 6, asterisk can filter discard the messages if you configure the logging levels in pjproject.conf |
| 20:24.29 | gtjoseph | look in pjproject.conf |
| 20:24.49 | Demon_VoIP | hmm. pjproject not bundled now. guess that is the reason. |
| 20:25.01 | gtjoseph | doesn't matter whether you use bundled or not |
| 20:25.12 | gtjoseph | pjproject.conf still applies |
| 20:26.00 | Demon_VoIP | pjproject.conf exists, but does't have any settings. Why spammed? |
| 20:28.55 | gtjoseph | iirc the default is "everything". hopld on i'll get you a sample |
| 20:29.30 | gtjoseph | ; Common pjproject options |
| 20:29.30 | gtjoseph | ; |
| 20:29.30 | gtjoseph | ;========================LOG_MAPPINGS SECTION OPTIONS=============================== |
| 20:29.30 | gtjoseph | [log_mappings] ; NOTE: The id of this object MUST be log_mappings. |
| 20:29.31 | gtjoseph | type = log_mappings |
| 20:29.32 | gtjoseph | asterisk_error = 0,1 |
| 20:29.33 | gtjoseph | asterisk_warning = 2 |
| 20:29.35 | gtjoseph | ;asterisk_notice = |
| 20:29.37 | gtjoseph | ;asterisk_verbose = |
| 20:29.39 | gtjoseph | ;asterisk_debug = 3,4,5,6 |
| 20:29.52 | gtjoseph | this will only print logs levels 0 and 1 as error and 2 as warning |
| 20:30.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0071182e29f690bbd0.ipv6.abo.wanadoo.fr) |
| 20:30.17 | Demon_VoIP | after that "pjsip reload" helps or restart? |
| 20:30.34 | gtjoseph | i forget. restart to be safe |
| 20:32.52 | Demon_VoIP | it did not help :( i'll recompile pjproject with level 0. |
| 20:33.31 | gtjoseph | are the messages actually coming from asterisk? |
| 20:34.10 | Demon_VoIP | from pjproject. like this: |
| 20:34.11 | Demon_VoIP | Feb 9 23:34:02 talk37 asterisk[31744]: 23:34:02.250 atm0x2f54d68 .Mutex released by thread Asterisk Thread |
| 20:34.11 | Demon_VoIP | Feb 9 23:34:02 talk37 asterisk[31744]: 23:34:02.250 atm0x2f54d68 .Mutex: thread Asterisk Thread is waiting |
| 20:34.26 | gtjoseph | you can use "pjproject show log mappings" and "pjproject show log level" |
| 20:35.32 | gtjoseph | odd. that doesn't look right |
| 20:35.43 | Demon_VoIP | asterisk 13.7. There is no module pjproject. You make it in... 13.8? |
| 20:35.52 | gtjoseph | well, that explains it |
| 20:39.31 | Demon_VoIP | thanks for bugfix with OPTIONS. But it doesn't help me. I tried 13.14.0-rc1 with bundled pjprojects. It works about 5-10 mins and crash. I collect several .crash files before rollback to 13.7 |
| 20:45.05 | gtjoseph | there are more pjproject crash fixes in the works but they won't make it into 13.14.0 |
| 20:45.45 | rmudgett | With v13.7 you want PJ_MAX_LOG_LEVEL at no more than 3. |
| 20:47.23 | Demon_VoIP | gtjoseph, what is the target release? |
| 20:47.49 | gtjoseph | not sure. they're still in progress |
| 20:47.59 | Demon_VoIP | rmudgett, thanks. A define level 0. It helps |
| 20:48.54 | Demon_VoIP | now only asterisk spams to syslog in case of no any line "syslog" in logger.conf :) |
| 20:57.40 | Demon_VoIP | gtjoseph, are there issue numbers to watch bugfixes? |
| 20:58.00 | gtjoseph | give me a sec |
| 20:59.39 | gtjoseph | ASTERISK-26675 ASTERISK-26669 ASTERISK-26738 are a few |
| 20:59.46 | Demon_VoIP | Thank you! |
| 21:06.22 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-yvpryhkwxrttdzxv) |
| 21:06.22 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:09.19 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rbhtkcomcubvpbfr) |
| 21:09.19 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:10.20 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ciyplndphekzhrsp) |
| 21:10.20 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:20.05 | seanbright | file: so this may or may not be interesting |
| 21:20.35 | seanbright | i enabled the FRAME_TRACE function on my channel and filtered on control frames |
| 21:21.24 | seanbright | and there is an ast_assert in there if AST_CONTROL_MASQUERADE_NOTIFY is encountered with a comment that says "Should never happen" |
| 21:21.30 | seanbright | well i triggered the assert |
| 21:21.46 | file | :D |
| 21:22.25 | seanbright | is that issue-worthy? |
| 21:22.36 | seanbright | do you think it's related to my other issue somehow? |
| 21:22.51 | file | I don't think it's related |
| 21:22.54 | seanbright | k |
| 21:24.46 | seanbright | looks to be related to yanking a channel. teehee. |
| 21:25.15 | rmudgett | Ok, now pull the other one :D |
| 22:05.59 | *** join/#asterisk-dev NirS (~Nir_S@12.206.107.11) |
| 22:06.13 | NirS | hey all |
| 22:06.22 | NirS | any of the Asterisk developers at ITexpo ? |
| 22:23.28 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:23.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:40.42 | newtonr | NirS, I think they are all here. |
| 22:43.47 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rmqusulquqqqjrcf) |
| 22:43.47 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:46.17 | *** join/#asterisk-dev klow (~klow@66.114.139.162) |
| 23:08.48 | *** join/#asterisk-dev klow (~klow@66.114.139.162) |
| 23:44.11 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 23:44.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:46.30 | *** join/#asterisk-dev spditner (~simon@104-222-124-153.cpe.teksavvy.com) |