| 00:01.55 | newtonr | jkroon: do you already have reviewboard access? |
| 00:19.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:19.14 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:22.08 | snuff-work | wedhorn: my callpickup is now causing segfaults everywhere.. talk later :) |
| 00:39.19 | *** join/#asterisk-dev rmeyerriecks (~rmeyerrie@nat/digium/x-mungutfwwedvmbid) |
| 00:39.20 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 00:39.20 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 00:39.20 | *** mode/#asterisk-dev [+o opticron] by hitchcock.freenode.net |
| 01:15.38 | leifmadsen | is it intentional that astricon.net now goes to an incredibly content light page? |
| 01:16.10 | leifmadsen | all the videos and such used to be accessible, but now are sadly hidden away from view :( |
| 01:19.15 | jsmith | leifmadsen: I could go out on a limb and hope that it was a sign that Digium was no longer using TMC to manage AstriCon... but that would be a bit dreamy even for me |
| 01:19.26 | leifmadsen | jsmith: :) |
| 01:19.38 | leifmadsen | that would be nice... although losing all the content of the website would be catastrophic I guess :\ |
| 02:13.43 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:13.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:00.38 | *** join/#asterisk-dev greenwolf (425700e4@gateway/web/freenode/ip.66.87.0.228) |
| 03:05.27 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 03:05.27 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 04:21.41 | opticron | high fives the connectedline test |
| 04:25.32 | jkroon | newtonr, no |
| 04:32.26 | opticron | was worried that the test was just bouncing again |
| 05:40.56 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 06:02.13 | wedhorn | snuff-work: back if you want to talk |
| 06:04.21 | snuff-work | yey |
| 06:04.41 | wedhorn | first up, how'd the new patch go? |
| 06:04.45 | snuff-work | so sad my pickup seems to explode it all atm.. swear it used to work |
| 06:05.32 | snuff-work | vm hasn't blown up in my most recent tests |
| 06:05.48 | wedhorn | cool, at least some forward motion |
| 06:06.00 | wedhorn | so what's the go with pickup? |
| 06:06.53 | snuff-work | 1 thing.. when you have a 'vm msg' waiting.. after a skinny reload.. seems not to re-engage red light until u make a new call |
| 06:07.40 | snuff-work | well if i have 2 skinny phones... 1 ringing.. try group pickup boom.. normally goes dead inside ast_rtp |
| 06:07.48 | snuff-work | and its called from ast_hangup |
| 06:07.58 | wedhorn | yep, I thought I saw something similar on my 7961 (older 79xx's work fine). Assume it's the order we send out packets on registration |
| 06:08.49 | snuff-work | u should be able to test pickup urself.. just add 'pickupgroup=1' for 2 phones |
| 06:09.11 | wedhorn | just did, seemed to work (minus callid stuff) |
| 06:09.21 | snuff-work | mm.. drat.. |
| 06:09.33 | wedhorn | what patches have you got? |
| 06:10.13 | snuff-work | 1 chan_sip change for redirect xfer.. |
| 06:10.46 | snuff-work | in skinny.. just ur new callinfo patch |
| 06:11.02 | wedhorn | okay, sounds about the same |
| 06:11.24 | snuff-work | will test calling from a sip phone here.. |
| 06:11.45 | snuff-work | but when i have between 3 skinny phones.. it goes boom.. going to try put a sip in mix |
| 06:12.11 | wedhorn | 3 skinny worked for me |
| 06:12.28 | wedhorn | sip calling skinny, picked up by skinny worked |
| 06:13.06 | wedhorn | skinny calling sip, picked up by skinny worked |
| 06:13.24 | wedhorn | got a backtrace? |
| 06:13.48 | snuff-work | yer |
| 06:15.18 | snuff-work | http://pastebin.ca/2329778 |
| 06:15.34 | snuff-work | reliably dies.. in the order shown most times |
| 06:17.23 | wedhorn | earlyrtp? |
| 06:18.45 | snuff-work | dont think i have that explictly enabled |
| 06:22.31 | wedhorn | had a look through my log and I don't seem to go into destroy_rtp |
| 06:22.54 | snuff-work | mm.. setting calgroup+pickup group |
| 06:23.29 | snuff-work | ok think i found issue |
| 06:24.26 | snuff-work | if we do a pickup.. but we dont have callgroup assigned.. |
| 06:24.30 | snuff-work | boom |
| 06:25.03 | snuff-work | so i had originally.. no call or pickup group.. |
| 06:25.06 | wedhorn | I've got a case of deja vu |
| 06:25.19 | snuff-work | and that made it die.. |
| 06:25.34 | snuff-work | then i had just pickupgroup... and that died |
| 06:25.47 | snuff-work | after putting both pickupgroup + callgroup = ok |
| 06:26.31 | wedhorn | so disable when both aren't set? |
| 06:28.48 | wedhorn | actually, sensibly you need a pickup group, if it's not set, no pickup |
| 06:29.12 | wedhorn | if pickup is set, but no callgroup, callgroup should default to pickupgroup |
| 06:29.39 | wedhorn | if only callgroup set, no pickup, but others can pick you up... |
| 06:34.05 | snuff-work | sounds right |
| 06:34.29 | snuff-work | will need to retest |
| 06:39.40 | *** join/#asterisk-dev schmidts (~schmidts@vie-91-186-159-076.dsl.sil.at) |
| 06:39.48 | schmidts | good FRIDAY morning TGIF! |
| 06:40.44 | wedhorn | cheers schmidts, time for another beer |
| 06:42.31 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:42.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:43.04 | oej | Morning folks |
| 06:43.36 | schmidts | wedhorn atleast one yes ;) |
| 06:45.11 | wedhorn | you betcha, on number 3 at the moment |
| 06:50.33 | wedhorn | snuff-work: https://issues.asterisk.org/jira/browse/ASTERISK-21224 |
| 06:50.51 | wedhorn | untested as allways ... |
| 06:53.10 | snuff-work | well i know this.. callgroup/callgroup set.. (but no pickup = boom) |
| 06:58.13 | wedhorn | callgroup/callgroup? |
| 07:01.16 | snuff-work | nm.. |
| 07:01.25 | snuff-work | i was just trying variations |
| 07:01.50 | wedhorn | okay |
| 07:11.06 | wedhorn | snuff-work: any luck? |
| 07:15.47 | snuff-work | mm.. guy was on a call couldn't kill it :) |
| 07:16.02 | snuff-work | btw.. any way to force a ringtone via skinny? |
| 07:16.26 | snuff-work | and is it possible to have a diff 'offhook' sound when msg is waiting |
| 07:17.14 | wedhorn | yep to the second (I think I did something along those lines a few years ago) |
| 07:17.20 | wedhorn | but was rejected |
| 07:17.39 | wedhorn | force a ringtone? for outbound |
| 07:17.41 | wedhorn | ? |
| 07:18.03 | wedhorn | where we don't get a ringing indication? |
| 07:18.27 | wedhorn | option in dial() I think |
| 07:19.57 | snuff-work | force ringtone when inbound call |
| 07:20.15 | snuff-work | aka if ppl have 3 diff tones set as their "DEFAULT".. |
| 07:20.33 | snuff-work | i want an incoming call to a DP to say.. 'use THIS TONE' |
| 07:20.47 | wedhorn | pretty sure it's doable, just haven't played around with it |
| 07:20.49 | snuff-work | then all ring harmonisly.. with 1 tone |
| 07:20.56 | snuff-work | well as usual i'm bout to run off :) |
| 07:20.59 | snuff-work | ur patch worked.. |
| 07:21.08 | wedhorn | okay, have a good weekend |
| 07:21.26 | snuff-work | might almost be worth with the pickup.. send user an updated prompt msg.. |
| 07:21.32 | snuff-work | or EVEN BETTER.. |
| 07:21.43 | wedhorn | basically, we set ringer to one of a few things, off, inside, outside and a few others |
| 07:21.46 | snuff-work | we disable that key via our 'masking' :) |
| 07:21.55 | wedhorn | just a matter of linking it up to the dialplan |
| 07:22.14 | snuff-work | k will discuss another time :) |
| 07:22.15 | wedhorn | as per my comment in the bug ;) |
| 07:22.37 | snuff-work | didn't see it.. |
| 07:22.41 | snuff-work | anyway later :) |
| 08:28.44 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 08:53.21 | *** join/#asterisk-dev paravoid (~paravoid@scrooge.tty.gr) |
| 08:54.06 | paravoid | hey there |
| 08:54.29 | paravoid | I haven't used by Jira account in ages and I'm locked out for some reason |
| 08:55.09 | paravoid | I submitted the "Can't access your account" form but I'm not getting any mail |
| 09:05.00 | schmidts | paravoid its only 4 am at the place where most of the digium guys are living so i guess you have to wait a little bit for replay |
| 09:14.38 | paravoid | I know :) |
| 09:14.40 | paravoid | I sent a mail |
| 09:18.10 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:18.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:22.11 | schmidts | is there a known problem with ulaw / alaw and oneway audio after setting a call on hold and back |
| 11:25.26 | wdoekes | there is a known problem with videosupport and on-hold |
| 11:26.02 | schmidts | wdoekes videosupport is off |
| 11:26.21 | wdoekes | in that case I know of no problems |
| 11:31.15 | schmidts | its very strange cause it looks like this happens since i have upgraded to 10.11 from 1.8 |
| 12:15.51 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:15.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:21.38 | schmidts | ok this problem doesnt exist in 1.8 only in 10 and above including trunk i can reproduce it |
| 12:29.50 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:39.56 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:54.15 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fhlgzxfgbazhqihf) |
| 13:54.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:55.10 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cwkdtrjxujgktnsa) |
| 13:56.50 | schmidts | ok my problem looks lilke it depends on the generic bridge :( |
| 13:58.41 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:58.41 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:58.56 | WIMPy | wonders if that might be related to the bridge after ConfBridge thing. What was it there? The jitterbuffer? |
| 14:02.43 | Greenlight | Yes, exactly, the jitterbuffer |
| 14:03.06 | Greenlight | Reminds me I've still to get the debug stuff for that added to the issue |
| 14:03.33 | schmidts | WIMPy its about codec missmatching or something like this here |
| 14:04.28 | oej | I want to start throwing away RTP media. Anyone that has a good IP address to send it to? Someone with packet loss that needs a few packets to fill in. |
| 14:06.42 | oej | ast_rtp_instance_send_random_packets(instance, IP, port) |
| 14:07.17 | schmidts | oej i have heard 10.10.10.10 is a good place to sent to |
| 14:07.40 | oej | Yeah, they have a lot of packet loss. |
| 14:07.47 | oej | 192.168.0.1 |
| 14:08.20 | WIMPy | 127.0.0.2 unless you use Linux |
| 14:09.06 | oej | I pinged it, and there's no packet loss there… ;-) |
| 14:12.28 | schmidts | find the difference: |
| 14:12.30 | schmidts | [Mar 8 14:50:14] DEBUG[21154]: channel.c:3611 ast_settimeout: Scheduling timer at (0 requested / 0 actual) timer ticks per second |
| 14:12.35 | schmidts | [Mar 8 14:54:13] DEBUG[22410]: channel.c:3503 ast_settimeout: Scheduling timer at (50 requested / 50 actual) timer ticks per second |
| 14:13.00 | schmidts | second one works, first one doesnt, WIMPy maybe its the same |
| 14:19.17 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:19.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:33.12 | *** join/#asterisk-dev serafie1 (~erin@24.214.158.242) |
| 14:39.14 | oej | File? |
| 14:39.18 | file | hi |
| 14:39.22 | oej | Hi! |
| 14:39.34 | oej | Time for a q/a RTP session? |
| 14:39.39 | file | go! |
| 14:40.03 | oej | Trying to fix an old bug |
| 14:40.15 | oej | When we're on hold, we should not STOP rtcp and rtp keepalives |
| 14:40.27 | oej | so I'm implementing ast_instance_hold |
| 14:40.52 | oej | and simply throw away RTP in ast_rtp_write for streams that are on hold. |
| 14:41.10 | oej | Looked at p2p |
| 14:41.44 | oej | Now, if I put a call in the p2p bridge on hold, won't I be thrown out of p2p bridge mode, in order to service the other end with abba music? |
| 14:41.56 | file | yes |
| 14:42.43 | oej | So we agree that I don't need to bother with p2p for that sake? |
| 14:42.48 | file | yes |
| 14:42.50 | oej | Just for fixing rtcp... |
| 14:43.00 | oej | Thank you sir. |
| 14:43.10 | oej | Pls continue as if this discussion never happened. |
| 14:43.14 | oej | Have a great day! |
| 14:43.21 | file | did we just discuss something? |
| 14:43.31 | oej | Me, you talking to me? |
| 14:43.39 | file | putnopvut, hi! |
| 14:43.43 | oej | sip/dialplan_functions.c:145: warning: unused variable 'qos' |
| 14:43.49 | oej | Who cares about QoS anyway? |
| 14:45.22 | putnopvut | file: hi back! |
| 15:16.28 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:16.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:19.33 | file | leedm777, well... played... |
| 15:21.43 | mjordan | kerbloeey |
| 15:24.46 | mjordan | no one likes GoSubs anyway |
| 15:25.56 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 15:46.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:48.07 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:fcdd:6b67:1213:c577) |
| 15:52.38 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 16:19.26 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:fcdd:6b67:1213:c577) |
| 16:37.30 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:46.56 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:46.56 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:01.31 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jgnmokfmgyixuuyj) |
| 18:14.53 | *** join/#asterisk-dev caio1982 (~caio1982@177.40.113.8) |
| 18:30.38 | mjordan | hm. Looks like the stasis core merge changed the events sufficiently to break a few tests |
| 18:31.11 | file | mjordan, pitch forks and fire time |
| 18:32.04 | mjordan | nah |
| 18:32.13 | mjordan | what's interesting is that it was just a few of them, and recent tests at that |
| 18:32.21 | mjordan | wonder if it was just a merge nuking out some test events |
| 18:34.44 | mjordan | although those tests do interesting things with Local channels... |
| 18:36.30 | mjordan | eek. I'll be its that we are getting events for a channel before the Newchannel event |
| 18:37.35 | mjordan | welp. Oh wells. trunk will be faily for a bit. |
| 18:51.46 | mjordan | ...and grenade lobbed |
| 18:53.06 | file | mjordan, you mad mad man |
| 18:56.14 | mjordan | I look forward to the cries of developers everywhere |
| 18:56.38 | file | nah, that won't happen till Monday |
| 18:56.45 | file | people will live in bliss until then |
| 18:57.08 | Qwell | nah, they'll just see the email on Monday morning and mark it as read, since it's Monday |
| 18:58.01 | file | Qwell, well played sir |
| 18:58.45 | file | kicks printer |
| 18:59.19 | mjordan | or, they'll see CDR in the title and simply delete it |
| 18:59.24 | mjordan | would |
| 19:10.20 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:10.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:47.24 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:47.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:53.19 | leedm777 | mjordan: re: event ordering, those should sort themselves out as the other channel events move to Stasis. |
| 19:53.32 | mjordan | agreed |
| 19:53.35 | leedm777 | that's actually the reason why I went ahead and moved the VarSet event :-) |
| 19:53.45 | leedm777 | Which event did you see coming out of order? |
| 19:53.57 | mjordan | And I'm pretty sure that's what's causing it. Those tests look for a Newchannel event to know what Local channel half they're tracking, then wait until that channel enters an app |
| 19:54.28 | mjordan | Unfortunately, the Newexten events already occurred |
| 19:55.27 | mjordan | should be resolved once more of the channel based events get moved onto stasis core |
| 19:55.44 | leedm777 | agreed |
| 19:55.51 | leedm777 | experiences deja vu |
| 20:58.34 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-emogsoxyeksnefbv) |
| 21:17.08 | seanbright | i would like to suggest that asterisk 13 be skipped entirely |
| 21:17.24 | Qwell | We're going to do 13 twice. |
| 21:17.30 | seanbright | we don't need that kind of scrutiny |
| 22:02.24 | malcolmd | 13's an lts, it'll be with us for quite some time, mua..mua…muaha…muahahah |
| 22:06.48 | mjordan | the first LTS based on 12 no less |
| 22:06.50 | blitzrage | elevators skip the 13th floor |
| 22:06.52 | blitzrage | we should too |
| 22:06.52 | mjordan | so... yeah. |
| 22:07.08 | blitzrage | or make 13 a standard release... and make 14 the LTS |
| 22:07.16 | mjordan | two standards in a row? |
| 22:07.26 | blitzrage | it could be justified that so much changed in 12 we need another iteration |
| 22:08.01 | blitzrage | the main justification being that we aren't comfortable with a 13 number version being with us for 5 years |
| 22:09.05 | mjordan | heh |
| 22:09.18 | mjordan | I'm not sure I want another year without chan_gulp hitting an LTS |
| 22:09.28 | mjordan | we'll see how 12 goes :-) |
| 22:09.57 | snuff-home | hopes to test gulp next week.. |
| 22:13.24 | blitzrage | for some reason I think LTS's should be even numbers :) |
| 22:15.00 | jsmith | I'm interested to see how 12 goes, but I wouldn't be against pushing the LTS out to 14, depending on how long it takes to get 12 (and 13?) fully baked |
| 22:16.13 | blitzrage | there is also no rule that says a standard release needs to be released a full 12 months post previous release |
| 22:16.30 | blitzrage | it just needs to be maintained for the year |
| 22:16.32 | jsmith | Exactly :-) |
| 22:17.15 | blitzrage | just use 13 to fix any ABI/API stuff in chan_gulp you need, or core fixes etc |
| 22:17.22 | blitzrage | you are following all the rules at that point :D |
| 22:18.08 | blitzrage | (honestly I don't care about the 13 being an LTS, but in this case with a major shift in the way the most popular channel driver in Asterisk is used, being a bit cautious isn't a bad thing) |
| 22:18.55 | blitzrage | you'll know pretty quickly after the release of 12 whether making 13 an LTS is a good idea or not anyways, so the decision can easily be post-poned until post 12 release + a few months |
| 22:27.37 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:27.37 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:29.00 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fhlgzxfgbazhqihf) |
| 22:34.37 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-dxsqxkldtufvbazs) |
| 22:34.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 22:39.11 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 23:23.41 | *** join/#asterisk-dev zemmali-voip (~zemmali@unaffiliated/zemmali-voip) |
| 23:44.25 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-dxsqxkldtufvbazs) |