| 00:18.14 | *** join/#asterisk-dev wedhorn (~wedhorn@27-33-41-99.static.tpgi.com.au) |
| 01:14.00 | *** part/#asterisk-dev smarter (~smarter@ubuntu/member/smarter) |
| 01:21.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.116) |
| 01:47.51 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 01:47.51 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:51.34 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 02:00.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.116) |
| 02:24.25 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 02:53.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.234) |
| 03:13.12 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:23.29 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 03:23.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:32.12 | snuff-work | mm.. when i try to install chan_pjsip.. it fails during configure.. |
| 03:32.21 | snuff-work | checking for PJPROJECT... no |
| 03:32.33 | snuff-work | but all the other 'pjsip' related tests work fine |
| 03:33.59 | snuff-work | ok.. pkg-config.. needed to be installed |
| 03:35.16 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:53.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.16) |
| 04:03.39 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 04:03.39 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 04:23.00 | mjordan | snuff-work: yup, probably a lib/lib64 thing |
| 04:35.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:47.04 | snuff-work | clean vm without any prev pjsip (even though i removed all other copies).. now happy.. looks like i need to refresh my * vm |
| 04:53.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.39) |
| 05:35.20 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:37.08 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 05:39.04 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 05:53.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.231) |
| 06:06.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.231) |
| 06:35.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:38.58 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:38.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:12.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.142) |
| 07:20.33 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:27.41 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:33.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 07:34.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 08:20.29 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 08:20.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:24.13 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 08:38.13 | skrusty | morning |
| 08:38.22 | jmls | monring all |
| 08:38.27 | jmls | morning even |
| 08:39.04 | skrusty | tired already, only 8:39am :/ |
| 08:40.03 | jmls | I'm sure that there's a realtime voicemail bug in asterisk 12 with postgres . Everything works as normal (create mailbox, can access it from phone etc) but when it comes to try and change the password from the phone (0 - mailbox options, 5 - change password) I get this error on the console |
| 08:40.05 | jmls | [Feb 7 08:36:59] ERROR[3516][C-00000029]: res_config_pgsql.c:167 _pgsql_exec: PostgreSQL RealTime: Query Failed: UPDATE h42_voicemail SET context='f5f9852e-4ed9-c68d-db13-6fcf044bff42' mailbox='502' WHERE context='f5f9852e-4ed9-c68d-db13-6fcf044bff42' AND mailbox='502' |
| 08:40.05 | jmls | [Feb 7 08:36:59] ERROR[3516][C-00000029]: res_config_pgsql.c:168 _pgsql_exec: PostgreSQL RealTime: Query Failed because: ERROR: syntax error at or near "mailbox" |
| 08:40.05 | jmls | LINE 1: ...T context='f5f9852e-4ed9-c68d-db13-6fcf044bff42' mailbox='5... |
| 08:40.45 | jmls | i'm no sql guru, but I'm pretty sure that there's a missing "," between context and mailbox ... |
| 08:46.57 | wdoekes | missing a comma indeed |
| 08:52.22 | oej | Morning folks |
| 08:52.42 | wdoekes | but .. the update seems kind of redundant too.. context=x, mailbox=y where context=y and mailbox=y |
| 08:53.08 | wdoekes | which version is that, jmls |
| 08:53.11 | wdoekes | morning olle |
| 08:54.49 | wdoekes | the SET-part should have the password (from ast_update2_realtime("voicemail", "context", vmu->context, "mailbox", vmu->mailbox, SENTINEL, "password", password, SENTINEL)) |
| 09:01.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.38) |
| 09:09.34 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.204) |
| 09:16.28 | wdoekes | jmls: this should fix your comma: http://paste.ubuntu.com/6890227/ -- but it doesn't explain how the where-args got in the set-args |
| 09:16.54 | wdoekes | ah, you're using 12.. |
| 09:17.34 | wdoekes | ah.. and the code looks different there |
| 09:23.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a97c:ce5c:c7ab:2b9e) |
| 09:24.48 | wdoekes | jmls: could you try res_config_odbc? |
| 09:28.59 | wdoekes | ahyes.. I don't think what happens in ast_update2_realtime (ast12+) is legal |
| 09:29.05 | wdoekes | <PROTECTED> |
| 09:29.08 | wdoekes | <PROTECTED> |
| 09:35.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:50.46 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 09:50.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:15.23 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 10:43.16 | jmls | wdoekes: thanks |
| 10:43.40 | jmls | is this definately a bug in 12 then ? |
| 10:43.49 | jmls | should I raise a ticket ? |
| 10:44.02 | jmls | and is res_config_odbc a better choice for postgres ? |
| 10:45.07 | jmls | wdoekes: sorry, I see that there already is a code-review up there. thanls |
| 10:46.23 | wdoekes | jmls: that's one part |
| 10:46.26 | wdoekes | this is the other |
| 10:46.27 | wdoekes | http://paste.ubuntu.com/6890585/ |
| 10:47.51 | wdoekes | jmls: the point was, if res..odbc also did context=x, mailbox=x instead of password=x, then the bug was in main/config, not in res..pg |
| 10:48.32 | wdoekes | but I believe it is in main/config (see last paste) |
| 10:49.19 | wdoekes | if you could describe your libc+os+kernel+arch, I could add a mention of on which system va_arg behaves oddly |
| 10:53.06 | wdoekes | and gcc version perhaps |
| 10:54.41 | jmls | wdoekes: gcc version 4.6.3 (Debian 4.6.3-14+rpi1) |
| 11:29.42 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:33.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.143) |
| 11:35.23 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:08.23 | seanbright | morning o/ |
| 12:10.20 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 12:10.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:13.19 | file | yes, morning |
| 12:33.21 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.204) |
| 12:36.19 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@91.206.59.130) |
| 13:13.26 | coreyf1513 | how long do I wait after getting 'ship it' on reviewboard before committing? I thought there was a wiki page with guidelines for that but I can't find it. |
| 13:15.57 | wdoekes | 24 hours was agreed, iirc |
| 13:16.03 | wdoekes | so overseas had a chance to look at something too |
| 13:16.16 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:27.16 | file | 24 hours is a good number |
| 13:28.56 | mjordan | yeah... we have a lot of tribal knowledge that needs to get written down. |
| 13:29.53 | coreyf1513 | cool. so in general 1 ship it and 24 hour delay is good? how do I know if I need multiple ship it's? |
| 13:30.02 | mjordan | yup, and you never need multiples |
| 13:30.24 | mjordan | if someone has an issue with a review, they can simply e-mail the -dev list, reply to the commit, etc. |
| 13:30.43 | file | personal judgement comes into play too |
| 13:30.43 | mjordan | of course, if you want multiples, you can ask for someone else to take a look at the code |
| 13:30.47 | mjordan | yup. |
| 13:30.59 | mjordan | Caution is never a bad thing |
| 13:31.10 | mjordan | but we also have version control for a reason :-) |
| 13:35.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:36.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.204) |
| 13:37.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.129) |
| 13:43.03 | seanbright | how would i get ASTERISK-21094 over the finish line? it wasn't reported or patched by me, but it does work and should be included in 1.8 and beyon. |
| 13:43.09 | seanbright | should i put it up on reviewboard? |
| 13:49.36 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:50.09 | mjordan | seanbright: that would work |
| 13:50.33 | seanbright | alrighty |
| 13:50.50 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:53.12 | seanbright | wow... g729 patents expire in the next couple years? |
| 13:55.42 | blitzrage | we'll see :) |
| 14:08.22 | coreyf1513 | I was looking through JIRA tickets I'm involved in, was I supposed to 'Send Back' ASTERISK-23103 after I posted the patch? the patch is 'Waiting for Feedback'. |
| 14:13.00 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.204) |
| 14:16.19 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 14:49.25 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:54.30 | seanbright | what time does sruffell come around? |
| 14:58.37 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-pjdmpctemyaclbva) |
| 14:58.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:01.29 | wdoekes | coreyf1513: no, normally a message directed at JoshE would be appropriate. "Josh: can you reproduce the crash? does this patch help?" |
| 15:05.34 | wdoekes | however, your patch does not look thread safe to me. there is probably a better approach to this |
| 15:10.07 | seanbright | mjordan: file: rmeyerriecks: so an update from my testing the past few days |
| 15:10.33 | seanbright | sruffell suggested that i back out the patch from ASTERISK-19643 and test again |
| 15:11.04 | seanbright | that would be r366007 |
| 15:11.13 | file | yup yup |
| 15:11.21 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 15:11.39 | seanbright | so i backed that out, and the call between the RemoteAgent and the PSTN channels was immediately degraded |
| 15:11.44 | seanbright | even without the ChanSpy |
| 15:13.24 | seanbright | so then, on one of the BridgedCalls machines, i installed "codec_g729.so" (i think you get why i am quoting that) and noload'ed codec_dahdi.so |
| 15:13.55 | seanbright | no quality problems at all, in all of my test scenarios, including spy, whisper, or barge |
| 15:15.08 | seanbright | so either i have bad hardware (which i find unlikely considering it doesn't manifest unless a spy is happening) or codec_dahdi is the culprit |
| 15:18.40 | file | well, it's nice to have it isolated further |
| 15:19.25 | seanbright | so now what do i do? |
| 15:19.31 | seanbright | fix bugs? |
| 15:19.32 | seanbright | heh |
| 15:21.41 | file | I can not speak for codec_dahdi. ^_^ |
| 15:21.42 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:21.42 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:21.46 | file | but there's sruffell! |
| 15:21.55 | seanbright | ohai sruffell |
| 15:21.57 | sruffell | cringes |
| 15:22.05 | seanbright | hold for pastebin |
| 15:22.08 | sruffell | I *knew* seanbright was going to pipe up after file mentioned my name. |
| 15:22.24 | sruffell | btw…it's FRIDAY! (just wanted to get that out) |
| 15:22.37 | seanbright | well you have a long weekend in front of you |
| 15:22.38 | seanbright | (j/k) |
| 15:22.48 | sruffell | every joke has a seed of truth? |
| 15:22.58 | seanbright | http://pastebin.com/raw.php?i=7bdvVwM5 |
| 15:23.01 | seanbright | it's short |
| 15:23.17 | seanbright | have to run to a meeting. be back in a few. |
| 15:23.27 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:23.35 | sruffell | ugh |
| 15:26.12 | sruffell | so…now we got to figure out how chan_spy and codec_dahdi might be interacting. You know…..one thing that might be worthwhile….is change codec_dahdi to return a group of frames. It still only wants to return one frame at a time. I know that ability was added to the core as part of the chan_skype work. file, based on your understanding of the system generally…do you think that might have an impact? |
| 15:28.09 | file | it's audiohooks core so it would be an slinfactory on each direction |
| 15:28.26 | file | which will accept multiple frames being returned as a result of its translation from native codec to signed linear |
| 15:28.59 | file | hum hum hum |
| 15:29.32 | sruffell | hmm... |
| 15:30.13 | file | the audiohooks core is smart... if it's strictly spying it will only transcode once |
| 15:30.44 | coreyf1513 | wdoekes: I see what you mean. the thread safety issue actually already exists between active channels and shutdown, my patch doesn't fix it. I'm working on testing a new patch. |
| 15:31.14 | file | g729 comes in, translated to signed linear, if spies are present it gives that to spies, if no whispering or manipulation is happening then that frame is discarded and the original is passed through |
| 15:33.27 | sruffell | refreshes my understanding of codec_dahdi. |
| 15:33.38 | seanbright | i'm IRCing from a meeting |
| 15:33.47 | seanbright | that is how special you guys are |
| 15:34.19 | file | if codec_dahdi were not returning in a timely fashion then that operation would be delayed and audio could go... wonky |
| 15:34.52 | file | if it were a variable delay then that would be even more wonky |
| 15:35.11 | mjordan | file: maybe try a jitter buffer in front of the channel using codec_dahdi? |
| 15:35.33 | sruffell | it'll definitely be a couple of ms to transcode the packet.. and that is variable depending on if other channels are being setup. |
| 15:36.03 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-pxnkjrgqejratjaq) |
| 15:36.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:36.40 | seanbright | sure. but doesn't codec_g729 do effectively the same thing? |
| 15:37.05 | file | mjordan, depends on what you mean by in front |
| 15:38.04 | sruffell | frameout also returns a single frame, but of variable size. So there isn't always necessarily a one to one correlation between sizes of frames in currently and sizes of frames out. It jus waits until it has at least one good frame on the outbound. |
| 15:38.36 | file | lemme ask something |
| 15:38.40 | sruffell | that is why I was thinking that perhaps using the capability to return lists of frames…and make sure there is a 1-to-1 correlation might be more like codec_g729 if that is the reference. |
| 15:38.56 | mjordan | file: agreed. Assuming the buffer was on the read side, then reading from the channel with codec_dahdi could return an interpolated frame, if the delay there was causing the issue. But that's probably not the case |
| 15:39.04 | file | quiet! |
| 15:39.17 | sruffell | pipes down |
| 15:39.32 | mjordan | I REFUSE TO BE SILENCED |
| 15:39.36 | coreyf1513 | sruffell: do you have a JIRA ticket for this quality issue? or someplace with logs and such? |
| 15:39.41 | sruffell | mjordan: aren't you married? |
| 15:39.54 | file | seanbright, k! so. yesterday I did that whole A and B talking to each other with C spying... during that was there any whispering or manipulation going on besides spying? |
| 15:39.58 | mjordan | sruffell: yes. IRC != life. |
| 15:40.03 | sruffell | lol |
| 15:40.25 | sruffell | coreyf1513, not I…I also do not think seanbright has opened one yet. |
| 15:43.31 | file | mjordan / sruffell, you two can talk again :P |
| 15:43.39 | sruffell | heh |
| 15:43.46 | coreyf1513 | sruffell: any chance a masquerade or local optimization happened to a channel with an audiohook active? |
| 15:44.19 | sruffell | coreyf1513: I'm not sure..this isn't actually my issue. I'm just the person who's sullied codec_dahdi the most. |
| 15:45.05 | sruffell | we'll need seanbright to answer those questions. |
| 15:45.41 | seanbright | file: no sir |
| 15:45.49 | file | okay so |
| 15:46.19 | seanbright | ok, let me paint the picture again, this time i'll do it more easily |
| 15:46.41 | file | the audio frames being passed between the call being spied on... are not the same as the ones returned by codec_dahdi |
| 15:46.59 | seanbright | User A (SIP - G729) -> [ Asterisk Box A ] <- User B (SIP - G729) |
| 15:47.25 | seanbright | User B's channel has: VOLUME(RX)=2, and MixMonitor (.sln) |
| 15:47.33 | seanbright | User A's channel has no hooks |
| 15:47.48 | file | ah, that's a manipulation |
| 15:48.15 | seanbright | User C (SIP - Any Codec) -> [ Asterisk Box A ] |
| 15:48.26 | seanbright | User C's channel spies on User A's channel |
| 15:48.50 | seanbright | no whisper, no barge, no DTMF to change spy modes (so there is only 1 hook created, not 3) |
| 15:49.06 | seanbright | now |
| 15:49.13 | seanbright | if User C spies on User B's channel |
| 15:49.15 | seanbright | no problems |
| 15:50.01 | seanbright | file: you're right, i'm sorry for lying initially |
| 15:50.11 | file | is the audio heard on User B degraded when User A is spied on? |
| 15:50.21 | seanbright | yes |
| 15:50.40 | seanbright | A and B are unable to understand what the other is saying |
| 15:51.04 | file | so... the frame that is given to user B is the one received from user A - it doesn't get translated back and forth |
| 15:51.51 | file | oh, except it's stupid |
| 15:52.03 | file | seanbright, any way you can temporarily do without the VOLUME? |
| 15:52.13 | seanbright | file: and the patch in ASTERISK-21094 is not to blame in your opinion? |
| 15:52.35 | seanbright | file: yes, i could. |
| 15:52.40 | seanbright | but only for testing |
| 15:53.14 | file | I don't think it is the problem |
| 15:53.24 | file | removing VOLUME would make the audio path between A and B unmodified |
| 15:53.32 | seanbright | ok |
| 15:54.18 | seanbright | i will hack something in to turn it off and then test |
| 15:54.27 | seanbright | should have an update for you in 20 minutes or so |
| 15:55.06 | sruffell | file: What are you thinking? Is there still a change that you believe might be worth exploring making to codec_dahdi? |
| 15:55.14 | file | sruffell, don't know yet |
| 15:55.19 | sruffell | kk |
| 15:55.22 | file | BUT |
| 15:55.37 | file | if the audio path between A and B is fine after this then it's the frames that codec_dahdi are returning |
| 15:55.55 | file | if it's not then it's taking wild amounts of time which is causing the jitterbuffers on each side to freak out |
| 15:56.02 | file | that's my theory |
| 15:56.17 | sruffell | can you define "wild" ? |
| 15:56.31 | file | that depends on the jitterbuffers |
| 15:56.33 | sruffell | would < 20ms cause problems? |
| 15:56.49 | file | my answer is maybe |
| 15:56.53 | sruffell | lol |
| 15:57.36 | sruffell | ok…I'll still look to see about making codec_dahdi have a one-to-one correlation between frames in and out (but that requires returning multiple frames in a single frameout call) |
| 15:58.18 | sruffell | well….hmm…that actually shouldn't matter unless there is a timeout in the wait. |
| 15:59.05 | file | sruffell, actually... |
| 15:59.33 | file | sruffell, this would cause potentially... 3 transcodes in the path |
| 15:59.54 | file | for the frame |
| 16:00.44 | file | sruffell, could that cause a cumulative effect? |
| 16:00.45 | sruffell | hmmm…that would compound the time waiting for the hardware (if I'm following ...) |
| 16:00.47 | sruffell | yeah |
| 16:01.05 | sruffell | the way it is now. |
| 16:01.54 | sruffell | Originally…it was framein to send the packets to the hardware…and frameout would return a variable sized frame of whatever was currently available…..but with that last patch…it now blocks in frameout until there is at least one frame…so that time could build up. |
| 16:02.43 | file | he backed the patch out and even without spying it went bad |
| 16:02.59 | sruffell | but it sounds like when seanbright took out that block, it was even worse in this case..so it's like this path cannot handle null frames in the translation path. |
| 16:12.05 | sruffell | coreyf1513: btw, regarding your earlier question about local chan optimization….. what were your thoughts about how that might be related to this issue? |
| 16:12.28 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:13.58 | sruffell | seanbright: do you have CNG packets from the endpoints? That could cause a 10ms block and then a null frame returned. |
| 16:14.39 | coreyf1513 | sruffell: I've seen audio quality become terrible when a local channel in ConfBridge with func_jitterbuffer enabled gets optimized. posted to ASTERISK-22409 I wanted to see if your issue was related |
| 16:17.05 | sruffell | hmm…ok. thanks. |
| 16:17.28 | sruffell | Probably not in this case since when seanbright switches to codec_g729 his issue goes away. |
| 16:17.56 | sruffell | (unless it's all timing related) |
| 16:19.23 | seanbright | so |
| 16:19.53 | seanbright | if i remove the VOLUME, i can't currently replicate the issue |
| 16:20.12 | seanbright | but it's hit or miss with the VOLUME in |
| 16:20.22 | coreyf1513 | sruffell: partly wishful thinking that my issue would be related since I've hit a dead-end on it |
| 16:20.29 | seanbright | i think because the number of channels is currently fairly low |
| 16:22.08 | seanbright | sruffell: how would i know if there is CNG? dumping the RTP? |
| 16:22.29 | sruffell | yeah…(or if the endpoints are spefically using g729.b…which Asterisk does not support) |
| 16:23.13 | seanbright | well, User A's audio is coming from another asterisk server (where it is encoded to g729 with the card) |
| 16:23.32 | seanbright | so upstream would be the only source of CNG if it was there |
| 16:23.40 | seanbright | let me do a quick dump |
| 16:24.35 | sruffell | I've seen in the past where an Asterisk server says it' doesn't support Annex B but an endpoint sends the SID/CNG frames anyway. |
| 16:26.40 | seanbright | any idea how to get the RTP port for a given call from the CLI? |
| 16:26.44 | seanbright | chan_sip |
| 16:30.11 | sruffell | I personally don't. |
| 16:30.21 | seanbright | file: any idea how to get the RTP port for a given call from the CLI? |
| 16:31.43 | file | nothing immediately springs to mind |
| 16:32.38 | seanbright | hmm |
| 16:34.36 | gtjoseph | mjordan: your 407602 commit yesterday is causing build errors (dtd validation) False needs to be false |
| 16:35.56 | mjordan | hm. That's weird. |
| 16:36.13 | mjordan | That's also very bad. |
| 16:36.29 | gtjoseph | if dev-mode is disabled, the build doesn't stop |
| 16:36.38 | mjordan | what's really odd is that xmllint doesn't catch it on Ubuntu |
| 16:36.43 | gtjoseph | so maybe that's why it didn't get caught |
| 16:36.53 | gtjoseph | oh... |
| 16:37.51 | gtjoseph | xmllint: using libxml version 20901 on Fedora |
| 16:38.14 | mjordan | I'm double checking that I didn't just screw this up royally locally as well |
| 16:38.20 | mjordan | but I'll get it committed ASAP. |
| 16:38.26 | mjordan | sighs |
| 16:38.37 | gtjoseph | :) |
| 16:38.44 | mjordan | build agents caught it, I just missed the notification :-( |
| 16:44.28 | mjordan | yeah, that's really odd. Seems to have passed just fine locally. |
| 16:44.30 | mjordan | nuts. |
| 16:45.19 | gtjoseph | with --enable-dev-mode ? |
| 16:45.35 | seanbright | sruffell: CNG is sent when one of the parties isn't speaking? |
| 16:46.23 | mjordan | gtjoseph: yup |
| 16:46.26 | sruffell | Yes |
| 16:46.26 | mjordan | makes me wonder a bit. |
| 16:46.31 | sruffell | (and the SID frames) |
| 16:46.37 | mjordan | rut roh |
| 16:46.57 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-bmkijlpyaphjxtvn) |
| 16:47.14 | seanbright | sruffell: i only see g729 RTP packets |
| 16:47.51 | seanbright | length of 74 |
| 16:49.22 | seanbright | the rtp packet is 40 bytes |
| 16:49.34 | seanbright | i can't maths the payload length |
| 16:49.34 | sruffell | ok…so then that should be ok. |
| 16:49.42 | sruffell | (20 bytes) |
| 16:49.43 | *** join/#asterisk-dev ipengineer_ (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 16:49.47 | seanbright | 20 bytes |
| 16:49.50 | seanbright | i did it! |
| 16:49.53 | seanbright | heh |
| 16:49.53 | sruffell | lol |
| 16:50.29 | seanbright | so taking out the VOLUME appears to clear it up |
| 16:50.43 | seanbright | a few tests is hardly definitive |
| 16:51.06 | seanbright | but this last call was 20 minutes+ and i didn't notice any degredation |
| 16:51.34 | sruffell | and if I followed file's theory, that means that extra translations for the frame, which means more time to move the frame through the chain…and jitter buffers are failing. |
| 16:51.49 | file | yeah |
| 16:52.22 | seanbright | we do no explicit jitter buffering |
| 16:52.24 | sruffell | so….my belief is that if codec_dahdi can take a group of frames on the inbound and outbound…we might be able to prevent blocking so much….. not sure if framein can take a list. |
| 16:52.45 | seanbright | the agent UAs do |
| 16:52.49 | seanbright | i don't know about upstream |
| 16:53.57 | sruffell | not sure if the other parts of the system will provide a list of all waiting frames when called…or if the whole chain only wants to process one frame at a time. |
| 16:54.43 | file | it generally wants a constant stream of X sized frames, usually 20ms |
| 16:56.40 | file | I think you'd have to do a buffer in codec_dahdi |
| 16:57.22 | sruffell | codec_dahdi will buffer….but it's sort of bypassed by the patch to make it act like g729. |
| 16:57.48 | sruffell | the old way was to let the kernel buffer the frames on the descriptor ring for the hardware to pick up. |
| 16:58.18 | sruffell | so that way the hardware can service them when it's available…but that led to the null frames being returned. |
| 16:58.38 | file | nods |
| 16:59.04 | sruffell | so if it take a couple of ms to transcode each frame, and I have to do so synchronously…I'm not sure how that can be sped up, unless I can someone avoid needing to block for every frame. |
| 17:04.00 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 17:04.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:11.59 | seanbright | sruffell: fixed yet? |
| 17:12.01 | seanbright | :D |
| 17:12.52 | sruffell | I'm not even sure I *can* fix this. |
| 17:13.05 | sruffell | still thinking. |
| 17:13.08 | tm1000 | who wants to look at a backtrace |
| 17:13.24 | sruffell | quickly touches nose |
| 17:13.27 | tm1000 | file: mjordan |
| 17:13.27 | tm1000 | hmmmmmmmm |
| 17:13.49 | file | *mouth full of food* sure |
| 17:13.54 | tm1000 | http://pastebin.com/UwPbjvcy |
| 17:14.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.204) |
| 17:14.30 | seanbright | sruffell: that's a scary thought |
| 17:14.35 | seanbright | considering how many of these cards i have |
| 17:14.38 | seanbright | heh |
| 17:14.58 | file | tm1000, ummm |
| 17:15.04 | file | tm1000, not really... useful |
| 17:15.16 | tm1000 | file: lol. I honeslty think the machine is just dead |
| 17:16.39 | file | set it on fire and then it really will be |
| 17:16.49 | sruffell | seanbright: I hate to ask users to open JIRA issues generally….but in this case, would you mind opening one in ASTERiSK with the facts so far? |
| 17:17.10 | sruffell | (hate to ask them to open for me I mean) |
| 17:17.19 | tm1000 | sruffell: you're so lazy |
| 17:17.22 | tm1000 | :-p |
| 17:18.00 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 17:19.01 | sruffell | yeah…(I was trying to find a post I saved on this topic…but I cannot) |
| 17:19.14 | seanbright | sruffell: i can, yes. do you expect that it is something that can be looked at sooner than later though? |
| 17:20.06 | seanbright | if it's not fixable then i need to start looking into other options |
| 17:20.59 | seanbright | (hopefully i'm not coming off as more of an asshole than usual right now...) |
| 17:21.37 | sruffell | Can I answer that question for you on Monday after I've looked things over? |
| 17:21.49 | seanbright | sure |
| 17:21.52 | sruffell | (and you're not) |
| 17:22.00 | seanbright | creating the issue now |
| 17:22.37 | seanbright | i will attach the two IRC logs that went up on pastebin.com as well for reference |
| 17:22.46 | seanbright | and i'm always here, or lurking |
| 17:27.36 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jrrmoqtphlkpvrhi) |
| 17:29.08 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 17:32.54 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:35.21 | tm1000 | file: |
| 17:35.22 | tm1000 | res_pjsip/pjsip_distributor.c: In function ‘find_dialog’: |
| 17:35.23 | tm1000 | res_pjsip/pjsip_distributor.c:141: error: ‘pjsip_transaction’ has no member named ‘mutex’ |
| 17:35.24 | tm1000 | make[1]: *** [res_pjsip/pjsip_distributor.o] Error 1 |
| 17:35.24 | tm1000 | make: *** [res] Error 2 |
| 17:35.43 | file | you likely have two pjprojects installed |
| 17:35.52 | tm1000 | file: righto |
| 17:36.35 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 17:40.10 | seanbright | sruffell: created and assigned to you (i hope that's ok) |
| 17:40.11 | seanbright | ASTERISK-23262 |
| 17:40.29 | sruffell | thanks |
| 17:42.12 | seanbright | thank you |
| 17:43.56 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 17:48.16 | tm1000 | file: nice catch btw, working fine now |
| 17:55.11 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-ystuggpadhcvnbhq) |
| 17:55.35 | rmeyerriecks | nickserv keeps de-identifying me :-( |
| 18:16.11 | pabelanger | did you register datachomper? |
| 18:16.37 | rmeyerriecks | Yep, I think it maybe a local problem, jabber is wonky as well |
| 18:20.10 | gtjoseph | mjordan: build fixed but now seeing these every 15 minutes... ERROR[799]: security_events.c:393 append_event_str_single: FRACK!, Failed assertion json_string != NULL (0) |
| 18:20.18 | gtjoseph | not sure if this is related |
| 18:20.57 | mjordan | probably. What is the security event that is causing it? |
| 18:21.37 | gtjoseph | not sure, i'd have to debug. |
| 18:21.56 | mjordan | I ran with a SIP client and an AMI connection and didn't see that. I'm not sure what security event is hitting it |
| 18:22.33 | gtjoseph | let me test a little, there's no activity on this server except registrations, qualify, etc. |
| 18:30.28 | tm1000 | file: "Use of ast_presence_state_message_type() before init/after destruction" |
| 18:30.38 | tm1000 | "user_data is NULL |
| 18:30.39 | tm1000 | Segmentation fault" |
| 18:30.51 | file | that would be ungood |
| 18:31.26 | mjordan | barf. |
| 18:32.37 | tm1000 | im trying to figure out what config is killing it |
| 18:32.37 | mjordan | tm1000: do you have the backtrace for that? |
| 18:33.13 | file | http://pastebin.com/UwPbjvcy was what he posted earlier |
| 18:33.26 | tm1000 | no let me go recompile |
| 18:33.35 | tm1000 | this was working until I loaded in the freepbx configs. |
| 18:33.38 | tm1000 | I still think its this machine |
| 18:36.12 | tm1000 | file: mjordan http://pastebin.com/sZXDbFK6 |
| 18:36.34 | mjordan | hm. |
| 18:36.35 | file | hrm |
| 18:37.18 | tm1000 | I dont even know where it's getting "PJSIP/1000" from |
| 18:37.24 | tm1000 | I removed all pjsip config files |
| 18:37.36 | file | yup, we initialize presence stuff afterwards |
| 18:37.42 | mjordan | gr. Preload. |
| 18:38.23 | mjordan | tm1000: it isn't that, unfortunately. |
| 18:38.26 | tm1000 | mjordan: do I need to reload pjsip correctly |
| 18:38.29 | mjordan | we've got to do something about the module loader. |
| 18:38.35 | mjordan | tm1000: turns out, it isn't PJSIP's fault. |
| 18:38.50 | mjordan | this is just pure Asterisk guts being wrong. And stupid. |
| 18:39.00 | tm1000 | mjordan: anything I can do? |
| 18:39.31 | Qwell | tm1000: The only known fix, is to take the rest of the day off and drink. Sorry! |
| 18:39.38 | tm1000 | lol |
| 18:39.39 | Qwell | (meet you at the bar in 5) |
| 18:39.44 | mjordan | tm1000: do you have a preload directive in your modules.conf? |
| 18:39.49 | tm1000 | unfortunately tonyclewis has 4 other boxes I could use |
| 18:39.52 | tm1000 | mjordan: yes |
| 18:40.00 | mjordan | tm1000: which module(s)? |
| 18:40.15 | tm1000 | http://pastebin.com/HhJd5Lqw |
| 18:40.27 | file | pbx_config.so. |
| 18:40.30 | mjordan | what happens if you remove pbx_config and chan_local? |
| 18:40.35 | mjordan | chan_local no longer exists... |
| 18:40.39 | mjordan | so there's that. :-D |
| 18:41.10 | tm1000 | mjordan: tonyclewis is the one who said pbx_config needs to be there |
| 18:41.29 | mjordan | he may not be wrong, but right now, let's just see if it removes the crash |
| 18:41.55 | tonyclewis | We had to preload before for a issue with queues |
| 18:42.06 | mjordan | tm1000: the short story is that Asterisk's module loader is antiquated and needs an overhaul. |
| 18:42.20 | mjordan | tonyclewis: Device state not showing up for Queues on load? |
| 18:42.44 | tonyclewis | Yes thats it |
| 18:43.39 | tm1000 | ugh |
| 18:43.45 | tm1000 | rouge asterisk process now |
| 18:43.53 | mjordan | tonyclewis: how long ago was that? |
| 18:44.25 | tonyclewis | Couple years |
| 18:44.31 | tm1000 | mjordan: ok that works |
| 18:44.34 | tm1000 | it starts fine now |
| 18:44.38 | tm1000 | and lets me register |
| 18:44.44 | mjordan | k. We might have fixed that, since pbx_config has a module load priority before app_queue now |
| 18:44.55 | mjordan | tm1000: that's a work around, the long answer is we have to go fix the module loader |
| 18:44.58 | tm1000 | mjordan: buuut in 12 only right |
| 18:45.08 | tm1000 | (btw this is 12.0.1) |
| 18:45.12 | mjordan | tm1000: if it ain't broke in 11 and below, wouldn't fix it |
| 18:45.18 | tm1000 | but it might have regressed from 12.0.0 I am not sure |
| 18:46.04 | mjordan | my guess is that you don't need to preload pbx_config/chan_local any more for the device state to work for app_queue in 1.8/11 as well, but without actually testing it I'm not sure. Both of those should load before app_queue, which means they should have the device states ready for it |
| 18:46.06 | tm1000 | mjordan: so should I file a bug for you and on that note should I file a bug for me to no longer do preloads on pbx_config |
| 18:46.10 | mjordan | yup |
| 18:46.12 | mjordan | that would work |
| 18:46.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.204) |
| 18:46.39 | mjordan | I'm writing up draft wiki pages for stuff, which won't be published for awhile, but one of them is to overhaul the module loader. I'll use that as fuel for that fire :-) |
| 18:46.53 | mjordan | but it's not a trivial effort. It's about the same as file's crazy "fix the format stuff" work |
| 18:47.33 | mjordan | 12 is nice in that it put things in separate modules (maintainability, separate of concerns, etc.) - but that means that we really overburdened an already shaky module loader in the process. |
| 18:47.44 | tm1000 | mjordan: what do you need in this bug report? |
| 18:47.56 | tm1000 | mjordan: lol nice |
| 18:48.01 | file | rewriting the universe one step at a time |
| 18:48.14 | mjordan | tm1000: the backtrace is fine, with what was in the modules.conf and what the fix was |
| 18:48.24 | mjordan | I'll comment on it |
| 18:49.00 | gtjoseph | mjordan: those assert failures are happening on Challenge and UsingPassword events. |
| 18:49.12 | mjordan | blech. |
| 18:49.18 | mjordan | well that just sucks. |
| 18:49.24 | gtjoseph | I can give you more debug info after lunch if you need it. |
| 18:49.36 | mjordan | gtjoseph: that'd be great, thanks. |
| 18:49.56 | mjordan | I'll spin something up here. Not sure how I didn't get a Challenge though when testing. Just unlucky I guess. |
| 18:49.59 | gtjoseph | no prob |
| 18:52.48 | tm1000 | mjordan: https://issues.asterisk.org/jira/browse/ASTERISK-23265 |
| 18:52.55 | mjordan | thanks |
| 18:56.06 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:59.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.204) |
| 19:03.09 | tm1000 | mjordan: I added our scrubbed IRC conversation for clarification |
| 19:05.26 | mjordan | tm1000: thanks |
| 19:58.58 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 20:00.42 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qcvgbiamfqjrrhkg) |
| 20:12.57 | gtjoseph | mjordan: pb for security event assert... http://pastebin.com/CUGamBSB |
| 20:13.12 | gtjoseph | bt and debug |
| 20:13.34 | mjordan | gtjoseph: thanks. I had totally forgotten that on my test box yesterday I was running chan_sip |
| 20:13.41 | mjordan | I'm .... ashamed. |
| 20:13.42 | mjordan | :-( |
| 20:13.55 | gtjoseph | LOL |
| 20:13.57 | mjordan | I reproduced it easily enough with PJSIP and committed a fix to 12 just now |
| 20:14.02 | mjordan | it wasn't PJSIP's fault |
| 20:14.32 | mjordan | the security_event processing had an assert that verified that the IEs in a security event have values. With optional IEs, however, that won't always be the case |
| 20:14.34 | gtjoseph | testing |
| 20:14.35 | mjordan | so, explodey |
| 20:16.15 | gtjoseph | so I just spent 30 minutes figuring out how to disable fortify_source to get you a good bt for nothing??? :) |
| 20:18.14 | mjordan | sorry :-( |
| 20:18.24 | mjordan | but I gave you props in the commit message |
| 20:18.28 | mjordan | do virtual internet points help? |
| 20:18.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:3e97:eff:fe14:ef66) |
| 20:18.47 | gtjoseph | absolutely :) |
| 20:18.56 | mjordan | gtjoseph: but seriously, thanks for catching it. That was a pretty embarrassing miss on my part |
| 20:19.41 | gtjoseph | no worries. everybody misses something. |
| 20:20.08 | gtjoseph | and i got to learn something |
| 20:21.13 | file | huh |
| 20:24.53 | file | DESTROY HASHTAB! |
| 20:25.21 | gtjoseph | hashtab = weak reference container |
| 20:26.31 | mjordan | gtjoseph: or dangingling reference container |
| 20:26.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.204) |
| 20:26.33 | mjordan | er |
| 20:26.35 | mjordan | dangling |
| 20:26.43 | mjordan | which, I suppose, is also "weak" |
| 20:26.57 | file | or performance penalty for not as often used cases |
| 20:33.19 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-irhegayaadzyeecs) |
| 20:39.31 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-pjdmpctemyaclbva) |
| 20:50.38 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-egdlkhyigjltjlfz) |
| 21:31.26 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:39.17 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-sijlkjmbflpclraw) |
| 21:58.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.232) |
| 22:02.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:24.31 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-saazgfivwasrxofk) |
| 22:57.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.124) |
| 23:08.42 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:2c1:cf01:2677:3ff:fe8f:2730) |
| 23:10.21 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:35.20 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:58.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.241) |