IRC log for #asterisk-dev on 20130301

00:23.45*** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger)
00:23.45*** mode/#asterisk-dev [+o pabelanger] by ChanServ
01:04.29*** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de)
01:23.17*** join/#asterisk-dev serafie (~erin@24.214.158.242)
01:34.49*** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell)
01:34.49*** mode/#asterisk-dev [+o sruffell] by ChanServ
05:31.51*** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202)
05:31.52*** mode/#asterisk-dev [+o tzafrir] by ChanServ
05:32.26*** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file)
05:32.26*** mode/#asterisk-dev [+o file] by ChanServ
06:03.14wedhornsnuff-work: good to hear. So how's that rollout coming along ;)
06:10.06snuff-workmaking last of scripts for my xml files..
06:10.17snuff-workdone my voicemail/skinny files already
06:11.38wedhorncool
06:16.08*** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net)
06:16.08*** mode/#asterisk-dev [+o oej] by ChanServ
06:17.07snuff-workwedhorn:  u have example of ur cnf.xml.. want to check against my current 1
06:20.29wedhornjust sent it to you. It's not what you'd call well formed, but it works
06:25.22snuff-worku know vim has nice way of 'auto formatting' ?
06:26.00snuff-workif u hit ctrl+v.. then go down ur page x number of lines.. then hit '=' auto indenting goodness
07:27.54*** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net)
07:27.55*** mode/#asterisk-dev [+o oej] by ChanServ
07:43.31*** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net)
07:43.32*** mode/#asterisk-dev [+o oej] by ChanServ
08:04.50*** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36)
09:48.31*** join/#asterisk-dev infobot (~infobot@rikers.org)
09:48.31*** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk
09:52.24*** join/#asterisk-dev infobot (~infobot@rikers.org)
09:52.24*** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk
09:58.14*** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c137:b84:36fa:c584)
10:23.51*** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c137:b84:36fa:c584)
11:30.22*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
12:09.49*** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file)
12:09.49*** mode/#asterisk-dev [+o file] by ChanServ
13:02.46*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
13:38.19*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
13:40.34*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
13:55.38*** join/#asterisk-dev serafie (~erin@nat/digium/x-ibifjinepbyuhftv)
14:09.41*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
14:09.41*** mode/#asterisk-dev [+o malcolmd] by ChanServ
14:20.06*** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson)
14:20.07*** mode/#asterisk-dev [+o putnopvut] by ChanServ
14:25.44*** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yvzrslgmxakpaowd)
14:25.45*** mode/#asterisk-dev [+o mjordan] by ChanServ
15:45.27*** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell)
15:45.28*** mode/#asterisk-dev [+o sruffell] by ChanServ
16:00.25*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
16:00.25*** mode/#asterisk-dev [+o malcolmd] by ChanServ
16:47.59*** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger)
16:47.59*** mode/#asterisk-dev [+o pabelanger] by ChanServ
17:00.24*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
17:02.52*** join/#asterisk-dev saghul (~saghul@ip3e830637.speed.planet.nl)
17:12.57*** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3)
17:42.35*** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net)
17:42.36*** mode/#asterisk-dev [+o oej] by ChanServ
18:31.06*** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm)
18:58.12*** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd)
18:58.13*** mode/#asterisk-dev [+o malcolmd] by ChanServ
20:13.55*** join/#asterisk-dev Demon_ru (~demon@ip253.net222.n37.ru)
20:15.35Demon_ruHi. Can anybody answer me why issue is closed? https://issues.asterisk.org/jira/browse/ASTERISK-17888
20:16.02Demon_ruI can't find this modification in any modern version or trunk
20:19.24Demon_ruleifmadsen, it was issue assigned to you :)
20:19.58leifmadsenlies
20:21.09Demon_ruleifmadsen, ok. Can anybody reopen this issue? I am not registered in bugtracker :(
20:22.12leifmadsenDemon_ru: in this case re-opening is not the best way -- open a new issue with the required data and link it
20:22.29Demon_ruI am not registered in bugtracker :(
20:22.30leifmadsenI doubt this issue should be reopened
20:22.35leifmadsenthen you should register
20:23.50Demon_ru"To request an account, please contact your JIRA administrators." Where are they?
20:24.07filehttps://signup.asterisk.org/ you can sign up there
20:24.27Demon_rufile, thank you
21:03.26mjordanfile: question about the change in res_rtp_asterisk for strictrtp
21:03.43fileyes
21:03.52mjordanwhen ICE completes, it looks like we mark strictrtp as open
21:04.14mjordantypically, when we re-init the probation period, it's because the endpoint that the RTP session is talking to is about to change
21:04.17mjordanor has changed
21:04.26fileyes.
21:04.30mjordanwouldn't we want to re-init still, even if ICE has completed?
21:04.48fileit does
21:05.04filewhen ICE negotiation begins it is open, when ICE negotiation completes it switches to learn
21:05.31mjordanthat's a bit of a different definition of open
21:05.55mjordanbut I suppose you want to accept RTP from wherever you get it from initially
21:06.14mjordanwell. Hm. I need to go back and re-read what strictrtp is preventing
21:06.48fileICE negotiation can take a little bit, so if it's not open and the source changes then you are dropping media until it completes
21:07.32WIMPymjordan: There was a talk about that on 28c3.
21:08.17mjordanI agree. I guess I'm concerned about cases where, for example, you're in ICE negotiation and an update comes into change source and you don't re-init the rtp source because you're technically open at that point
21:08.44WIMPyNo, one year erlier. 27c3 4193 £having fun with rtp". The video should be around, I guess.
21:09.54filemjordan, the source would get re-inited when the ICE negotiation completes
21:10.45mjordanthere's something about re-purposing states in an enum that fills me with fear :-)
21:10.52fileit's not re-purposing
21:11.04fileI want strictrtp in an open state while ICE negotiation is happening :P
21:11.20fileand once complete to learn, if configured to do so once again :P
21:11.32mjordanwell, open wasn't really used much at all prior to this change. It was really the antithesis of strictrtp
21:12.03filethe other open is to add another field that is set/unset when negotiation is happening and not block on that
21:12.12fileor rather, to disable strictrtp when it is set
21:12.31snuff-homemm.. new simcity looks way cool..
21:12.45fileI'm going to eat dinner now kthx
21:12.50mjordankkbye
21:26.42*** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de)
21:27.43mjordanputnopvut: I think we need to re-think the probation mode changes
21:28.35mjordanputnopvut: in the latest one way audio failure, there does not appear to be a prior address associated with the RTP instance. We essentially have a new RTP instance, it goes into probation mode, gets the RTP packets from the system being removed from the audio path, locks onto it, then rejects the audio from the new source
21:33.18putnopvutHm
21:33.46putnopvutMaybe there could be a reverse probation at some point.
21:34.08putnopvutLike, if you go a certain time without getting any audio from the locked-on source, then open yourself up to a different potential source?
21:34.18mjordanthat's possible.
21:39.08mjordanThat feels like a better alternative. In the original vulnerability, as soon as we got a packet from a new source we set that as the destination and sent RTP to it
21:39.54mjordanso long as we don't do *that*, we should be okay. If we instead create what amounts to a perma-probationary period for any new source, such that a received RTP packet from the old locked in source resets it, that would prevent it
22:03.20*** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-yvzrslgmxakpaowd)
22:08.52*** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-armriwgkptpkpplz)
22:08.52*** mode/#asterisk-dev [+o mjordan] by ChanServ
22:35.20*** join/#asterisk-dev w9sh (~w9sh@50-79-224-193-static.hfc.comcastbusiness.net)
22:50.05*** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-zmqfkyizrwpnlmee)
22:50.47*** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net)
23:33.29*** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-armriwgkptpkpplz)
23:51.40*** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger)
23:51.41*** mode/#asterisk-dev [+o pabelanger] by ChanServ

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.