| 00:52.42 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:05.06 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-rlhqrdrufgkzizkh) |
| 01:59.53 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:59.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:18.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fmlwjuxpmpjmmpvb) |
| 02:18.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:07.58 | *** join/#asterisk-dev newtonr (~newtonr@64.34.219.47) |
| 03:07.58 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 03:08.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 03:08.07 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:35.37 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-kxgqwyfzikbmegop) |
| 05:53.51 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:53.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:00.52 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 07:06.20 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:06.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.17 | oej | Morning folks |
| 07:51.52 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:89b2:ba74:f0f7:e5e0) |
| 09:30.02 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:30.03 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:42.32 | oej | tzafrir: Have you cross-compiled for sheevaplug/dreamplug? |
| 09:43.40 | tzafrir | oej, I mostly use a native compiler (sometimes in a qemu-user chroot) |
| 09:43.50 | tzafrir | But that's for relatively small builds |
| 09:44.02 | tzafrir | For the kernel I did use cross-building |
| 09:46.41 | oej | Ok. I just got a dreamplug. My Sheevaplug is working as an IPv6 gateway. |
| 09:46.55 | oej | I'll try native then, I can just switch sd cards ;-) |
| 09:54.44 | tzafrir | For the sheevaplug, a qemu-user chroot was about as fast as a native build |
| 10:43.33 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 11:07.52 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:07.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:29.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jtoystxwcwrwitij) |
| 11:29.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:30.50 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:37.34 | *** join/#asterisk-dev jkroon (~jkroon@dsl-244-28-165.telkomadsl.co.za) |
| 11:38.01 | jkroon | oej, mjordan suggested I contact you regarding some RTCP work that I'm busy with. |
| 11:38.41 | jkroon | apparently I'm probably doing duplicate/redundant work, and should have a chat with you. |
| 11:38.55 | jkroon | please let me know if/when you have a few minutes |
| 11:42.00 | oej | —stand by. On the phone. |
| 11:42.36 | jkroon | no problem |
| 11:43.06 | jkroon | perhaps i should so long state what i'm seeing, and what i'm after. |
| 11:43.19 | oej | Please go ahead |
| 11:43.42 | jkroon | i don't honestly care too much about what * does with RTCP internally, i'm much more concerned with getting the sent/received RTCP reports reported properly via AMI |
| 11:43.58 | jkroon | reason being that I intend to build an external "quality" monitor. |
| 11:52.32 | jkroon | ok, so what I've cooked (got distracted sorry) so long is a set of functions that reports the standard SR and RR (each block separately) vir the AMI. |
| 11:52.53 | jkroon | i don't *think* we will ever see RC>1, but I'd rather deal with it out of hand. |
| 11:53.29 | oej | have you checked my patch? |
| 11:53.30 | jkroon | and I'm about halfway done with functions to deal with XRs (PT=207), which I am (probably in violation of some spec or another) receiving from some phones from some clients |
| 11:53.37 | oej | It reports during the call and after the call to AMI |
| 11:53.48 | jkroon | no, i was not aware of your patch until a few minutes back - do you have a link? |
| 11:53.57 | oej | Google for pinefrog |
| 11:54.14 | oej | The main work is in the 1.4 branch. Updating the 1.8 branch as well. |
| 11:54.53 | oej | http://svnview.digium.com/svn/asterisk/team/oej/pinefrog-rtcp-1.8/README.pinefrog-rtcp |
| 11:55.00 | jkroon | ok, and 11.X? |
| 11:55.15 | jkroon | would you mind if I look at that, and possibly initiate that work? |
| 11:56.09 | jkroon | does it change internal handling of RTCP at all? (I've seen what I *think* is a few errors, but I'm not sure, for example, I think I've seen some "skew" errors due to incorrect handling of the NTP timestamps, but I haven't been able to confirm) |
| 11:56.35 | jkroon | does asterisk actually *do* anything with the RTCP values being kept up to date for anything other than statistical purposes? |
| 11:57.55 | jkroon | one thing in particular I've seen is that conversion from 64-bit NTP timestamp => seconds.useconds and the 32-bit variant results in different usecond values ... which feels ... wrong. So either my math is buggered or the timeval2ntp function is incorrect. |
| 11:59.24 | jkroon | I'm glad you also don't like the combined RTCPReceived and RTCPSent reports as they are in 11.X ... |
| 11:59.45 | oej | Mjordan and I are working on 11, there's a branch for that too. |
| 11:59.58 | oej | My tests are focused on 1.8 right now, since that's what the customer requires. |
| 12:00.27 | oej | It doesn't really change handling, so I would be very happy if you check NTP timestamps and such |
| 12:01.04 | oej | It doesn't do anything with the RTCP values - send them over AMI and store in realtime. I have left it to external parties to manage sip trunks and connections. |
| 12:01.20 | oej | When we add Opus and modern codecs we should use it for internal feedback. |
| 12:01.36 | jkroon | ok, let me first get a diff for your branch currently. perhaps that already does a lot of what I need. Or do you possibly have a git repo I can clone? |
| 12:01.45 | oej | Just svn diff |
| 12:01.57 | oej | Keep me posted. I'll be happy to work on improving RTCP. |
| 12:02.10 | jkroon | is that diff available somewhere? |
| 12:02.13 | oej | I have a lot of RTP-related work - DTMF, plC and more. |
| 12:02.25 | oej | Not really, if you make it from svn you will get the latest code. |
| 12:02.31 | jkroon | have you initiated any work on XRs? which answers some of the questions in your readme. |
| 12:02.57 | oej | No. But if you look into the data I store, you will see that we have the data needed for MOS values. |
| 12:03.33 | jkroon | ok, so not being a svn fundy here ... can I ask svnview.digium.com to generate the diff or do I need to do a svn checkout? and at what URL? |
| 12:03.46 | oej | I did add support -meaning debug lines - more more RTCP types and started using SDES properly. |
| 12:04.08 | oej | http://svn.digium.com/svn/asterisk/team/oej/pinefrog-something |
| 12:04.11 | oej | for checkout |
| 12:04.23 | oej | The 11 version might be in group instead of oej |
| 12:04.48 | oej | Hints on diffs here http://www.voip-forum.com/uncategorized/2006-02/subversion-branch/ |
| 12:05.44 | jkroon | it's in oej ... svn checkout initiated. |
| 12:08.37 | jkroon | ah, it's all coming back to me now! (used svn like 7 years ago!) |
| 12:08.46 | oej | Welcome back :-) |
| 12:12.51 | jkroon | to the dark side? i forgot almost all about svn once i started using git. |
| 12:13.42 | jkroon | ok, this svn diff is not working for me: svn diff http://svn.digium.com/svn/asterisk/branches/11 http://svn.digium.com/svn/asterisk/team/oej/pinefrog-rtcp-11 |
| 12:13.46 | jkroon | bbiab |
| 12:13.57 | jkroon | need to go cut an analog PBX out of the loop |
| 12:20.17 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-jtoystxwcwrwitij) |
| 12:26.03 | oej | :-) |
| 12:39.28 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:40.10 | jkroon | ok, one more analog PBX ready for it's final resting place. |
| 12:41.52 | jkroon | ok, installing git-svn ... |
| 12:44.38 | jkroon | but it's handling of branches are not good .. given the layout for digium is using :( |
| 12:45.21 | *** join/#asterisk-dev RadJackson (~RadJackso@fktel.cust.jaguar-network.net) |
| 12:45.52 | RadJackson | Hi everyone , i'm trying to develop a .call file , which i copy to /var/spool/asterisk/outgoing/ in order to make the call happen, |
| 12:46.13 | RadJackson | I would like to know if it possible to leave a message on the voicemail directly , without making the phone ring |
| 12:46.19 | RadJackson | I appreciate your help! |
| 12:46.30 | oej | While it is kind of development it is not asterisk development. |
| 12:46.40 | oej | You have a better chance of getting help in #asterisk channel |
| 12:47.24 | RadJackson | Sometimes you guys exageerate :) asterisk or asterisk-dev, most important is to spread the word and support the community , thank you anyway. |
| 12:47.34 | RadJackson | I am sure asterisk channel are going to forward me here. |
| 12:48.27 | oej | I just said you have better chances of getting help there. |
| 12:53.24 | oej | Hmm. Wonder how hard it would be to make the DNS asynch. |
| 12:55.30 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yekggxqmljskrkdi) |
| 13:06.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:06.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:13.52 | leifmadsen | RadJackson: no, they won't, and if they did that would be wrong, since .call files are an asterisk integration thing |
| 13:14.49 | RadJackson | leifmadsen Thank you. |
| 13:34.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ksjfmurccawuhrco) |
| 13:34.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:41.27 | oej | Welcome to the world of Asterisk, Matt Jordan! |
| 13:49.48 | mjordan | more like universe :-) |
| 13:51.04 | jkroon | oej, @ dns - if you want a +1 vote on that - you've got mine. |
| 13:54.07 | oej | jkroon: I've wanted asynch dns for years. Looking at c-ares. |
| 13:55.34 | jkroon | why not just expand on dnsmgr? |
| 13:55.47 | jkroon | ie, do the callback thing and just ask dnsmgr to notify you when it gets a resolution? |
| 13:55.50 | oej | I don't like dnsmgr. But maybe I'm wrong |
| 13:56.45 | oej | digs down in dnsmgr source to find out why I did not like it. |
| 14:00.12 | oej | It doesn't really bother with DNS TTL, does it? |
| 14:00.30 | mjordan | my fear with asynchronous DNS isn't really getting asynchronous DNS to work. It's getting chan_sip to understand that when it asks for hostname resolution, it won't get an immediate response and has to defer whatever it's doing |
| 14:00.52 | oej | Right. |
| 14:01.08 | oej | But there are many cases where chan_sip has to wait, like retry after or 491 conflicts |
| 14:01.42 | oej | The main problem is when you reload SIP and SIP hangs waiting. That part should be easy to fix. We can have callbacks for peer updates. |
| 14:03.03 | oej | When you place a call, we need a full list of the SRV records and start placing calls. We can certainly wait for that. I assume it only affects one thread. |
| 14:03.25 | oej | I mean, we are waiting synchronysly today |
| 14:04.51 | oej | We need to remove the ability to hang the whole monitor thread when DNS is broken and I think that's not a big fix. |
| 14:05.08 | oej | If it's in scope for this project is another question. |
| 14:07.50 | oej | Hmm. DNSmgr with proper TTL handling might be a way forward. We should not cache beyond TTL. |
| 14:08.04 | oej | Thanks for the feedback jkrron |
| 14:08.35 | oej | Now the question is how to handle peers... |
| 14:08.50 | oej | Today we randomly select one IP from the list of srv records, which is buggy. |
| 14:08.59 | oej | Not randomly, but we select one |
| 14:09.26 | oej | So if I have peer=mydomain.tld and SRV points to five hosts and one calls that we haven't selected, we will deny the call. |
| 14:10.20 | oej | We can have an ACL list for peer matching, provided I can feed the hash table with it. |
| 14:10.41 | oej | How does gulp handle SRV? File? |
| 14:10.49 | file | pjsip handles it for us |
| 14:11.07 | oej | But if you define an endpoint like I said earlier? |
| 14:11.12 | oej | And want IP/port matching |
| 14:11.21 | file | right now the matching does a one time resolution at time of load |
| 14:11.39 | oej | DO you store the list of servers for matching? |
| 14:11.46 | file | not at this time |
| 14:11.57 | oej | So you have the same behaviour. |
| 14:19.49 | oej | Maybe something that should be redesigned |
| 14:19.51 | oej | ;-) |
| 14:20.21 | file | the module which does that for gulp is tiny, and everything is flexible enough so it can be changed at any time |
| 14:21.34 | oej | +1 |
| 14:41.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:41.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:42.14 | oej | Hmm. |
| 14:42.44 | oej | on_dns_update_peer can cause glitches. We remove the old IP from the linked list, then try a lock (which could take a while) and then add the new IP to the list. |
| 14:42.59 | oej | It should be the other way around. Add the new IP, then remove the old one. |
| 14:45.37 | oej | Do we have a limit on the hash input for hash tables in ao2? |
| 14:48.39 | oej | I think this is doable. I can add an ACL for the list of IPs and match in the hash table. One peer can have multiple entries. |
| 14:53.29 | oej | Is there anything in astobj2 that limits the number of entries for one single object? |
| 14:53.40 | *** join/#asterisk-dev jkroon (~jkroon@kerberos.uls.co.za) |
| 15:06.19 | jkroon | oej, that patch from yours is looking much more comprehensive than mine. |
| 15:06.40 | jkroon | how production ready do you think it is? |
| 15:07.16 | jkroon | I can reasonably easy plug it into our PBX in the office (and *most* of the users will probably tollerate a crash or two if I inform them beforehand) |
| 15:07.23 | oej | The 1.4 version has been in production for many years, handilng milions of calls in quite a lot of sites. |
| 15:07.36 | jkroon | 1.8 and 11? |
| 15:07.56 | oej | Not yet, the 1.8 is in testing. One known crash bug reported I will look into this week. |
| 15:07.59 | oej | With Lync. |
| 15:08.26 | jkroon | I would like to implement also giving the Channel: associated with the rtp stream (had a patch for 1.8 on my bug report, will need to redo for 11). |
| 15:08.46 | jkroon | and it probably won't apply on top of pinefrog either. |
| 15:08.56 | oej | I do that in my reports - the cqrs |
| 15:09.09 | jkroon | may I inquire what stops it from going into mainline? |
| 15:09.16 | jkroon | cqrs? |
| 15:09.26 | oej | With Matt as the leader, not much else than my work time. |
| 15:09.36 | oej | Call Quality Records stored in realtime. |
| 15:09.51 | oej | For one call you have one for the incoming call leg and one for the outbound call leg. |
| 15:10.40 | oej | The 1.8 patch was something I got funded a month or so ago and have been working on recently. I need to make sure that the 1.4 and 11 patches are up to date with the latest fixes. |
| 15:11.12 | oej | mjordan and I was supposed to have a call soemtime this week about all the RTP stuff and how to migrate it into trunk. |
| 15:11.59 | oej | So the Digium dev team seems to be backing this work nowadays, which I am very, very happy for. |
| 15:12.20 | oej | It makees the customer happy too :-) |
| 15:16.45 | jkroon | correct @ two legs. i was thinking to just have an external app collect and store the data via AMI. |
| 15:17.23 | jkroon | and then using the bridge reports to figure which channels are related to which other channels ... |
| 15:18.35 | jkroon | makes me happy too. i don't ever want to be notified by customers (300+ of them at what feels the same instant) again that there is a problem. |
| 15:20.22 | jkroon | interesting (broken?) case I've bumped into even with the old reports, one of my provider-peers includes an SDP in their 180 Ringing already and immediately commences rtp, so the first time asterisk accepts the rtp is after the OK, and then reports that we've lost all the packets prior to the OK signal ... anything we cn do about that? |
| 15:21.03 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:21.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:21.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:21.39 | oej | I wasn't aware of that. Need to run. Please send that issue to me in an -email oej@edvina.net |
| 15:21.41 | oej | Thanks. |
| 15:22.08 | jkroon | will gather some "evidence" and mail that :). thanks. |
| 15:22.23 | oej | Great to have feedback and someone to discuss this with :-) |
| 15:31.28 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 16:41.58 | Kobaz | okay sooooo |
| 16:42.17 | Kobaz | i'm adding this bit to have internally registered hangup callbacks on a channel |
| 16:42.28 | Kobaz | i'm getting some deadlocks with it... so what's the best place to put this thing |
| 16:42.55 | Kobaz | so right now i have a call to my ast_channel_run_hangup_callbacks() inside of ast_softhangup_nolock |
| 16:44.16 | mjordan | by hangup callbacks, do you mean a hangup handler? |
| 16:44.27 | Kobaz | like if i want to run some pre-hangup code after the channel has hung up, and before the channel is destroyed |
| 16:44.43 | mjordan | wouldn't that be a hangup handler? |
| 16:44.53 | Kobaz | actually that could be put in the same place |
| 16:44.54 | mjordan | that was your patch we merged into 11 :-P |
| 16:44.58 | Kobaz | yeah i know |
| 16:45.05 | Kobaz | thinking why i put this where i put it |
| 16:45.18 | Kobaz | this is 'internal' hangup handlers |
| 16:45.38 | mjordan | so you aren't running dialplan |
| 16:45.59 | Kobaz | <PROTECTED> |
| 16:46.00 | Kobaz | correct |
| 16:46.11 | mjordan | you can put it wherever you like then, but the callback should know what the state of the channel is when it's called, that is, is the channel locked or unlocked |
| 16:46.46 | Kobaz | yeah so the hangup handlers are in ast_hangup |
| 16:46.49 | mjordan | what are you doing in your callback that is causing a deadlock? |
| 16:46.51 | Kobaz | i can stick it in there |
| 16:46.59 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:47.26 | Kobaz | i gotta go through the lock list and make an abstract |
| 16:47.31 | Kobaz | hard to see with all the backtraces |
| 16:49.34 | Kobaz | mmm |
| 16:49.50 | Kobaz | okay so my deadlock is between adding a hangup callback and processing a hangup callback |
| 16:50.38 | Kobaz | and i think i stupidlyu just have this callback executor in the wrong place |
| 16:50.41 | Kobaz | that's one problem |
| 16:50.48 | Kobaz | since it can run multiple times for a single channel it looks like |
| 16:51.46 | Kobaz | === ---> Lock #1 (channel.c): MUTEX 3248 ast_channel_run_hangup_callbacks &hangup_callback_info_bhl_lock 0x82001a0 (1) |
| 16:51.47 | Kobaz | === ---> Waiting for Lock #1 (channel.c): MUTEX 3297 ast_channel_add_hangup_callback &hangup_callback_info_bhl_lock 0x82001a0 (1) |
| 16:51.56 | Kobaz | so that's bad |
| 16:52.39 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:59e1:aa5a:c9b2:1ac2) |
| 16:57.25 | Kobaz | speaking of code in 11 |
| 16:57.45 | Kobaz | who wants to be my mentor for getting group variables into 12 |
| 16:58.46 | mjordan | Kobaz: do you have a review up on reviewboard? |
| 16:59.15 | Kobaz | a really old one |
| 16:59.38 | Kobaz | i just finished porting to the new trunk |
| 16:59.52 | Kobaz | i'll have a new review in the next week or so |
| 17:00.19 | mjordan | kk - I'd say once a review is up we can see if it's just some minor stuff or if a PoC would be a good diea |
| 17:00.21 | mjordan | idea |
| 17:00.43 | Kobaz | k k |
| 17:28.56 | *** join/#asterisk-dev pce (~pce@p5791AB3B.dip0.t-ipconnect.de) |
| 17:51.19 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:51.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:26.24 | *** join/#asterisk-dev anonymouz666 (bd69c954@gateway/web/freenode/ip.189.105.201.84) |
| 19:18.04 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:18.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:23.33 | jkroon | oej, you've got mail. |
| 19:24.18 | jkroon | must say, job well done for the most part. a lot of it took me quite a while to understand, most of it looks very good and I'm not seeing any glaring errors, would love to help push that for 11 soonest possible. |
| 19:35.57 | *** join/#asterisk-dev jkroon (~jkroon@kerberos.uls.co.za) |
| 19:53.20 | mjordan | it won't go into 11. New features aren't put into release branches. It can be put into trunk however |
| 19:54.47 | jkroon | i guess. still, it's a good patch. |
| 19:56.19 | sruffell | leedm777: Can you think of any reason to not drop the old github organization? http://github.com/asterisk-org |
| 20:41.12 | Kobaz | mjordan: yeah... 12 |
| 21:03.10 | leedm777 | sruffell: re: dropping the old asterisk-org organization, no reason I can think of, except for possibly some old links to https://github.com/asterisk-org/starpy |
| 21:15.37 | sruffell | leedm777: think I should just go all bold and do it? |
| 21:15.59 | sruffell | …I'm thinking yes.... |
| 21:16.39 | leedm777 | sruffell: I'll leave that to you. A quick Google shows about 450 hits for the old URL. Not huge, but not as small as I would have thought. |
| 21:16.54 | sruffell | hmm…. |
| 22:10.54 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 22:10.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:13.54 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ksjfmurccawuhrco) |