| 00:07.45 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 00:14.34 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-qxfzfytanooofnnx) |
| 01:12.12 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:26.54 | *** join/#asterisk-dev serafie1 (~erin@24.96.64.240) |
| 03:24.56 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 03:24.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:59.56 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@75.76.55.191) |
| 04:00.34 | mjordan | .reference Originate |
| 04:00.40 | ColonelShorts | Originate: Originate a call. [ https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+ManagerAction_Originate ] |
| 04:00.41 | ColonelShorts | Originate: Originate a call. [ https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_Originate ] |
| 04:00.55 | mjordan | 7 seconds ColonelShorts. That's kinda slow. |
| 04:07.43 | mjordan | .reference DialBegin |
| 04:08.29 | mjordan | .reference 12 DialBegin |
| 04:08.30 | ColonelShorts | DialBegin: Raised when a dial action has started. [ https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+ManagerEvent_DialBegin ] |
| 04:39.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.164) |
| 04:54.46 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 06:14.10 | *** join/#asterisk-dev jkroon (~jkroon@kantoor.wdns.uls.co.za) |
| 06:15.26 | jkroon | ok, where to start. got a client where I'm sitting with a SIP client (connaito) that caims to have VAD for G.729 switched off, yet I'm seeing CNG frames coming from it, causing Monitor() desync. I've initiated some debugging, and I do have a bug in my VAD detection patch that can definitely contribute to this, but I don't think it's the sole cause. |
| 06:16.40 | jkroon | there seems to be issues with the seek offset into the monitor files as well, for example, if we get a CNG frame the next frame needs to seek to the right location before we can write the payload (multiple of 10 bytes) to the stream, this doesn't seem to be happening, and in certain cases where it does happen I suspect the offset is often wrong. |
| 06:17.31 | jkroon | additionally, the ast_frame->ts and len values doesn't seem to be set for the -out (write) side of the Monitor at the time of monitor write. |
| 06:18.49 | jkroon | i guess my question really is where to start with digging into this issue, I can post my patches and the output from a test run I've made, and then hopefully someone can advise where to from here? |
| 06:31.19 | WIMPy | Hi jkroon. It's been a long time! |
| 06:35.45 | jkroon | WIMPy, indeed. it means it's been busy, but mostly well :) |
| 06:35.46 | jkroon | you? |
| 06:36.33 | WIMPy | Yes, also always busy, but lately less PC related. |
| 06:39.55 | WIMPy | But also got an order for a small IVR/VM yesterday. So there's a little Linux telephony again. |
| 06:41.26 | jkroon | cool, i just need to find a way to deal with the VAD (CNG) frames in that g729 stream from connaito in a reliable way, will post my stuff in a moment, just running through my support queue quick seeing if there is anything requiring my urgent attention. |
| 07:35.28 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:42.35 | jmls | I've still got a problem with -11 and sounds installation. The sounds/ directory has Makefile and sounds.xml only. I've done a make update, ./configure , make distclean, make install |
| 07:42.56 | jmls | and it seems that no files are either downloaded or installe |
| 07:43.00 | jmls | *installed |
| 07:43.17 | jmls | anyone got any clue on why this may be happening ? |
| 07:46.22 | jmls | of course, now I fix it |
| 07:46.34 | jmls | make uninstall; make install seems to do the job |
| 08:08.23 | jkroon | odd that you need to uninstall first ... |
| 08:09.32 | jkroon | ~book |
| 08:09.32 | infobot | Asterisk: The Definitive Guide, 4th Edition (ISBN 1-4493-3242-0) available at http://oreilly.com/catalog/0636920025894 - Asterisk: The Definitive Guide is released under a Creative Commons License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/) and a version is available for reading online at http://www.asteriskdocs.org/ or see ~buybook |
| 08:25.05 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:25.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:31.10 | jkroon | Hi guys, my patches and logs as promised above: http://pastie.org/8674565 |
| 08:31.27 | jkroon | I think I solved my own issue whilst typing that up, but I'd love if someone can please just doublecheck me please. |
| 08:33.35 | jkroon | WIMPy, can I please ask you to just check that for me please? tzafrir - your input too would be much appreciated. |
| 08:34.21 | WIMPy | I have nfi about the handling of audio frames :-( |
| 08:34.52 | jkroon | WIMPy, please read, I just want to know whether what I deduced makes sense or whether I'm off my rocker completely. |
| 08:35.20 | jkroon | until last night I also had no idea about the handling. |
| 08:45.09 | WIMPy | Wow. That looks complicated. |
| 08:46.09 | WIMPy | At least the whole thing you wrote seem to fit together. But I wonder why the thing is that complex. |
| 08:47.42 | jkroon | which thing? The mechanism as a whole or just the format_g729.c code? |
| 08:47.48 | WIMPy | Oh, and the thing about 30ms frames is interesting as well. |
| 08:48.02 | WIMPy | The whole thing. |
| 08:49.11 | jkroon | if you read the channel.c code you'll get a better idea. it's actually relatively simple, the frame is destined for multiple location possibly, and the ts data etc goes through direct to the other endpoint, whereas the format_write code in a way is an "endpoint" that is actually intended to "play" the audio to a file in a way. |
| 08:50.17 | WIMPy | Yes, I can see that. |
| 08:50.18 | jkroon | if we could flag the CNG and if it was legal to deal with the CNG data we could actually on the write of the CNG data set up the parameters, and flag that the last write was a CNG update and then on the next seek actually write out the appropriate g.729 data to represent that comfort noise, but alas, patent's is problematic. |
| 08:50.47 | jkroon | I actually wondered about that "complexity" since last night, and whilst I agree it's complex I don't really see a simpler way. |
| 08:54.17 | WIMPy | wonders about that partial CNG stuff. Looks like you're having a partial frame with the rest flagged as silence. Could it also happen the other way round? I.e. reverse order? |
| 08:54.33 | jkroon | that's the question |
| 08:55.57 | jkroon | i had to make a guess and be done with it |
| 09:04.05 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7009:7cd0:1718:7f85) |
| 09:10.57 | jkroon | WIMPy, ok, so my assumption is that *normally* we will receive a voice-only frame, or a cng-only frame, the only concern is a hybrid frame, which fortunately I don't see at this client. Whatever I do, it's a guess as I don't seem to be able to get accurate information on the web |
| 09:13.15 | jkroon | either which way, the Monitor() code actually only warns regarding write failures, so in the case where I discard the 16 samples I should probably just seek forward 2 bytes and fix the seek function to deal with that. |
| 09:16.12 | WIMPy | There's nothing worse than incomplete documentation. |
| 09:18.26 | jkroon | the fact that it doesn't deal with those failures in a sane way in terms of seeking worries me, but in the *general* case any kind of failed write is a problem. |
| 09:19.15 | WIMPy | Can't argue that. |
| 09:19.58 | jkroon | so somehow just need to deal with the seek case so two options really: seek the two bytes forward + fix seek to deal with partial inner-frame seeks (and issue a should the "cur" position after a seek not be a multiple of 10), or alternatively cache the fact that I've discarded two bytes, and add that on the next SEEK_CUR or SEEK_FORCECUR |
| 09:20.24 | jkroon | but any audio stream is going to desync in asterisk in case of *any* write failure unless main/channel.c gets fixed. |
| 09:20.37 | jkroon | which is not something I'm personally even going to attempt. |
| 09:21.44 | WIMPy | I can understand that. Maybe something for a letter to Santa :-) |
| 09:35.33 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:36.02 | coreyf1513 | jkroon: I've run into Monitor desync due to network loss of RTP on one leg of the call. I have not seen the same issue with MixMonitor. |
| 09:36.29 | jkroon | coreyf1513, rtp loss shouldn't cause it any more |
| 09:37.28 | coreyf1513 | jkroon: ahh, been a while since I've used Monitor since MixMonitor solved my issue. thanks for the info |
| 09:38.02 | jkroon | my problem is licensing on g729 :( |
| 09:55.59 | skrusty | morning |
| 10:00.08 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:37.10 | *** part/#asterisk-dev vincentroy (~vincentro@vroy.ca) |
| 11:46.02 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.185) |
| 11:57.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.185) |
| 12:02.13 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@212.34.52.66) |
| 12:16.29 | jkroon | is there anybody that's able to explain the code in main/channel.c with respect to the jump offset for Monitor() ? |
| 12:18.54 | jkroon | something just doesn't seem quite right (ie, whether we seek or not depends more on the in samples vs out samples rather than based on actual timing offset) |
| 12:19.48 | jkroon | in particular, if there is a discontinuity from the previous frames timestamp + samples to this one we should seek, and this doesn't seem to be happening. |
| 12:20.05 | jkroon | coreyf1513, so you may well be right in case @ desync still |
| 12:29.56 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 13:13.57 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:13.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:17.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:20.09 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@75.76.55.191) |
| 13:22.24 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:27.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.125) |
| 13:33.41 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:52.13 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 14:19.41 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:26.24 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:37.38 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-urbcaywybdojiadu) |
| 14:39.30 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 14:40.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.142) |
| 14:55.17 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-pvaddfzfxjovdcjq) |
| 14:55.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:06.27 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:06.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:15.11 | file | I think a test I was tweaking based on feedback from putnopvut just found a bug... |
| 15:15.25 | putnopvut | ooh!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| 15:15.29 | putnopvut | what's the bug? |
| 15:16.56 | file | putnopvut, in attended_transfer_bridge this is done without holding the channel lock I think... |
| 15:16.57 | file | app = ast_strdupa(ast_channel_appl(chan2)); |
| 15:20.16 | file | if I add a sleep in my test before doing the transfer life is good, amusingly |
| 15:25.55 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gdnqixensdvlrvtf) |
| 15:27.57 | file | hrmph |
| 15:31.19 | mjordan | strange. |
| 15:31.28 | mjordan | is the channel nuked during the string dup? |
| 15:33.18 | file | unknown at this time, please deposit 25 cents |
| 15:35.38 | opticron | erm...where do I deposit the money. also, CAD or USD? |
| 15:36.01 | file | somewhere, and USD |
| 15:38.42 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-brekchvrejrsrwbp) |
| 15:38.58 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@91.206.59.143) |
| 15:39.07 | file | HAHAHAHA |
| 15:39.09 | file | it's empty |
| 15:39.25 | file | er NULL, but hahahaha |
| 15:39.36 | mjordan | the channel is NULL? |
| 15:39.46 | file | appl is NULL |
| 15:39.49 | mjordan | er |
| 15:39.57 | mjordan | that's odd. |
| 15:40.10 | file | not really, it's just highly unlikely to happen |
| 15:40.19 | mjordan | did it just not get set yet? |
| 15:40.24 | file | I've got a callback happening on the newexten which triggers the attended transfer, it's just happening so fast |
| 15:40.30 | mjordan | ah |
| 15:41.01 | mjordan | how did the newexten event fire prior to the application being set on the actual channel? |
| 15:41.40 | file | PBX core? |
| 15:47.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.125) |
| 15:47.44 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-khqlbvubxhpkvhhs) |
| 15:47.44 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:48.48 | file | yay better |
| 15:53.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-wmnmtnkdqzzvojzu) |
| 15:54.30 | pabelanger | Can we thank file for having Astricon in Las Vegas? |
| 15:54.49 | file | you can thank me for anything you want |
| 15:55.15 | GameGamer43 | pabelanger: wouldn't that depend on if we still have money when we leave? |
| 15:55.47 | Qwell | GameGamer43: Oh, we won't. |
| 15:56.24 | file | hrm... |
| 15:56.36 | file | contemplates moving his normal vacation time to after Astricon |
| 15:56.49 | mjordan | probably a good idea |
| 15:56.56 | file | Las Vegas, Seattle, Vancouver |
| 16:02.26 | danjenkins | why would it be file 's fault for las vegas pabelanger ? |
| 16:03.11 | pabelanger | Didn't say it was his fault. It's the cool astricon now |
| 16:03.21 | pabelanger | file is always a head of the curve on cool |
| 16:03.37 | danjenkins | also, my first real contribution to "asterisk" - https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+ManagerEvent_AgentCalled - the class at the bottom, it's small BUT it'll make a big difference to AMI people ;) |
| 16:04.51 | pabelanger | So, the next question, astridevcon before astricon again? |
| 16:05.29 | danjenkins | i didnt mean "fault" pabelanger , i just couldnt think of the english i was looking for |
| 16:05.39 | danjenkins | i'm happy its vegas! I've never been |
| 16:05.52 | pabelanger | get your talk ready |
| 16:07.38 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 16:08.39 | file | AstriDevCon will probably occur before then, yes. |
| 16:09.42 | danjenkins | not sure what im going to submit this year, something that doesnt require a load of code prep i think |
| 16:10.04 | skrusty | danjenkins: nice work ;) |
| 16:11.04 | danjenkins | skrusty: it looks tiny and the code really was tiny... but its the first asterisk project that has a commit in my name ;) |
| 16:11.28 | skrusty | yeah, much respect, more than i can say! :D |
| 16:11.47 | danjenkins | now mjordan , i expect to be in that list of people at the end of astricon that you always seem to put up ;) LOL |
| 16:12.05 | skrusty | i did try to submit a patch years ago (like 2004) but you had to fax some form over or something, i gave up :) |
| 16:13.20 | skrusty | pabelanger: I am going to update my agigallerywebsite this weekend to include ARI applications (and maybe review the name :D) but I wondered if i could put up payload on there. |
| 16:13.47 | danjenkins | FAX |
| 16:14.05 | pabelanger | skrusty, do what you want, open source. Just read the LICENSE (it's apache2 FWIW) |
| 16:14.17 | skrusty | oh it wont host it, but link to it |
| 16:14.29 | pabelanger | I started adding quota support the other night |
| 16:14.35 | skrusty | and be a resource for people to look at different ARIs etc |
| 16:14.39 | skrusty | nice |
| 16:14.50 | skrusty | im half way through my little confbridge :) |
| 16:19.15 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 16:26.57 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 16:34.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:3e97:eff:fe14:ef66) |
| 16:37.14 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-ayetowyumnemgcnh) |
| 16:42.13 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-jdbmglgabwanemde) |
| 16:57.45 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-rqrswhjneixrnirw) |
| 17:03.49 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 17:10.33 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:10.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:15.19 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-zdakiflymtrowzln) |
| 17:29.38 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-hvlhdtinodvnsupa) |
| 17:31.16 | danjenkins | ive just started writing a node client for it skrusty |
| 17:31.34 | danjenkins | well i say just, it does an http request to resources.json |
| 17:31.36 | danjenkins | thats it |
| 17:59.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.224) |
| 18:32.48 | sruffell | tzafrir: on http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=commit;h=03b3ce1a107c49260389, any problem changing the clock to the monotonic clock? |
| 18:33.03 | tzafrir | yes, just noticed it after the commit |
| 18:33.52 | sruffell | there is a problem? |
| 18:34.06 | tzafrir | no, Just forgot a 'git add' somewhere. Fixing now |
| 18:34.29 | sruffell | ahh..ok…. |
| 18:35.53 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 18:43.52 | tzafrir | done |
| 18:46.24 | sruffell | thanks. |
| 19:23.37 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 19:34.31 | tzafrir | sruffell, so I wonder how to avoid yet another shell script... |
| 19:41.39 | tzafrir | sruffell, also, where do you want to run udev-settele? |
| 19:43.30 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.160) |
| 20:04.33 | sruffell | I think I can make dahdi_cfg do what it should do without adding the shell script…. but I need to think about. The udev settle is because how does the /etc/init.d/dahdi init script know it's not running in parallel with the udev scripts that could be assigning the known-spans? |
| 20:15.00 | tzafrir | We tried to use dahdi_waitfor_span_assignments in an earlier variation |
| 20:42.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.201) |
| 20:46.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.201) |
| 20:54.54 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:54.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:01.11 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:04.14 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 22:17.24 | mjordan | sgriepentrog: speaking of updating some reviews, if you get r3027 updated, I'll take another look at it |
| 22:18.52 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:27.57 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:27.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:03.03 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-xkzegbqneobbozho) |
| 23:11.13 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-tdumntvyqgcvnjil) |
| 23:28.45 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:44.18 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 23:49.30 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-disvdpngwijuoxve) |