| 00:00.57 | snuff-work | mm did a onhook pickup just then was happy.. will get person from other office to try |
| 00:11.04 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 00:14.54 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 00:16.59 | snuff-work | seems to be ok this time |
| 00:17.53 | snuff-work | well i now have the debug threads on.. so i can get core show locks output when req |
| 00:22.45 | wedhorn | ok, guess we'll just wait |
| 00:28.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.201) |
| 00:31.32 | snuff-work | well i think my next idea is to think about fleshing out the button maskings via config |
| 00:34.53 | wedhorn | snuff-work: this I found an issue, go offhook and do a gpickup when no call to pickup |
| 00:36.19 | snuff-work | ah there |
| 00:36.25 | snuff-work | explains it |
| 00:36.41 | wedhorn | guessing the call ended before the pickup ran |
| 00:36.45 | snuff-work | i fixed up my 'callgroup' |
| 00:36.56 | snuff-work | pastebin of locks incoming.. if u want |
| 00:37.27 | snuff-work | http://pastebin.com/0mU6M8CF |
| 00:37.52 | snuff-work | only bad thing is.. now i need to restart * |
| 00:46.52 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 00:49.50 | *** join/#asterisk-dev vtone_ (~vtone@87.82.223.195) |
| 01:12.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-23-159-253.kc.res.rr.com) |
| 01:27.16 | wedhorn | snuff-work: try the patch on https://issues.asterisk.org/jira/browse/ASTERISK-23249 for your deadlock |
| 01:28.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.248) |
| 01:31.16 | snuff-work | k will do soon |
| 01:36.22 | snuff-work | k seems to be happy now |
| 01:45.07 | wedhorn | have you tried picking up a sip call? |
| 01:46.00 | snuff-work | i can do.. the crash was repo by just having no ringing calls in a callgroup and trying to pickup tho |
| 01:47.19 | wedhorn | yeah, I made some additional changes |
| 01:50.45 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 01:52.36 | snuff-work | k i try in a sec.. |
| 01:53.24 | snuff-work | was able to do gpickup of a sip call ok |
| 02:00.56 | wedhorn | okay, cool. Will commit it |
| 02:18.31 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 02:28.34 | *** join/#asterisk-dev Devon_ (~Devon_@adsl-65-8-195-200.mia.bellsouth.net) |
| 02:28.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.234) |
| 02:32.49 | snuff-work | ok.. with transfers.. if A calls B.. / B transfers to C (without waiting for C to pickup) = C only sees B not A's details who they are talking to |
| 02:34.45 | pabelanger | Is that a question or statement? |
| 02:35.10 | WIMPy | And up to which version is it true? |
| 02:35.16 | snuff-work | its ONLY skinny |
| 02:35.19 | snuff-work | don't worry =) |
| 02:35.27 | pabelanger | oh, not sure then |
| 02:35.42 | pabelanger | I would imagine you see A on a blind transfer |
| 02:36.03 | snuff-work | something me and wedhorn will figure out |
| 02:36.14 | snuff-work | u should see A yes.. |
| 02:36.49 | snuff-work | you do see A if u pickup B's call on C.. then B finishes xfer.. A's details show on C |
| 02:37.12 | snuff-work | minor details |
| 02:42.38 | WIMPy | Hmm. I thought I had seen chan_sip do that. But it doesn't. Was that new in 12? |
| 02:46.38 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 02:49.16 | snuff-work | still have issue though with SVN.. i cannot start via init script |
| 02:50.01 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 02:50.50 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:16.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.238) |
| 03:28.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.238) |
| 03:48.34 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 03:49.09 | wedhorn | snuff-work: that A B C thingy looks wrong, but does that mean that if the xfer occurs after C answers, all the details are correct? |
| 04:06.26 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 04:06.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:48.45 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 05:18.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 05:25.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 05:48.44 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 05:59.59 | wedhorn | snuff-work: had a look at the transfer stuff, normal and blind transfers seem fine. Blonde doesn't update details, but their does appear to be any indication provided by the new bridging |
| 06:08.45 | snuff-work | you mean doesn't |
| 06:08.48 | snuff-work | ? |
| 06:14.00 | snuff-work | also.. i dont seem to be able to transfer a ringing call to another phone blind.. odd request i know ;) |
| 06:28.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.56) |
| 06:28.54 | wedhorn | snuff-work: yep, doesn't appear to be any indication provided by the blonde transfer stuff in core |
| 06:30.40 | wedhorn | snuff-work: never tried transferring a ringing call |
| 06:30.51 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 06:30.52 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 06:31.44 | wedhorn | actually, quite surprised the whole thing doesn't fall in a heap |
| 06:33.08 | snuff-work | heh |
| 06:33.16 | snuff-work | it just tells me no which is nice |
| 06:33.54 | snuff-work | i like that rather fail to work than segfault |
| 06:33.58 | wedhorn | yeah, core transfer is rejecting the transfer |
| 06:34.24 | wedhorn | Technically, I've a feeling it's a forward rather than a transfer |
| 06:34.37 | snuff-work | pretty much is a fwd.. |
| 06:35.25 | wedhorn | yeah, happy if we code it to be a forced transfer, ie, forward as soon as we get a dialplan match? |
| 06:35.43 | wedhorn | sorry, should read "forced forward" |
| 06:41.30 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 06:41.30 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:43.17 | snuff-work | sounds ok to me |
| 06:43.56 | snuff-work | pretty much what it is.. forwarding without answer |
| 06:48.06 | snuff-work | for the ringing to ringing right |
| 06:49.12 | snuff-work | to solve the A->B (answers) B->C(xfer while still ringing) is a diff fix right? |
| 06:53.34 | snuff-work | also i think skinny still has a real preference for ulaw no matter skinny.conf settings |
| 07:08.08 | wedhorn | snuff-work: you lost me on the A->B thing |
| 07:08.26 | snuff-work | mm 2nd thing is that 'blonde' transfer |
| 07:08.57 | wedhorn | yeah, I think, too many issues at once ... |
| 07:09.21 | wedhorn | codecs, I think we rely on whatever core does, but not sure |
| 07:09.48 | snuff-work | pretty sure i remember some specific code in skinny that shoves the ulaw back in.. but its fine atm |
| 07:10.39 | wedhorn | possibly, and if so, that's probably a bug |
| 07:12.17 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 07:12.52 | wedhorn | anyone know whether it's an oversight or deliberate that blonde transfer doesn't provide a connected line update? |
| 07:13.57 | snuff-work | going to 'break stuff' in my env in next 2 days.. going to try n use pjsip instead of chan_sip |
| 07:14.34 | wedhorn | cool, so if you have any issues I'll just blame it on pjsip ... |
| 07:15.54 | snuff-work | mm.. might try commenting out the ULAW in 'default cap' 8691.. see if it truly gives up on ulaw |
| 07:33.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:34.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:52.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 08:24.16 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:24.50 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 08:25.04 | skrusty | morning |
| 08:25.33 | wdoekes | good morning |
| 08:33.39 | *** join/#asterisk-dev vtone (~vtone@87.82.223.195) |
| 08:35.32 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:35.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:56.10 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:59b9:89d7:2e9e:660e) |
| 09:05.14 | *** join/#asterisk-dev vtone (~vtone@80.169.55.98) |
| 09:25.46 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:43.01 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:56.43 | skrusty | is there a reason why RecordingFinished doesn't include the channel that recording was done on? Is it because it could be a channel or a bridge? |
| 10:39.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 11:00.24 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 11:00.25 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 11:16.17 | *** join/#asterisk-dev vtone (~vtone@80.169.55.98) |
| 11:17.56 | skrusty | or is it an oversight, as playback has the target_uri (chan or bridge) |
| 12:14.16 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 12:14.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:19.34 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:19.34 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:23.34 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:23.34 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:30.02 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:30.02 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:30.50 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:30.50 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 13:02.59 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 13:02.59 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 13:13.08 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:39.26 | skrusty | afternoon |
| 13:40.36 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 13:51.04 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:51.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:05.35 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:07.37 | *** join/#asterisk-dev AsteriskUser (~AsteriskU@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 14:09.24 | AsteriskUser | Hi All, I have a strange issue with audio which has just started reciently in asterisk 1.8.23.1 with early audio not being forwarded by asterisk. When the call is answered audio passes correctly. |
| 14:09.27 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-psmtbajxvxppgrtw) |
| 14:09.27 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:10.13 | AsteriskUser | Audio is passing from the provider which I can see in the wiresharks |
| 14:10.36 | AsteriskUser | Am i in the correct room to discuss this? |
| 14:11.33 | skrusty | maybe better asking in #asterisk |
| 14:46.13 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:49.16 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:50.36 | oej | afternoon folks |
| 14:50.49 | skrusty | afternoon |
| 14:51.11 | skrusty | just finsihed my first (rough version) of a conf written in ari! |
| 14:51.16 | skrusty | https://asternetari.codeplex.com/SourceControl/latest#AsterNET.ARI.SimpleConfExample/Program.cs |
| 14:58.56 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 15:02.48 | oej | congrats |
| 15:03.58 | leifmadsen | .NET?! |
| 15:03.59 | leifmadsen | :D |
| 15:04.18 | leifmadsen | well, C# I guess |
| 15:07.48 | russellb | C#? i'm sorry |
| 15:07.52 | russellb | trololo |
| 15:08.45 | skrusty | yeah c# :) |
| 15:09.01 | skrusty | in fact, i should see if it runs on mono! |
| 15:09.16 | leifmadsen | if you did it in java my company would be all over it |
| 15:09.25 | leifmadsen | not that I encourage that type of behaviour |
| 15:09.41 | skrusty | i hate java, i think the reason being my tutor at uni was a java nazi |
| 15:09.46 | skrusty | (for want of a better phrase :) |
| 15:11.28 | skrusty | so, who wants to add speaker detection to ari for me?! :D |
| 15:13.51 | skrusty | __tumbleweed__ :/ |
| 15:18.42 | seanbright | define speaker detection |
| 15:18.51 | seanbright | voice activity detection? a la app_amd? |
| 15:19.24 | file | that is something I would want discussion on asterisk-app-dev for... what it looks like from an API perspective, how stuff is reported, options, etc |
| 15:19.49 | seanbright | then i retract my follow up questions |
| 15:19.56 | skrusty | :) |
| 15:20.11 | skrusty | well, can i kickstart that discussion? :) |
| 15:20.19 | file | seanbright, app_amd adds some additional logic |
| 15:20.33 | seanbright | skrusty: http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev |
| 15:20.35 | file | skrusty, you sure can |
| 15:20.46 | skrusty | seanbright: thanks, already a member |
| 15:20.50 | seanbright | well then there you go |
| 15:20.56 | seanbright | glad i could help |
| 15:20.59 | skrusty | :D |
| 15:21.10 | seanbright | file: yeah, i had the pleasure of porting it to freeswitch |
| 15:21.25 | file | seanbright, you're dead to me (j/k) |
| 15:21.32 | seanbright | err, another telephony platform |
| 15:21.53 | skrusty | lol |
| 15:22.00 | file | app_amd is not something I would envision being ported |
| 15:22.12 | seanbright | how do you mean? |
| 15:22.25 | seanbright | to ARI? |
| 15:22.32 | leifmadsen | I would picture something more like noise detection |
| 15:22.35 | file | no, to another platform |
| 15:22.36 | leifmadsen | like AMI has now |
| 15:22.43 | seanbright | file: why's that? |
| 15:22.56 | file | seanbright, surely there has to be better options... |
| 15:23.00 | seanbright | file: there are not |
| 15:23.30 | seanbright | they have two modules for answering machine detection that both listen for a beep |
| 15:23.34 | seanbright | which is all but useless |
| 15:23.59 | seanbright | they allegedly have a commercial module for VAD, but i didn't have any luck getting a response from their commercial email alias |
| 15:24.25 | file | ah |
| 15:25.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:25.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:25.06 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-tzeiqyvtkxhjroub) |
| 15:25.22 | seanbright | all of the pieces are there (really just silence/'voiced' detection), so it was just a matter of plugging in the logic |
| 15:25.31 | seanbright | app_amd isn't perfect, but it's good enough for me |
| 15:25.42 | file | nods |
| 15:26.10 | file | whoops |
| 15:26.13 | skrusty | :) |
| 15:26.20 | skrusty | well, it works on mono too, so that's good |
| 15:26.33 | seanbright | anyway, VAD is hard |
| 15:26.47 | skrusty | noise detection is suppose is what i meant |
| 15:26.53 | skrusty | (doesn't have to be voice) |
| 15:26.59 | seanbright | well, right |
| 15:27.12 | skrusty | a simple way of doing speaker detection, i.e. noise over x |
| 15:27.14 | seanbright | defining "noise" is hard |
| 15:27.22 | seanbright | but you can get close enough for most uses |
| 15:27.27 | seanbright | right |
| 15:27.31 | seanbright | noise over a threshold |
| 15:28.01 | skrusty | yeah |
| 15:28.45 | skrusty | how does ConfBridge do it for ConfbridgeTalkingEvent ? |
| 15:29.19 | seanbright | the same way app_amd does i'd assume |
| 15:29.27 | seanbright | ast_dsp_new |
| 15:31.04 | opticron | file, on the subject of sorcery observers, how would you go about pushing existing sorcery information through a newly added observer or does that happen automatically as a bunch of create callbacks upon addition? |
| 15:32.55 | skrusty | Also, quick question. Why does Playback not have a reference to the channel or bridge it's being played on? |
| 15:33.10 | skrusty | erm |
| 15:33.14 | skrusty | sorry |
| 15:33.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.120.122) |
| 15:33.30 | skrusty | LiveRecording even |
| 15:34.26 | skrusty | RecordingFinished event gives no indication of what bridge or channel the recording was being made/failed on, that i can see |
| 15:34.50 | *** join/#asterisk-dev roramirez (~rodrigo@pc-34-179-160-190.cm.vtr.net) |
| 15:35.45 | file | opticron, the observer has to request it |
| 15:36.01 | file | opticron, ie: if it wants to know what already exists it has to retrieve all |
| 15:36.06 | opticron | ok |
| 15:36.15 | opticron | thanks |
| 15:36.21 | opticron | does some more digging |
| 15:43.31 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 15:43.38 | file | skrusty, I don't know... what would it be useful for? |
| 15:44.43 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.56) |
| 15:45.31 | skrusty | well, it might be handy to know (as it was for me) what channel the recording had finished on! |
| 15:45.46 | skrusty | as i want to, on finsihing the recording, play it back on that channel |
| 15:46.11 | skrusty | you have a target_uri (bridge or channel) on the playback finished event |
| 15:46.19 | skrusty | but not on recording |
| 15:46.25 | skrusty | just seems inconsistant |
| 15:47.37 | file | you should make a list of inconsistencies |
| 15:48.01 | skrusty | can do, im only finding them because i am using ARI :) |
| 15:53.32 | skrusty | i'll put a list together and post on dev list, is that OK? |
| 15:54.24 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-rvztklxtrwsoccsh) |
| 15:54.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:54.26 | file | sure is |
| 15:54.45 | skrusty | one last question, should two sounds be played on a channel at once, or one after another? I.e. if i call Play(x) and then Play(y), would you expect both to be played overlayed, y stop x and play, or queue? |
| 15:54.56 | file | queue |
| 15:55.02 | skrusty | they dont currnetly |
| 15:55.05 | skrusty | currently |
| 15:55.07 | skrusty | they overlay |
| 15:55.26 | skrusty | i'll add that to my list |
| 15:55.28 | file | that's.... odd... |
| 15:55.41 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:56.11 | file | sure it's not on a bridge? |
| 15:56.12 | skrusty | it happens in my conf sample, when entering or leaving the bridge, the play command to the bridge plays the callers name and "has left" at the same time, i.e. over the top of one another |
| 15:56.17 | skrusty | yes, sorry |
| 15:56.21 | skrusty | it's on a bridge |
| 15:56.26 | file | oh then that already has an issue open |
| 15:56.27 | file | https://issues.asterisk.org/jira/browse/ASTERISK-22677 |
| 15:56.29 | skrusty | i said channel didn't i! |
| 15:56.33 | skrusty | soz :) |
| 15:56.35 | skrusty | ah, cool |
| 15:57.21 | skrusty | should i join that issues site? |
| 15:57.47 | file | it's where all issues are reported for Asterisk, so it's not a bad idea :D |
| 15:58.00 | skrusty | who's my JIRA admin? :) |
| 15:58.06 | skrusty | oh |
| 15:58.10 | skrusty | it's a contact form, cool |
| 16:05.12 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 16:15.53 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 16:17.05 | file | putnopvut, did you ever do anything with the taskprocessor memory leak? |
| 16:20.13 | putnopvut | file: Talking about the one that could happen on taskprocessor shutdown? |
| 16:20.15 | putnopvut | No. |
| 16:20.35 | file | putnopvut, I wonder if that could impact pjsip... |
| 16:21.41 | putnopvut | The thing is, my initial work on that may be irrelevant now since leedm777 made a bunch o' changes to taskprocessors at one point. |
| 16:23.28 | file | doesn't look like the issue you reported was fixed as a result |
| 16:28.19 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 16:28.20 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 16:47.16 | mjordan | kharwell: looks like the pjsip/subscribe/missing_aor test is still failing - https://bamboo.asterisk.org/bamboo/browse/AST-ATSEM-C632TE-2/test/case/2457816 |
| 16:47.36 | mjordan | putnopvut: and the pjsip/mwi test: https://bamboo.asterisk.org/bamboo/browse/AST-ATSEM-C664TE-2/test/case/2457818 |
| 16:48.24 | mjordan | the other tests apparently fail on the module object not having the AccountCallback attribute as well |
| 16:48.49 | skrusty | lo mjordan |
| 16:49.06 | skrusty | posted that link to the dev list |
| 16:49.13 | kharwell | mjordan: hmm, those tests shouldn't even be running as they should fail the dependency check for external_mwi |
| 16:49.14 | putnopvut | mjordan: Yeah, I just looked at the pidf/xpidf failures, and that's weird. |
| 16:49.29 | mjordan | kharwell: it should, as that is the plan that enables external MWI |
| 16:49.48 | kharwell | aaah okay I see |
| 16:51.52 | putnopvut | I'm going to see if the pidf/xpidf tests fail locally. |
| 16:52.07 | putnopvut | There could be some issue with pjsua python bindings on the test agents |
| 16:52.40 | putnopvut | Nope, having the problem locally too. I wonder if something didn't get transferred properly when the pjsua pluggable module was moved to its own file. |
| 16:54.13 | putnopvut | I wonder if there's some ambiguity since the pluggable module is called pjsua.py and the PJLIB-provided bindings are in a module called pjsua.py. |
| 16:54.36 | putnopvut | I'm going to change the name of the module in the testsuite and see if that clears things up. |
| 16:55.54 | seanbright | sruffell: i assume without debug logs, this message doesn't mean much: |
| 16:55.58 | seanbright | codec_dahdi.c: Failed to write to transcoder: Resource temporarily unavailable |
| 16:57.29 | putnopvut | Nope, that didn't help. |
| 16:57.46 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:57.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:59.08 | sruffell | seanbright: yeah…not really. From the driver side EAGAIN comes from trying to write to a channel that is not yet built….but….how that happened. |
| 17:00.09 | seanbright | alrighty |
| 17:00.10 | seanbright | thanks |
| 17:13.09 | putnopvut | mjordan: did you move the pjsua pluggable module to be in its own file? |
| 17:14.07 | putnopvut | Actually, svn blame says yes, so I'll go ahead and ask. There's a reference to a variable called PJSUA_AVAILABLE in there, and I can't find where this variable is defined/set/etc. So my tests are failing because of that. |
| 17:17.17 | mjordan | doh |
| 17:17.21 | mjordan | (sorry) |
| 17:17.24 | mjordan | just remove that. |
| 17:17.30 | putnopvut | Okay, that's easy. |
| 17:17.48 | mjordan | My initial attempt to fix the import problem was to catch the ImportError exception and set a global variable that it wasn't available |
| 17:18.09 | mjordan | that worked for the pluggable module, as it would throw an Exception when that occurred - but the class that inherited directly from an object in pj made that approach infeasible |
| 17:18.15 | mjordan | I apparently left that in... mea culpa |
| 17:18.23 | putnopvut | It's all good. |
| 17:19.26 | putnopvut | So the problem actually was that there was ambiguity because of two modules being called "pjsua". I moved our pjsua.py to a pjsua_mod.py and erased pjsua.pyc from lib/python/asterisk, and the initial problem went away. |
| 17:19.59 | mjordan | yay |
| 17:20.14 | putnopvut | pidf test is still not passing at the moment, but I'm not sure why. |
| 17:37.21 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-qkhmtlznjqaatlui) |
| 18:05.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:3e97:eff:fe14:ef66) |
| 18:33.40 | pabelanger | coreyf1513, might be easier to chat here, then reviewboard |
| 18:35.55 | *** part/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 18:36.02 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 18:36.02 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:38.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.226) |
| 18:39.31 | putnopvut | The presence_pidf test is unfortunately in a state where it is bouncing. I had it pass about 25 times on my machine and then it suddenly failed. Looking at the logs, it appears that my call to starpy's ami.setvar() method is not actually sending the SetVar AMI action to Asterisk. I see my debug message stating that we're setting the device state to RINGING but I never see that SetVar command get processed by Asterisk. |
| 18:40.00 | putnopvut | Is there any implied rule that states that starpy's AMI commands should only be issued from the reactor thread? |
| 18:41.52 | coreyf1513 | pabelanger: sure |
| 18:45.21 | pabelanger | So, for me, I'd actually like to see us freeze development on chan_sip. Simply for the fact, it forces us as a community to improve chan_pjsip. |
| 18:45.43 | pabelanger | While, it is not feature part with chan_sip.c, I believe people can live with how chan_sip works today |
| 18:45.59 | pabelanger | any functionality that is broken / lacking, should drive chan_pjsip |
| 18:46.24 | leifmadsen | I think that isn't an approach that can really happen currently |
| 18:46.40 | leifmadsen | you can't have this non-overlap of support between the channel drivers |
| 18:46.45 | mjordan | putnopvut: you're likely to run into issues if it isn't. I'm pretty sure that starpy is going to use twisted to set up a deferred callback for the action that was executed |
| 18:47.05 | leifmadsen | you put people in a situation where neither channel driver is able to fully be deployed into a production environment |
| 18:47.22 | leifmadsen | I agree new features, functionality, major overhaul etc should be discouraged heavily from chan_sip |
| 18:47.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.226) |
| 18:47.26 | mjordan | and as much as I'd like to agree with pabelanger, leifmadsen is correct. What's more, the project as a whole doesn't force people to abandon... anything. Down that path be dragons |
| 18:47.35 | putnopvut | mjordan: Okay, it's an easy adjustment to make. I didn't want to do it if it wouldn't likely help though. |
| 18:47.48 | leifmadsen | mjordan: chan_sip could of course be put into extended support |
| 18:47.56 | mjordan | at some point, yes |
| 18:48.05 | leifmadsen | I don't think that's possible for 13 at the current time |
| 18:48.08 | leifmadsen | perhaps 14 |
| 18:48.23 | mjordan | leifmadsen: we'll see. That depends on the success of 12 and the work over next couple of months |
| 18:48.39 | mjordan | keeping in mind that the issue of 'core' versus 'extended' is really a reflection of Digium's commitment to maintaining a module |
| 18:48.48 | leifmadsen | as much as I would love to see as little effort put towards chan_sip and most of it on chan_pjsip, you can't just abandon the primary channel driver because something shiny is available |
| 18:48.58 | leifmadsen | mjordan: oh I know what it means :) |
| 18:49.02 | mjordan | see, now we're conflating extended => abandoned |
| 18:49.08 | coreyf1513 | the deprecate chan_sip argument might easily sway in a year or two, after pjsip has been proven in live busy/critical production systems. |
| 18:49.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.133) |
| 18:49.24 | mjordan | the fact is, if someone wants to maintain, enhance, and improve *anything* in Asterisk, I am all for that |
| 18:49.25 | leifmadsen | I think it depends how Asterisk 13 pans out |
| 18:49.39 | file | well, there's also supporting versus progressing... |
| 18:49.43 | leifmadsen | right |
| 18:49.47 | leifmadsen | security issues, etc |
| 18:49.50 | leifmadsen | vs features |
| 18:50.08 | mjordan | I'm going to use "we" here from here on to refer to Digium, not the community :-) |
| 18:50.15 | mjordan | We always fix security issues, in any module. Period. |
| 18:50.35 | mjordan | We will continue to maintain chan_sip as a core module in whatever versions of Asterisk have it marked as a core module. We won't downgrade it in a release branch. |
| 18:50.40 | pabelanger | leifmadsen, So, chan_sip to day can be used in production, so we are not leaving people stranded. However, at the same point, active development has stopped |
| 18:50.42 | mjordan | That means bugs fixed in that version will naturally flow up. |
| 18:50.51 | pabelanger | development directed at chan_pjsip |
| 18:50.55 | sgriepentrog | In this case, the improvement is one that will make it easier to maintain chan_sip which is going to continue for a long while. |
| 18:51.03 | putnopvut | pabelanger: depends on what you mean by active development |
| 18:51.12 | putnopvut | Digium still regularly is fixing bugs |
| 18:51.27 | mjordan | as for what Digium focuses on, I think we've been pretty clear about that. chan_pjsip is the SIP stack of the future. As for when chan_sip gets moved into extended support, that's a function of whatever happens over the next year |
| 18:51.30 | skrusty | evening |
| 18:51.32 | putnopvut | And Digium won't prevent community members from putting new features in if the feature is reviewed and has tests |
| 18:51.33 | pabelanger | putnopvut, refactoring code for improbability for example |
| 18:51.54 | mjordan | pabelanger: why would I discourage anyone from improving code, even in a module that I personally dislike? |
| 18:52.02 | leifmadsen | pretty much that. |
| 18:52.03 | mjordan | I think app_alarmreceiver is silly |
| 18:52.08 | mjordan | but people still use it, and go them |
| 18:52.10 | mjordan | rock it out |
| 18:52.25 | pabelanger | my only concern is any time chan_sip is changed, even for the better, something breaks |
| 18:52.30 | mjordan | so if someone wants to add a feature, or clean something up, that's badass. Put it up for review. |
| 18:52.44 | mjordan | pabelanger: better participate in the review and testing then |
| 18:52.52 | leifmadsen | pabelanger: that's why you have a separate rebase branch |
| 18:53.23 | mjordan | and, I'll say this as well: if you make changes in chan_sip and break things, then the onus is on you fix it |
| 18:53.42 | mjordan | if a pattern emerges where someone makes a change, breaks the world for everyone else, and then they disappear, that person is not acting as a good participant of an open source project |
| 18:54.04 | mjordan | if nothing else, the burden of proof that said person's changes do not break existing deployments should be taken into account. |
| 18:55.28 | mjordan | and on that note, via file, here is Benedict Cumberbatch in a Suburu: http://i.imgur.com/8uHUAIT.jpg |
| 18:56.15 | skrusty | think i've found another issue on ARI with dtmf events stopping when multiple callers on a bridge... |
| 18:56.29 | skrusty | not 100% sure yet |
| 18:57.07 | *** part/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-yjmhlmradbxblztb) |
| 18:57.16 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-yjmhlmradbxblztb) |
| 18:57.40 | skrusty | mjordan: did you see i put that code up for the conference sample? |
| 18:58.05 | mjordan | skrusty: not yet, haven't had a chance to sit down and digest the mailing list yet. :-) Hopefully I will in a few hours |
| 18:58.13 | skrusty | no worries ;) |
| 18:58.25 | skrusty | reported a few issues i've found to the mailing list too |
| 19:02.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:02.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:05.28 | pabelanger | Fair enough, if people don't like the idea, we don't need to do it |
| 19:08.19 | coreyf1513 | so my goal with my current chan_sip review (and hopefully future ones) is to make chan_sip less of a beast / easier to maintain. I know it depends who I ask, but is this welcome or unwelcome? For the record I'm against adding any new features to chan_sip unless it's cleaned up first. |
| 19:09.52 | mjordan | coreyf1513: personally, I have no problems with that. chan_sip is resistant to change, but I'm all for the attempts. I think a good idea when doing such work is to make sure that there are some tests in the Asterisk Test Suite that cover the affected code paths, and verify that the behavior stays the same before/after the changes |
| 19:12.07 | coreyf1513 | I had no plan to change any code without test suite coverage |
| 19:12.27 | mjordan | +1 |
| 19:16.03 | wedhorn | anyone know whether it's an oversight or deliberate that completing a transfer before the recipient picks up doesn't provide a connected line update? |
| 19:21.56 | mjordan | wedhorn: not entirely sure of the answer, but blonde transfers are... tricky |
| 19:25.54 | wedhorn | mjordan: yeah, just not sure whether I should try fixing core to send the update, or modify skinny to not expect the update? |
| 19:26.22 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 19:27.12 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-rvztklxtrwsoccsh) |
| 19:46.54 | *** join/#asterisk-dev boom^time (~boom^time@75-151-20-174-Michigan.hfc.comcastbusiness.net) |
| 19:49.17 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.226) |
| 19:49.35 | boom^time | Hey guys, can anyone see any horrible consequences from changing the frame type set for a SIP 503 for the function ast_queue_control from AST_CONTROL_CONGESTION to AST_CONTROL_HANGUP. I'm doing this in chan_sip.c |
| 19:50.22 | boom^time | The change does what I need it to, but I'm worried there maybe some consequences I'm not aware of. |
| 19:51.03 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@91.206.59.135) |
| 19:52.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:52.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:54.29 | boom^time | My ITSP returns a 503 for disconnected numbers which uses AST_CONTROL_CONGESTION which ends up getting to the AMI originate response state reason as an 8. Which makes it so I can't tell the difference between and bad number and when my ITSP is congested. |
| 19:55.48 | pabelanger | Seems like the wrong approach to me |
| 19:55.59 | boom^time | pabelanger, what would you recommend? |
| 19:56.24 | pabelanger | setup a local channel in dialplan to handle it |
| 19:57.36 | pabelanger | or change ITSP |
| 19:58.06 | boom^time | pabelanger, do you know what SIP response would be appropriate that would illicit the correct AMI state reason? |
| 19:58.21 | pabelanger | not without looking at the code |
| 19:59.07 | pabelanger | THis is more a implementation issue, you should be using a local channel, then you can use Dial() to check the DIALSTATUS / CAUSE CODE and up date your numbers |
| 19:59.37 | pabelanger | but hacking chan_sip to deal with a telco 503 is wrong IMO |
| 20:00.07 | pabelanger | Many ways to work around it already |
| 20:00.26 | boom^time | But how is using a local channel going to tell my AMI application the results of the dial? |
| 20:00.37 | pabelanger | #asterisk |
| 20:00.39 | boom^time | I mean I understand that within the dialplan |
| 20:00.42 | boom^time | it would |
| 20:00.51 | pabelanger | but, you are originating a local/1234@default |
| 20:00.59 | pabelanger | then you use [default] |
| 20:01.07 | pabelanger | exten => 1234,1,Dial(blah |
| 20:02.08 | boom^time | Sure, I get that. But how is the application communicating via AMI going to hear about the results? |
| 20:02.19 | boom^time | That information is locked into the Dial plan. |
| 20:02.27 | boom^time | The app making the origination needs to know |
| 20:03.46 | pabelanger | These questions are for #asterisk, my people their can help you get to it. If you want to modify chan_sip, you are free too, but IMO it is the wrong approach to fixing your issue |
| 20:04.19 | boom^time | Okay thanks for your help |
| 20:04.30 | pabelanger | UserEvent() or you use an external process to update your application |
| 20:21.30 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:46.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.134) |
| 20:51.23 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 21:06.42 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:06.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:30.29 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-rvztklxtrwsoccsh) |
| 21:30.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:48.55 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:59.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:14.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.13) |
| 23:40.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.6) |
