| 03:05.44 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 03:05.44 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- ViewVC for SVN is down for the foreseeable future |
| 03:06.47 | Corydon76-dig | infobot: yay! |
| 03:06.49 | infobot | Yipee! |
| 03:06.58 | Corydon76-dig | ~botsnack |
| 03:06.58 | infobot | thanks, Corydon76-dig |
| 03:20.54 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 03:20.57 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 03:33.27 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 03:45.46 | Corydon76-dig | moy: could you take a look at issue 15820, please? |
| 03:46.14 | Corydon76-dig | The issue points to a revision in one of your branches, and I'm confused. |
| 03:46.31 | moy | hold on |
| 03:49.46 | moy | Corydon76-dig: mmm well, mfcr2 branch was merged into trunk while ago, why did you think that the branch was not merged in trunk? |
| 03:50.35 | moy | the change in question though comes from one merge from trunk to mfcr2 |
| 03:57.06 | russellb | Corydon76-dig: pong |
| 04:06.22 | moy | Corydon76-dig: trunk r175663 by mmichelson "Merge queue-reset branch to Asterisk" seems to be the commit removing that |
| 04:46.37 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) [NETSPLIT VICTIM] |
| 04:46.37 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 04:46.37 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 04:46.37 | *** join/#asterisk-dev c4rg (i=crg@lagoon.freebsd.lublin.pl) |
| 04:46.37 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 04:46.37 | *** join/#asterisk-dev korihor (n=korihor@190.77.83.180) |
| 04:46.37 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 04:46.37 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 04:46.37 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 04:46.37 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) [NETSPLIT VICTIM] |
| 04:46.37 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-daahdpyocoizartt) |
| 04:46.37 | *** join/#asterisk-dev ApOgEE (i=apogee@elite.bshellz.net) [NETSPLIT VICTIM] |
| 04:46.37 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) [NETSPLIT VICTIM] |
| 04:46.37 | *** join/#asterisk-dev jsmith-away (n=nnjsmith@asterisk/training-and-documentation-guru/jsmith) |
| 04:46.37 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 04:46.37 | *** mode/#asterisk-dev [+oooo snuff-home snuff-work jsmith-away ChanServ] by irc.freenode.net |
| 04:46.43 | *** join/#asterisk-dev ctooley (n=ctooley@c-68-52-165-168.hsd1.tn.comcast.net) |
| 04:46.43 | *** join/#asterisk-dev mohawk (n=ross@host217-40-110-153.in-addr.btopenworld.com) |
| 04:46.43 | *** join/#asterisk-dev micols (n=mio@rlogin.dk) [NETSPLIT VICTIM] |
| 04:46.43 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 04:46.43 | *** mode/#asterisk-dev [+o ctooley] by irc.freenode.net |
| 04:47.06 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 04:47.06 | *** join/#asterisk-dev justsomedood (n=justsome@mail.serverplus.com) [NETSPLIT VICTIM] |
| 04:47.06 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 04:47.06 | *** mode/#asterisk-dev [+o mog] by irc.freenode.net |
| 04:47.09 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) [NETSPLIT VICTIM] |
| 04:47.09 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) [NETSPLIT VICTIM] |
| 04:47.09 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 04:47.09 | *** join/#asterisk-dev gonzo- (n=gonzo@launchpad.bluezbox.com) [NETSPLIT VICTIM] |
| 04:47.09 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 04:47.09 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 04:47.10 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 04:47.10 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 04:47.10 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 04:47.10 | *** mode/#asterisk-dev [+ooo Qwell The_Boy_Wonder file] by irc.freenode.net |
| 04:47.28 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) [NETSPLIT VICTIM] |
| 04:47.28 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) [NETSPLIT VICTIM] |
| 04:47.28 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 04:47.29 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev Mw3 (i=mw3@88.151.97.220) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) [NETSPLIT VICTIM] |
| 04:47.29 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 04:47.30 | *** join/#asterisk-dev Corydon76-dig (i=five@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 04:47.30 | *** mode/#asterisk-dev [+oooo seanbright tzafrir_laptop mvanbaak Corydon76-dig] by irc.freenode.net |
| 04:47.30 | *** join/#asterisk-dev brookshire (i=mbrooks@hijacked.us) [NETSPLIT VICTIM] |
| 04:47.30 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) [NETSPLIT VICTIM] |
| 04:47.30 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) [NETSPLIT VICTIM] |
| 04:48.27 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 04:48.27 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 04:48.27 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 04:48.27 | *** mode/#asterisk-dev [+oo Deeewayne russellb] by irc.freenode.net |
| 04:48.42 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 04:55.50 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 05:04.21 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:04.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:08.06 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 05:16.17 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.134) |
| 05:48.38 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:48.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:49.36 | mvanbaak | mornin oej |
| 05:49.49 | oej | Good Morning, dear Michiel! I hope you had a wonderful night and that the sun is shining down upon you today! |
| 05:50.58 | mvanbaak | oej: it's raining here |
| 05:51.20 | mvanbaak | waidaminite |
| 05:51.20 | mvanbaak | what did I do to get a good morning like that ? |
| 05:52.27 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 05:52.27 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 05:52.27 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 05:52.27 | *** mode/#asterisk-dev [+oo Deeewayne russellb] by irc.freenode.net |
| 05:52.28 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 05:52.28 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 05:52.28 | *** join/#asterisk-dev gonzo- (n=gonzo@launchpad.bluezbox.com) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev janinge (i=j@ninge.net) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 05:52.28 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 05:52.28 | *** mode/#asterisk-dev [+ooo Qwell The_Boy_Wonder file] by irc.freenode.net |
| 05:52.45 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 05:52.45 | *** join/#asterisk-dev justsomedood (n=justsome@mail.serverplus.com) [NETSPLIT VICTIM] |
| 05:52.45 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 05:52.45 | *** mode/#asterisk-dev [+o mog] by irc.freenode.net |
| 05:53.17 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 05:57.11 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 05:58.24 | snuff-work | ;) |
| 05:58.35 | mvanbaak | there you go :) |
| 05:59.10 | snuff-work | looks @ sad ao2 jabber branch.. u'll get there one day my child.. |
| 05:59.24 | mvanbaak | whehehehe |
| 05:59.40 | mvanbaak | at least you did work on it |
| 05:59.51 | mvanbaak | I still have a branch that's a verbatim copy of trunk |
| 06:00.08 | snuff-work | well.. after i get it back to automerge.. i can hope it doesn't break again |
| 06:00.33 | snuff-work | i had ao2 changes for chan_gtalk / chan_jingle |
| 06:00.54 | snuff-work | but i will probably have to redo a bit more |
| 06:01.00 | snuff-work | after ao2 jabber |
| 06:07.31 | snuff-work | i know some ppl wanted some stuff to change to ast_list.. but that's little too much to change at once |
| 06:20.33 | oej | Sorry mvanbaak, I just meant to say "morn" |
| 06:25.36 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 06:25.36 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 06:25.36 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 06:25.36 | *** mode/#asterisk-dev [+oo Deeewayne russellb] by irc.freenode.net |
| 06:26.04 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 06:26.04 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 06:26.04 | *** join/#asterisk-dev gonzo- (n=gonzo@launchpad.bluezbox.com) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev janinge (i=j@ninge.net) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 06:26.04 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 06:26.04 | *** mode/#asterisk-dev [+ooo Qwell The_Boy_Wonder file] by irc.freenode.net |
| 06:26.05 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 06:26.05 | *** join/#asterisk-dev justsomedood (n=justsome@mail.serverplus.com) [NETSPLIT VICTIM] |
| 06:26.05 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 06:26.05 | *** mode/#asterisk-dev [+o mog] by irc.freenode.net |
| 06:29.03 | mvanbaak | lol oej |
| 06:39.13 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 06:39.13 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 06:39.13 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 06:39.13 | *** mode/#asterisk-dev [+oo Deeewayne russellb] by irc.freenode.net |
| 06:39.14 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 06:39.14 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 06:39.14 | *** join/#asterisk-dev gonzo- (n=gonzo@launchpad.bluezbox.com) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev janinge (i=j@ninge.net) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 06:39.14 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 06:39.14 | *** mode/#asterisk-dev [+ooo Qwell The_Boy_Wonder file] by irc.freenode.net |
| 06:39.16 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) [NETSPLIT VICTIM] |
| 06:39.16 | *** join/#asterisk-dev justsomedood (n=justsome@mail.serverplus.com) [NETSPLIT VICTIM] |
| 06:39.16 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 06:39.16 | *** mode/#asterisk-dev [+o mog] by irc.freenode.net |
| 06:39.54 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.22) |
| 07:04.08 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:04.50 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:06.35 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 07:24.43 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 07:36.37 | mvanbaak | oej: I have something really weird in asterisk |
| 07:36.38 | mvanbaak | [Sep 3 09:35:51] NOTICE[7987]: chan_sip.c:21809 handle_request_subscribe: Received SIP subscribe for peer without mailbox: (null) |
| 07:36.52 | mvanbaak | I have 2 peers on this box, and they both have voicemail |
| 07:40.06 | mvanbaak | meh |
| 07:40.22 | mvanbaak | [Sep 3 09:39:51] No matching peer for '192.168.2.4' from '192.168.2.68:5060' |
| 07:40.54 | mvanbaak | never mind, I think it's zoiper |
| 07:45.47 | oej | NULL? |
| 07:45.49 | oej | Weird |
| 07:45.53 | oej | Hmm |
| 07:46.02 | mvanbaak | yeah |
| 07:57.51 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:05.25 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:05.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:19.40 | *** join/#asterisk-dev obnauticus (n=l@about/windows/regular/obnauticus) |
| 08:26.07 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 08:27.50 | *** join/#asterisk-dev jmls (n=jmls@217.36.208.155) |
| 10:01.45 | kaii | "PICKUP"MARK" obviously is a pun, isnt it? ;-) |
| 10:02.22 | mvanbaak | you think ? |
| 10:03.20 | kaii | i met mark in a bar in berlin once |
| 10:04.42 | kaii | but i did not pick him up :) |
| 10:12.21 | atis_work | hmm, is func_callerid working for anybody on 1.6.1.5? |
| 10:24.41 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) [NETSPLIT VICTIM] |
| 10:24.41 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 10:24.41 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) [NETSPLIT VICTIM] |
| 10:27.36 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 10:27.44 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:27.44 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 10:27.44 | *** mode/#asterisk-dev [+o mvanbaak] by irc.freenode.net |
| 10:27.50 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 10:27.50 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 10:28.00 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 10:28.03 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) [NETSPLIT VICTIM] |
| 10:28.27 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 10:28.27 | *** join/#asterisk-dev brookshire (i=mbrooks@hijacked.us) |
| 10:28.29 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) [NETSPLIT VICTIM] |
| 10:28.29 | atis_work | what was that? |
| 10:28.30 | atis_work | did some transatlantic cable just disconnected? :p |
| 10:28.47 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 10:28.47 | *** join/#asterisk-dev jmls (n=jmls@217.36.208.155) [NETSPLIT VICTIM] |
| 10:28.47 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 10:28.47 | *** join/#asterisk-dev Mw3 (i=mw3@88.151.97.220) |
| 10:28.47 | *** join/#asterisk-dev Corydon76-dig (i=five@pdpc/supporter/bronze/Corydon76-home) |
| 10:28.47 | *** mode/#asterisk-dev [+oo seanbright Corydon76-dig] by irc.freenode.net |
| 10:34.43 | mvanbaak | atis_work: netsplit |
| 11:07.29 | jmls | heh |
| 11:15.41 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 11:21.59 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 11:32.54 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:32.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:47.36 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 11:48.10 | *** part/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 11:49.01 | *** join/#asterisk-dev Dovid (n=annon@ool-4355e297.dyn.optonline.net) |
| 11:49.09 | Dovid | ./j #linux |
| 11:50.52 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:50.52 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:59.44 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 11:59.44 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 12:00.42 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 12:16.19 | kpfleming | oej: ping |
| 12:20.18 | oej | pong |
| 12:21.23 | oej | kpfleming: pong |
| 12:21.56 | kpfleming | i finished setting up our SIPit test system yesterday... this time it's a box running Xen with four separate VMs. much cleaner than what we did in France :-) |
| 12:24.39 | oej | Great! |
| 12:25.09 | oej | I've began to like OpenVZ. Easier to manage than Xen |
| 12:25.37 | oej | Which hotel are you going to honor with your presence? |
| 12:27.21 | kpfleming | i've never used anything but VMware before, but setting up Xen was dead simple |
| 12:27.28 | kpfleming | i don't know how anything could be easier :-) |
| 12:28.17 | kpfleming | we're not staying in Durham, we'll be at the Homewood Suites in Dover |
| 12:29.41 | oej | Dover/calais - that's europe. |
| 12:32.00 | oej | Well, the prices wasn't that good. |
| 12:32.39 | oej | pets allowed, so you can bring your cat |
| 12:32.46 | kpfleming | not this time |
| 12:32.59 | kpfleming | we got a good deal, i had a special offer from hilton hotels |
| 12:34.08 | oej | Ahhh |
| 12:34.10 | oej | I see |
| 12:34.18 | oej | girls special 126 USD |
| 12:34.22 | oej | hmmm |
| 12:34.31 | oej | There's a mystery hidden here |
| 12:35.07 | kpfleming | lol |
| 12:35.19 | kpfleming | the price was lower when i booked 2 months ago :-) |
| 12:35.28 | oej | Am I going to be testing with a lawyer? |
| 12:35.30 | oej | :-) |
| 12:37.20 | kpfleming | nope |
| 12:37.43 | kpfleming | she'll be coming on friday though, when we're heading down to connecticut for the weekend |
| 12:38.30 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 12:42.11 | oej | Nice! |
| 12:47.40 | kpfleming | i'm playing in a large-ish pool tournament there on the weekend, then we're off to spain for VOIP2DAY |
| 12:47.43 | kpfleming | will be a long trip |
| 12:47.57 | oej | Yeah, I'm coming home monday, leaving wednesday again. |
| 12:50.35 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 12:50.39 | kpfleming | when are you arriving in Durham? |
| 12:53.52 | oej | Trying to figure out airlines, but late Sunday evening is my guess. I have many events to attend to on Saturday - those types that I will become a single child-less man if I don't participate in. |
| 12:55.58 | oej | Hmm. I can't find the CEL-mysql driver... |
| 12:56.03 | putnopvut | kpfleming, where in Spain are you going? |
| 12:59.52 | oej | Madrid |
| 13:01.01 | kpfleming | yep |
| 13:01.23 | kpfleming | arrive on tuesday morning, leave on sunday morning |
| 13:01.37 | kpfleming | will have about 1.5 days of attending the show, the rest of the time for doing touristy stuff |
| 13:03.38 | oej | You are just focusing on private stuff, kpfleming. I'm just flying down there and back the day after. Work focus. |
| 13:04.02 | kpfleming | the flight cost was US$600 for the longer trip, US$2600 for the shorter trip |
| 13:04.03 | oej | Having said that, an explanation is that my wife couldn't join me for the weekend in Madrid |
| 13:04.05 | kpfleming | it was an easy decision |
| 13:04.38 | oej | Gosh, I'm paying almost as much as you for the ticket to Madrid |
| 13:06.09 | kpfleming | anyway, we're arriving in NH on saturday, because we'll be doing setup on sunday (we're providing the internal phone system this time, using Switchvox) |
| 13:06.27 | kpfleming | and we'll have wideband phones too! |
| 13:40.00 | Corydon76-dig | russellb: are any of us attending the gsoc mentor summit in October (1 week after the end of Astricon) |
| 13:52.31 | *** join/#asterisk-dev michael-i (n=michael-@141.41.40.153) |
| 13:52.56 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 13:55.26 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 13:55.26 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:14.15 | Marquis42 | Hrmmm... Is there a way to re-publish a review request? |
| 14:18.52 | russellb | Corydon76-dig: I need to work on that. They only confirmed that we were invited about 14.5 hours ago :-) |
| 14:32.36 | *** join/#asterisk-dev mnt_real (n=sinan@bas12-montrealak-1167977240.dsl.bell.ca) |
| 14:40.22 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:50.35 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:50.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:54.30 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.134) |
| 15:10.12 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:10.12 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:10.18 | Deeewayne | russellb, I addressed rmudgett's reviewboard suggestion a couple of days ago. Do you think he might be able to peak at https://reviewboard.asterisk.org/r/347/ and give a 'ship it' sometime ? I only ask you because there is no way to contact him via IRC |
| 15:10.49 | Deeewayne | actually 'peeking' would be better than 'peaking' |
| 15:11.00 | russellb | heh, you can contact him via rmudgett@digium.com |
| 15:11.51 | Deeewayne | ok |
| 15:17.21 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:22.58 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 15:25.57 | atis_work | ok, who broke chan_sip in 1.6.1.5 |
| 15:27.07 | atis_work | i have no audio on 1.6.1.5, however 1.6.1.4 works fine. also everything is recorded on asterisk http://imagebin.ca/view/W4I2sD.html http://pastebin.ca/1552700 |
| 15:28.14 | atis_work | could someone help me identify exactly where asterisk sends something bad to phone, so that it doesn't send RTP |
| 15:28.36 | leifmadsen | and zero configuration or network topology changes? |
| 15:28.46 | leifmadsen | because I'm not having an issue on 1.6.1.5 with audio |
| 15:28.47 | atis_work | leifmadsen: exactly |
| 15:29.12 | atis_work | leifmadsen: i even tried 1.6.1.5 without any patches |
| 15:29.43 | atis_work | leifmadsen: could you try using the same device for calling itself through asterisk |
| 15:30.01 | leifmadsen | I can't right now unfortunately, I have some other more pressing work issues to resolve |
| 15:30.07 | atis_work | leifmadsen: i have 24port gateway, no voice between it's own ports, but works with another device |
| 15:30.12 | atis_work | ok, sure :) |
| 15:30.19 | leifmadsen | but it works between other devices? |
| 15:30.22 | atis_work | yes |
| 15:30.27 | oej | By default, we all blame file for those issues, atis. |
| 15:30.32 | atis_work | hehe |
| 15:30.53 | atis_work | i wanted to blame oej, but i didn't saw he's name on top of changes summary :( |
| 15:31.07 | oej | No, I broke 1.6.1.0 |
| 15:31.14 | oej | Then russellb unbroke it. |
| 15:31.36 | oej | I think it's in his work description. "Unbroke what other people break." |
| 15:31.46 | russellb | I do my share of breakage, too |
| 15:31.50 | russellb | it's a team effort, heh |
| 15:32.01 | oej | More sofisticated breakage, that is. ;-) |
| 15:32.12 | oej | yes, we all work together breaking stuff as a happy family... |
| 15:32.34 | oej | Dinner time. For the first time in a long time I got focus and took care of a few bug reports. Feels good :-) |
| 15:32.42 | leifmadsen | atis_work: what softphone/hardphone are you using? |
| 15:32.48 | leifmadsen | oej: yay! |
| 15:33.00 | oej | See you later |
| 15:33.07 | atis_work | leifmadsen: Audiocodes MP-124 |
| 15:33.22 | leifmadsen | atis_work: try session-timer=refuse in sip.conf and re-test |
| 15:34.44 | kaii | there are 2 types of blind transfer.. A) blind transfer without even answering the call and B) blind transfer after answering the call. (but without talking to the target, so its not an attended transfer) |
| 15:35.03 | atis_work | leifmadsen: nope, session-timer doesn't help |
| 15:35.12 | leifmadsen | you've set it refused as I said above? |
| 15:35.21 | leifmadsen | does the UAS require session timers? |
| 15:35.27 | leifmadsen | M15621 |
| 15:35.29 | MuffinMan | [ready for review] [Asterisk] Channels/chan_sip/General 0015621: [patch] session-expires default timer wrong reported by fnordian (Karma: +18.50) https://issues.asterisk.org/view.php?id=15621 |
| 15:35.29 | atis_work | yes |
| 15:35.35 | leifmadsen | atis_work: that is why -- known issue |
| 15:35.42 | leifmadsen | please test that patch |
| 15:35.49 | kaii | at least in Asterisk 1.4, only in case B) the "BLINDTRANSFER" variable |
| 15:35.56 | russellb | was that a regression, or was it always broken with session timers? |
| 15:36.30 | leifmadsen | russellb: it appears bugfix 15403 broke it |
| 15:36.36 | kaii | is set.. in case A) it's not. can this be considered a bug and will a patch go into next 1.4 bugfix release, if i submit it? (i already have a working patch) |
| 15:36.36 | russellb | M15403 |
| 15:36.38 | leifmadsen | so it appears to be a regression |
| 15:36.39 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0015403: [patch] Session timer is not activated reported by makoto (Karma: +8.50) https://issues.asterisk.org/view.php?id=15403 |
| 15:36.50 | russellb | leifmadsen: know what release that went in to? |
| 15:36.52 | kaii | ok bad timing will ask again later |
| 15:37.01 | leifmadsen | 1.6.1.2? |
| 15:37.06 | leifmadsen | not 100% sure though |
| 15:37.24 | leifmadsen | it looks recent actually |
| 15:37.31 | leifmadsen | so looks like 1.6.1.5 may be the first release with it |
| 15:37.43 | leifmadsen | merged 07-15 |
| 15:37.45 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:37.57 | atis_work | leifmadsen: thanks, this fixed |
| 15:38.08 | leifmadsen | atis_work: please report on that issue that it worked for you |
| 15:44.17 | kaii | on a really blind SIP transfer (without answering the call in the first place), the variable BLINDTRANSFER is not set. it is only set when you answer the call and do a blind or attended transfer after answering.# |
| 15:44.35 | kaii | is this considered a bug and will a bugfix patch get it into next 1.4 release? |
| 15:45.19 | leifmadsen | kaii: is there an open issue for this? I'm not sure if that is a bug -- it'll depend on how the SIP transactions happen I suppose. How are you doing a blind transfer without actually doing a transfer? (isn't that just a 302 Redirect?) |
| 15:45.46 | kaii | exactly, 302 redirect. not refer. |
| 15:45.53 | leifmadsen | that doesn't sound like a bug then |
| 15:46.29 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 15:46.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:46.29 | kaii | but its a blind transfer, one that happens quite often here. ("that caller is not for me, i fire him to the right target") |
| 15:46.51 | leifmadsen | how is it a blind transfer if you're not doing a transfer? |
| 15:46.54 | leifmadsen | I don't quite understand |
| 15:47.07 | kaii | well, its a "forward on demand" |
| 15:47.15 | kaii | snom phones have a key for sending 302 redir. |
| 15:47.27 | kaii | our customers use this key alot. |
| 15:47.33 | leifmadsen | perhaps someone better versed in SIP messages can answer this better than I |
| 15:47.40 | leifmadsen | personally I don't feel it is a bug, but perhaps I am wrong |
| 15:47.51 | kaii | and accidentially they transfer the caller to a busy extension, where the caller is lost after. |
| 15:48.27 | kaii | maybe its not a bug from RFC view to sip messages, but it obviously is a bug from a users view who presses this button :) |
| 15:48.42 | leifmadsen | I wouldn't say obviously, but if you say so :) |
| 15:48.43 | kaii | oej: what do you think. |
| 15:48.46 | leifmadsen | please open an issue to track it |
| 15:48.55 | kaii | will do |
| 15:48.56 | oej | I think about a lot of stuff. |
| 15:49.01 | Corydon76-dig | kaii: you don't have voicemail on your extensions? |
| 15:49.08 | atis_work | ok, thanks everyone regarding M15621, i attached my SIP traces and comments |
| 15:49.11 | kaii | oej: is 302 redir considered a blind transfer? |
| 15:49.14 | oej | I logged in in the middle of it all |
| 15:49.16 | atis_work | i wonder if it's going to be assigned to anybody :) |
| 15:49.32 | oej | Oh... To start with, Asterisk code for 302 support stinks. We should rewrite that. |
| 15:49.42 | kaii | Corydon76-dig: users can configure if they wish a busy signal or voicemail or ivr, or failover to group .... |
| 15:49.58 | oej | I can't call it a blind transfer, a transfer to me happens when a call is up |
| 15:50.04 | kaii | Corydon76-dig: in case of a busy transfer, i would love to route the caller back to the transferer, indicating that the target is busy. |
| 15:50.07 | oej | It's a forwarding scheme |
| 15:50.08 | Corydon76-dig | kaii: It actually sounds like a failure of your DIALPLAN, not of Asterisk |
| 15:50.17 | kaii | Corydon76-dig: using "BLINDTRANSFER" variable this is possible (if set) |
| 15:51.06 | oej | We should really hook 302 into the forwarding scheme of dial and take it back to the dialplan. If it's not changed lately, it actually bypassed the dialplan in some cases, which is no good. |
| 15:51.19 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 15:51.43 | oej | Dial has support for call forwarding I believe |
| 15:52.01 | kaii | oej: fact is, snom has a "transfer" button which sends 302 redir if you dont answer the call and press the button in ringing state. it send sends a 302 redir forward request to another extension. and BLINDTRANSFER is not set in this situation. |
| 15:52.47 | Corydon76-dig | kaii: it's not actually a blind transfer, then |
| 15:52.50 | kaii | i wrote a patch that enables Dial() to set this variable on a forward request, so that such a "transfer"(user view)/"forward request"(dev view) can be detected in the dialplan |
| 15:53.12 | kaii | Corydon76-dig: from the users view it definitely is :) |
| 15:53.24 | Corydon76-dig | kaii: that's a call forward |
| 15:53.44 | oej | russellb: Online, time for a question? |
| 15:53.53 | Corydon76-dig | kaii: then your users are mistaken on terminology. Blind transfer requires that the call be answered, first |
| 15:53.57 | kaii | from the technical developer view it is, right. but ask some users and they will call it transfer |
| 15:54.22 | oej | kaii: Check how we handle call forwarding in dial, if we set any channel variables. It should be the same as call forwarding, not transfer. |
| 15:54.36 | kaii | Corydon76-dig: my users just want to use a phone, they dont want to know anything about tech stuff, and all they know that there is a button, labeled "transfer" what exactly does what i said. |
| 15:54.36 | Corydon76-dig | Ask some users, and they will tell you the Earth is only 6000 years old |
| 15:55.09 | oej | kaii: we have to know about tech stuff and separate it, regardless of the users. You can then create the same user experience in your dialplan. Technichally, a 302 is NOT a transfer. |
| 15:55.22 | kaii | Corydon76-dig: alright, got the point. nevertheless, this is an issue for them. |
| 15:56.07 | kaii | oej: yes i understood. but there is no channel variable indicating a forward. please correct me if i'm wrong. |
| 15:56.08 | oej | If we designed for users we should have apps like "callmom()", "dontanswerscarygirl()" and "listentoboringbrother()" |
| 15:56.10 | oej | :-) |
| 15:56.47 | kaii | these apps would be awesome .. do you have plans to implement them shortwhile? |
| 15:56.51 | oej | Then we need one, so call forwarding can be caught in the dialplan. Like "if this dial() ends up being forwarded, stop processing and set a channel variable so I can make a decision" |
| 15:57.17 | oej | kaii: Still looking for funding. My mom did not write a check. |
| 15:58.10 | kaii | what would be an appropriate name for this variable? in a first version of my patch it was "FORWARDEDBY", then later i found that using "BLINDTRANSFER" was sexy because i can handle all transfer/forward requests with a single variable (which from the users view, are the same thing in different situations) |
| 15:59.48 | kaii | i assume the new variable will be considered a "new feature" then and so never make it in 1.4 ... pity |
| 16:00.57 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:02.15 | atis_work | kaii: isn't there a context for 302 redirects? |
| 16:02.33 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.124) |
| 16:02.56 | kaii | atis_work: there is a context for transfers, stop mixing two technically different things ;-) |
| 16:03.37 | oej | In SIP we set SIPREDIRECTURI :-) |
| 16:03.52 | atis_work | well, i remember some users have set some redirect on phone, and call got terminated in some weird context |
| 16:03.59 | atis_work | i never cared much to find out why |
| 16:04.31 | oej | Hmm. We're not checking here if it's a local SIP domain. Bad. |
| 16:04.45 | oej | As I said, SIP 302 support needs a lot of love and peace and happiness |
| 16:05.04 | kaii | i've seen that |
| 16:05.10 | kaii | but hey, it works (tm) |
| 16:05.46 | oej | Well at least we set SIPDOMAIN and SIPREDIRECTURI and push it through call_forward |
| 16:06.10 | oej | And signal busy to app_dial... |
| 16:06.24 | kaii | some var containing "SIP/100-ab1234cd" would be nice :) |
| 16:06.28 | oej | App dial should then issue a call forward in your dialplan |
| 16:06.58 | kaii | it does. its all working. but you cannot detect that a forward happened in dialplan |
| 16:07.04 | oej | well REDIRECTURI@SIPDOMAIN will get you there. |
| 16:07.15 | oej | sip/100-abcd is a channel identifier |
| 16:07.50 | oej | Well, check if you have SIPREDIRECTURI set early in the dialplan. If it is set, then it's a call forward. |
| 16:08.50 | oej | Reading app_dial, you set the variable FORWARD_CONTEXT and all forwards will end up there. In that context, you check the SIPREDIRECTURI to make sure it's a 302 and no other call forwarding scheme. |
| 16:08.51 | oej | Done. |
| 16:09.24 | oej | FORWARD_CONTEXT is documented in the channel variables document |
| 16:09.49 | oej | So you can detect it in the dialplan. In fact, you can control it. You have the power, kaii, given to you by us. |
| 16:10.03 | kaii | lol |
| 16:10.04 | oej | Use it well, while I'm going to eat dinner... |
| 16:10.37 | leifmadsen | I need lunch soon |
| 16:11.22 | Qwell | sends leifmadsen lunch via jabber |
| 16:11.43 | leifmadsen | Qwell: that's be awesome! |
| 16:15.15 | *** join/#asterisk-dev jtodd (i=f53pggej@204.91.156.197) |
| 16:15.15 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 16:23.01 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-64-036.xd-dynamic.ctbcnetsuper.com.br) |
| 16:24.19 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:24.19 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:26.57 | kaii | oej: SIPREDIRECTURI does not contain anything if printed with NoOp() in the target extension. but in see sourcecode i can clearly see that it should be set to the value of the Contact Header. |
| 16:27.19 | kaii | s/see sourcecode/the sourcecode/ |
| 16:31.51 | *** join/#asterisk-dev work|philipp64 (n=chatzill@mail.redfish-solutions.com) |
| 16:35.02 | oej | What is the setting for promiscous mode redirects? It should be OFF. |
| 16:36.11 | kaii | promiscredir = no |
| 16:36.11 | oej | Interesting. Can you check this: Before dial() in your dialplan, add answer(). Then check if you get the variable - ok? |
| 16:36.34 | kaii | no option. why should i answer a call and make the caller pay for getting busy in the worst case? |
| 16:36.43 | kaii | but i will try this out |
| 16:36.49 | kaii | just for verification |
| 16:37.22 | kaii | this is asterisk 1.4.26.1 (latest), not 1.6 .. fyi |
| 16:39.25 | oej | leifmadsen: If you're about to release new 1.6 releases wait for a patch from russellb on the issue on peer matching. It needs to get out there in next release. |
| 16:39.26 | kaii | even with answer in the first place (in both extensions: dialed target AND target of redir) the variable is empty in the target extension. |
| 16:39.44 | oej | is a pain in the a... but it is important. |
| 16:40.12 | oej | kaii: Do you see tha tit goes to FORWARD_CONTEXT? |
| 16:40.15 | kaii | that peer matching stuff from the list sounds very important |
| 16:40.25 | oej | kaii: I can't test right now, but will later. |
| 16:40.28 | kaii | oej: i do not use forward_context right now. |
| 16:40.32 | russellb | oej: This is a security release. Do you feel that it is important enough to include with the security release? |
| 16:41.26 | kaii | oej: nevertheless, i will prefer patching app_dial to set a variable containing the transferers channel and using this variable over a too-complicated-when-it-could-be-so-simple solution |
| 16:41.28 | oej | russellb: yes, it's almost a big security hole if it gets out there and it is a serious flaw if people are using tcp/tls in 1.6 release. So yes, it's important. |
| 16:41.49 | oej | kaii: Well, call forwarding is not very easy. I'll check. |
| 16:42.26 | kaii | oej: the patch is done. but "BLINDTRANSFER" seems to be the wrong variable name .. and since this is in fact a "new feature" in 1.4 it will most likely never make it into release.. pity. |
| 16:42.41 | kaii | (patch for app_dial i mean) |
| 16:42.48 | russellb | oej: Okay. I understand that it is important. I don't know if I would call it a security hole, since you can spoof a source IP just as easy as a Contact header. Anyway, I'll get it done. Thanks for the input. |
| 16:43.47 | russellb | It should be a quick patch I think ... |
| 16:44.51 | kaii | russellb: at least its a bug that leads to some pain when trying to understand why calls from different accounts at the same ISP are getting mixed together :) |
| 16:45.00 | russellb | totally understood |
| 16:45.02 | russellb | will fix!! |
| 16:46.21 | kaii | russellb: is that right what i said? would a new variable to indicate a call forward in app_dial be considered a new feature and never make it into release? |
| 16:46.39 | kaii | s/variable/channel variable/ |
| 16:47.11 | kaii | i am talking about 1.4 |
| 16:47.59 | russellb | I'm sorry, I can't look at that right now |
| 16:48.40 | kaii | ok. then i will answer the question myself and say its not a bug, its a feature. ;-) |
| 16:51.14 | leifmadsen | no features go into release branches |
| 16:51.17 | leifmadsen | only trunk |
| 16:57.28 | kaii | leifmadsen: the consequence is not opening an issue for that |
| 16:57.41 | kaii | ( i fear bad karma ) |
| 16:57.48 | oej | kaii: Yes, any new functionality is not integrated in releases |
| 16:57.58 | oej | But existing stuff should work. |
| 16:58.21 | oej | kaii: where's your patch? |
| 17:00.29 | oej | Hmm. A new security hole in IAX2? |
| 17:01.30 | kaii | oej: http://pastebin.ca/1552790 ... maybe its interesting for trunk/1.6 |
| 17:01.31 | Corydon76-dig | oej: information to be forthcoming. |
| 17:01.43 | kaii | oej: its blatantly easy. |
| 17:01.51 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.120) |
| 17:03.59 | kaii | oej: i was astonished that BLINDTRANSFER is set by chan_sip in 1.4 .. in 1.2 it was only set by res_features |
| 17:04.37 | oej | Well, we try to improve. Chan_sip also supports TRANSFER_CONTEXT |
| 17:07.04 | *** join/#asterisk-dev jtodd (i=sg1xaluc@ns.fox-den.com) |
| 17:07.04 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 17:07.18 | kaii | oej: i've seen that |
| 17:08.36 | kaii | oej: btw, a disclaimer is on file :) so you can use the code in trunk if you decide to. |
| 17:10.50 | Qwell | kaii: has to go through mantis (and it's a different license agreement than the disclaimer now) |
| 17:11.25 | kaii | Qwell: what different licence agreement? |
| 17:11.31 | Qwell | the one on mantis |
| 17:12.05 | kaii | i have one on mantis. but i fear bad karma for putting new features for 1.4 in there.. i could patch against 1.6 too, but i'm lazy today. |
| 17:15.08 | oej | The question is what you want to store in the variable. I would suggest the original extension. |
| 17:15.22 | oej | You want to know where the call was going originally |
| 17:19.13 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:20.12 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 17:21.06 | kaii | oej: it stores the same thing BLINDTRANSFER stores. the channel name of the transferer ... CALLFORWARD=SIP/999-ab1234cd when SIP/999 transferred/FORWARDED the caller |
| 17:21.30 | kaii | oej: that way, i can use the same dialplan logic to route busy transfers back to the transferer. |
| 17:21.42 | kaii | s/transfer/call forward/ |
| 17:21.58 | oej | Then we need another variable with the extension that caused the redirect |
| 17:22.40 | kpfleming | the redirecting device may not even map to an extension |
| 17:23.05 | kaii | oej: why? blindtransfer doesnt do this thing, too. does it? |
| 17:23.24 | kaii | kpfleming: thats right, but if thats true, then BLINDTRANSFER is a bug. |
| 17:25.09 | kaii | in my case, i really need the device. because using doublecall/multicall/whatever call, a Dial(SIP/100) can get expanded to Dial(SIP/100&SIP/anotherone) ... if SIP/100 is busy, and SIP/anotherone does the forward, then i route back the caller to SIP/anotherone. |
| 17:25.37 | kaii | (only if the target is busy) |
| 17:26.09 | kaii | so the caller never goes to nirvana |
| 17:26.27 | oej | transfer and call forward is not the same thing, can't be handled the same way really. |
| 17:26.53 | oej | call forward happens when we have a call to an extension and it get's redirected somewhere else in the dialplan. We have a forwarder and a forward destination and a previous destination. |
| 17:27.18 | oej | Transfer is in UP state |
| 17:27.19 | kpfleming | and in general the previous destination and the forwarder are one and the same |
| 17:27.36 | oej | Well destination = exten forwarder=device |
| 17:27.47 | oej | Two different name spaces |
| 17:27.50 | kpfleming | so what is the 'forwarder' useful for then? |
| 17:28.11 | oej | To me, nothing really. But Kaii seems to want it. |
| 17:28.15 | kpfleming | ahh |
| 17:28.17 | kpfleming | understood |
| 17:28.34 | oej | Could be used to check stuff with the SIPPEER function or similar in other channels. |
| 17:28.46 | kpfleming | assuming it's SIP :-) |
| 17:28.55 | kaii | kpfleming: again. a caller rings exten 100, which in fact does Dial(SIP/100&SIP/anotherphone) .. if 100 is busy, and anotherphone uses 302 redir to send the caller somewhere else, and the destination somewhere else is busy, i really, really want the caller to get back to SIP/anotherphone |
| 17:29.13 | kpfleming | why? the caller didn't call anotherphone, they called exten 100 |
| 17:29.14 | kaii | kpfleming: assuming SIP, right. :) |
| 17:29.23 | kpfleming | and if SIP/100 is now available, it should get the call |
| 17:29.40 | kaii | kpfleming: hm.. |
| 17:29.42 | oej | Agree with kpfleming. It's about the extension |
| 17:29.45 | kpfleming | this is what putnopvut is working on right now in his CCSS branch |
| 17:30.19 | kpfleming | tracking how the call forked so that it can be regenerated and follow the same path |
| 17:30.24 | oej | But the question could be if the two devices have different contexts, we might want to jump into forward_context, then check the authorized incoming context and send the call there |
| 17:30.28 | kaii | kpfleming: you're right, if SIP/100 is available later, it should get the call. |
| 17:30.30 | kpfleming | or not... if the admin wants to modify the recall list |
| 17:31.00 | oej | I should not be able to call forward to ANY extension in the dialplan, or not even to the contexts that the CALLER can reach. |
| 17:31.11 | kaii | kpfleming: but what if exten 100 is not just Dial(SIP/100&SIP/foo) but Playback(please-wait)+Dial(SIP/100&SIP/foo) ... the caller then hears the "please-wait" two times in a row |
| 17:31.20 | kpfleming | that's right |
| 17:31.24 | oej | I should only be able to forward to my default context or FORWARD_CONTEXT if it's set |
| 17:31.26 | kaii | this is just an example, the extension logic before dial can be more complex. |
| 17:31.30 | kpfleming | of course |
| 17:31.47 | kpfleming | it could query a database to produce the list of targets to dial, and have different lists at different times of day, etc. |
| 17:31.56 | kaii | so i would have to use local channels for each dial to an "extension" (extension as in "physical phone") |
| 17:32.13 | kpfleming | this is why he's workong on building a tree of actual destinations that were dialed, so that the call can be regenerated along that same path if desired |
| 17:32.34 | kpfleming | but redialing the original extension is really the right thing to do |
| 17:32.47 | kaii | sounds good to me. but its WIP.. i need working solutions :)= |
| 17:33.04 | kpfleming | well, you can hack something together i'm sure |
| 17:33.11 | kaii | oh noes.# |
| 17:33.26 | kpfleming | all you have to remember is which exten@context was dialed by the top-level channel |
| 17:34.55 | oej | ...and we haven't even discussed CDRs for call forwarding ... ;-) |
| 17:35.23 | kaii | an easy fix would be to have a context with an extension to each phone (or group of phones if an extension has multiple devices) with just a simple dial() to in .. then in a DDI for example, i could dial that via Local/ and forward in that context as much as i want without having any dialplan logic being executed unwanted multiple times (like Playback(please-wait)) |
| 17:35.46 | kaii | oej: CDRs for call forwarding are a mess. thx for bringing this topic up :D |
| 17:36.32 | kpfleming | CDRs were never intended to be able to represent the things that Asterisk is capable of |
| 17:36.32 | kaii | but even better are attended transfers in CDR handling .. no way here. |
| 17:36.33 | kpfleming | CDRs are for "party A calls party B" |
| 17:36.46 | kaii | we know |
| 17:39.02 | kaii | well for a hotfix re-enabling the disered behaviour in 1.4 i will just use the patch we already talked about. a clean solution for the future is doing it with extensions. that will cause some major changes to the dialplan |
| 17:39.12 | kaii | *desired |
| 17:40.16 | kaii | thank you oej and kpfleming for pointing out some issuesi did not see in the first place. |
| 17:40.23 | kpfleming | you are welcome |
| 17:40.58 | mvanbaak | I'm having issues as well. but they cannot be solved with a patch |
| 17:40.59 | kaii | pity were not using 1.6 and no feature i implement will ever make it into asterisk :) |
| 17:42.28 | mvanbaak | stuff we make is against 1.4 as well, but then I take it home and port it to trunk, test it on my home box and put it on mantis |
| 17:43.01 | mvanbaak | if it goes in I make a note on our office systems in what release it will be so we can remove the patch from our provisioning system once we reach that version of asterisk |
| 17:43.10 | mvanbaak | works like a charm |
| 17:43.59 | kaii | oej: what you think about "override calls"? some time ago i extended 1.2-bristuffed (i know ...) to enable override calls ... in that box you can use the dial options "k" and "K" to mark a call as k="you may kill this channel" and K="kill other channels if kill-flag is set" ... in a call waiting = off scenario, they can call extensions even if they ring in a ringgroup/queue there .. |
| 17:44.29 | kaii | would do the same thing in 1.6 and provide patches, if it's not considered "crap" |
| 17:44.30 | oej | Interesting |
| 17:44.39 | oej | But can't you do that already? |
| 17:44.39 | kaii | they really love it. |
| 17:44.43 | kaii | how ? |
| 17:44.57 | oej | You can set a channel variable and check it in other channels, and run softhangup on that channel |
| 17:45.22 | kaii | you mean SHARED() ? |
| 17:45.36 | kaii | well, i dont live in 1.6 ... |
| 17:46.10 | mvanbaak | you should move |
| 17:46.31 | kaii | in 1.2 and 1.4, you cannot check variables of other channels, cant you? and you would have to know the channel identifier in that case |
| 17:46.44 | kaii | would love to realize that without adding code to the source |
| 17:47.21 | kaii | mvanbaak: yes, all our customers should move. i'm not talking about my own single box. |
| 17:47.22 | Corydon76-dig | Inheritance only |
| 17:47.54 | Corydon76-dig | and you can import variables from other channels, you just cannot set them |
| 17:48.20 | Corydon76-dig | Starting in 1.6.3, you'll be able to set variables in the channel originating your channel |
| 17:48.22 | kaii | but i would have to know the channels exact identifier, dont i? |
| 17:48.31 | Corydon76-dig | Yes, you would |
| 17:48.58 | Corydon76-dig | and no, this feature in 1.6.3 is not backportable |
| 17:49.29 | kaii | how could i know? imagine i want to call SIP/100 and it is already in ringing state from a Queue() ... how would i check a variable in that channel SIP/100-XXXXXX (XXXXXX is the unknown part) |
| 17:50.01 | kaii | Corydon76-dig: would never try to backport this .. but i've seen a backport of SHARED in some team svn .. :) |
| 17:50.23 | Corydon76-dig | SHARED() is a different ball of wax |
| 17:50.37 | kaii | ok then i thought wrong direction .. |
| 17:50.56 | mvanbaak | kaii: you can get a list of channels using the CHANNELS() dialplan function |
| 17:51.10 | mvanbaak | kaii: it can optionally filter based on a regex |
| 17:51.28 | kaii | mvanbaak: awesome. sounds like high performance with a few more calls.. |
| 17:51.35 | mvanbaak | so you could use it to find the SIP/100-XXXXX when running CHANNELS with an argument to limit results on SIP/100 |
| 17:51.36 | kaii | ahh ok |
| 17:52.19 | kaii | will never be as fast as setting a channel flag "ALLOW_KILL" and checking this in Dial(), but acceptable. |
| 17:58.02 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 17:59.13 | oej | We're not saying that your suggestion is bad, we're just trying to figure out if it can be easily don, kaii... |
| 18:04.44 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:05.14 | kpfleming | if we were going to implement something like that, it'd have to have some sort of 'group naming' to allow for multi-tenant usage |
| 18:05.25 | kpfleming | and then you get into permissions... ugh |
| 18:06.48 | kaii | sounds like things getting complicated .. |
| 18:07.11 | kpfleming | that's life when you have to build features for general purpose usage instead of a specific case |
| 18:07.32 | kaii | kpfleming: but i do not see why there must be group naming for multi-tenant usage ... doesnt asterisk has Dial options "t" and "w" for transfer and recording? where are the permissions here? |
| 18:07.41 | kaii | they're set using the right context .. |
| 18:07.52 | kpfleming | because they don't affect what other people can do to the channel |
| 18:07.55 | kpfleming | like your idea does |
| 18:08.03 | kaii | mh right |
| 18:08.35 | kaii | you can use one asterisk box with multiple contexts for different companys in the same building ... there are the problems. |
| 18:08.53 | kaii | but nobody is forced to enable that dial option |
| 18:09.09 | kpfleming | right, but it's not nice to add options that can't easily be used in situations like that |
| 18:09.39 | kaii | at least, using DEVICE_STATE() it is possible to "disable call waiting" (knocking) on the server side .. this is a huge step forwards :) |
| 18:11.08 | kaii | adding "override groups" sounds not too complicated to implement .. maybe i will do it some time and provide it for trunk development |
| 18:12.05 | kaii | i see more problem in finding an appropriate Dial() option character that is not already in use :) in a short while the whole alphabet will be used .. |
| 18:13.41 | kaii | thats why i added all my options as parameters to a bogus option "%" in my patches .. so i have my own namespace.. looks like Dial(foo,,twR%(abc)) .. ugly but at least it avoids any conflict when updating the patchset to 1.6 |
| 18:14.44 | *** join/#asterisk-dev Chromis (n=millsu2@mail.serverplus.com) |
| 18:14.48 | kpfleming | that's a neat idea |
| 18:15.03 | kaii | kinda ugly though |
| 18:15.22 | kaii | but k/K is already used in 1.6 |
| 18:15.55 | kaii | same with "o" or any other appropriate abbreviation i could think of |
| 18:16.48 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:18.02 | kaii | have a nice day, time to know off work here |
| 18:54.46 | *** join/#asterisk-dev Dovid (n=annon@ool-4355e297.dyn.optonline.net) |
| 18:58.22 | oej | I guess that the IAX2 RFC is deprecated or at least should be updated by the protocol change. Maybe you should document that specifically in the pdf. |
| 18:58.35 | kpfleming | not realy, no |
| 18:58.44 | kpfleming | this sort of thing happens to RFC protocols all the time |
| 18:58.54 | kpfleming | the existing RFC is completely valid, but has some security concerns |
| 18:59.10 | kpfleming | so there will be a new I-D proposed to add a security extension to the existing protcol |
| 18:59.11 | oej | So we need to publish a new document with the changes |
| 18:59.15 | kpfleming | correct' |
| 18:59.17 | oej | Right |
| 18:59.21 | kpfleming | which is already planned |
| 18:59.29 | oej | Ok then |
| 18:59.45 | kpfleming | in fact, the protocol change text in the pdf is already in I-D format :-) |
| 18:59.59 | Qwell | I-D? |
| 19:00.04 | kpfleming | internet draft |
| 19:00.08 | Qwell | of course |
| 19:11.57 | leifmadsen | in my first round of the draft, I'll take RFCs 2811, 3389, 301, and 3670 |
| 19:13.55 | kpfleming | leifmadsen: lam |
| 19:14.01 | kpfleming | s/lam/lame/ |
| 19:14.50 | leifmadsen | I have that effect |
| 19:16.59 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:17.44 | kpfleming | seanbright: sucks for you |
| 19:18.04 | seanbright | no shit |
| 19:18.12 | seanbright | i'm so pissed right now |
| 19:18.27 | Corydon76-dig | missed something |
| 19:18.32 | kpfleming | facebook post |
| 19:18.36 | kpfleming | cross-social-networking |
| 19:19.16 | seanbright | long story short, the person who was supposed to sign for my new laptop decided to not be there when it was delivered |
| 19:19.27 | file | go get it? |
| 19:19.45 | seanbright | i don't know where it is |
| 19:20.11 | seanbright | it's sitting on a truck right now |
| 19:20.20 | file | it'll be back at the depot this evening though... |
| 19:20.33 | seanbright | i need to figure out which one |
| 19:21.50 | Corydon76-dig | seanbright: beat your chest and holler over the phone |
| 19:22.29 | Corydon76-dig | "Sean want package NOW!!!" |
| 19:23.15 | Corydon76-dig | wonders if that will work |
| 19:24.35 | Corydon76-dig | has probably had too much caffeine today |
| 19:24.48 | leifmadsen | I haven't had nearly enough |
| 19:27.21 | Corydon76-dig | wonders when the interns are going to make their way onto IRC |
| 19:28.17 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 19:33.48 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 19:40.14 | seanbright | package won't be back to the sort until after business hours |
| 19:40.20 | *** join/#asterisk-dev dbailey (n=doug@nat/digium/x-aottwpvpaajjqkxk) |
| 19:40.20 | seanbright | son of a bitch |
| 20:08.58 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 20:14.58 | mvanbaak | is the iax-security.pdf available in other formats ? |
| 20:15.09 | mvanbaak | like txt or something |
| 20:16.34 | kpfleming | it could be |
| 20:16.37 | kpfleming | it's a TeX document |
| 20:17.15 | mvanbaak | did I miss that ? |
| 20:17.22 | mvanbaak | I only saw the .pdf committed |
| 20:17.25 | kpfleming | no, it's not in the branches |
| 20:19.03 | mvanbaak | can you please add a format you can read on a console ? |
| 20:19.54 | kpfleming | russellb: ^^^ |
| 20:21.16 | kpfleming | mvanbaak: pdf2ps IAX2-Security.pdf | less |
| 20:21.45 | russellb | it's just a PDF, from openoffice |
| 20:22.30 | kpfleming | maybe you can make a .txt version and post it in /security with the advisory |
| 20:23.35 | mvanbaak | holy crap, ps is hard to read ! |
| 20:27.49 | russellb | kpfleming: sure. We include PDF and HTML in there for advisories. I'll just post both for that, too. |
| 20:27.55 | kpfleming | great |
| 20:29.15 | mvanbaak | thank you |
| 20:29.46 | mvanbaak | ps2ascii IAX-security.pdf does the trick (more or less, layout it fucked) |
| 20:33.12 | russellb | an HTML version should now be on the downloads site |
| 20:33.16 | russellb | (once it syncs anyway) |
| 20:33.46 | russellb | links2 -dump IAX2-security.html > IAX2-security.txt does a nice job of creating a plain text version |
| 20:38.16 | *** join/#asterisk-dev FlaPer87 (n=FlaPer87@unaffiliated/flaper87) |
| 20:39.03 | FlaPer87 | hy guys, I'm writting an asterisk app and I would like to record a message in a file, con you please give me some advices about how to do this? |
| 20:39.20 | kpfleming | look at the Record() application |
| 20:39.22 | kpfleming | it's very simple |
| 20:39.59 | russellb | i could do it half of a line in python, though |
| 20:40.09 | kpfleming | how many lines of whitespace? |
| 20:40.12 | russellb | lol .. |
| 20:40.20 | russellb | 4.3 |
| 20:40.31 | file | not 800km? |
| 20:40.47 | russellb | same thing |
| 20:41.33 | mvanbaak | russellb: yeah, links -dump is great for that |
| 20:41.43 | mvanbaak | works better then ps2ascii |
| 20:50.01 | mvanbaak | russellb: it's there |
| 20:51.25 | mvanbaak | oh wait, only the AST document |
| 20:51.58 | mvanbaak | ah, and the iax-security.html is there now as well |
| 20:52.02 | mvanbaak | thank you |
| 20:52.08 | russellb | np |
| 20:59.34 | *** join/#asterisk-dev tamiel (n=tamiel@ip-7.net-81-220-254.rev.numericable.fr) |
| 21:00.16 | mvanbaak | ok, if I read and parse this correctly, it only affects systems that allow guest calls and/or have dynamic peers |
| 21:00.42 | kpfleming | nope |
| 21:00.46 | kpfleming | it affects all systems |
| 21:01.13 | russellb | If I can send IAX packets to you _at all_, I can exploit it |
| 21:01.24 | kpfleming | and he will, trust me |
| 21:01.29 | mvanbaak | that's what I mean |
| 21:01.31 | russellb | yup, because that's how I roll |
| 21:01.34 | mvanbaak | with dynamic peers |
| 21:01.52 | kpfleming | you could have guest access turned off, no peers defined at all, absolutely no chan_iax2 configuration whatsoever, and your system is still attackable |
| 21:02.02 | kpfleming | if it's listening, it's vulnerable |
| 21:02.08 | mvanbaak | yeah |
| 21:02.33 | mvanbaak | but if you dont have dynamic peers nor guest access, why would you expose the iax port to the public anywayz ? |
| 21:02.40 | kpfleming | static peers |
| 21:02.46 | kpfleming | only authenticated peers |
| 21:02.48 | kpfleming | why not? |
| 21:02.51 | mvanbaak | yeah, but you firewall them right ? |
| 21:02.55 | kpfleming | doesn't matter |
| 21:02.56 | mvanbaak | only allow known ip's |
| 21:02.58 | kpfleming | IPs can be spoofed |
| 21:03.07 | kpfleming | that's the crux of this attack |
| 21:03.24 | mvanbaak | not that easily |
| 21:03.31 | kpfleming | trivially easily |
| 21:03.37 | russellb | the fix was, 1) make sure we know who is talking to us, and then 2) limit resource consumption per source |
| 21:04.13 | kpfleming | if i can send you UDP, i can use any source IP address i want |
| 21:04.27 | kpfleming | if it happens to be one you trust, you'll let the packet in |
| 21:04.53 | kpfleming | if your routers/edge devices do reverse-route analysis, you'll have less of a problem |
| 21:05.03 | kpfleming | but you're still vulnerable to the endpoints you 'trust' |
| 21:05.07 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) |
| 21:05.23 | mvanbaak | there are still routers that dont do it ? |
| 21:05.26 | kpfleming | tons |
| 21:05.36 | mvanbaak | sad |
| 21:05.37 | kpfleming | everyone who has their system on a DSL/cable connection |
| 21:05.49 | mvanbaak | that is _not_ true |
| 21:05.57 | kpfleming | everyone whose box is in a colo with 100K other boxes all on the same upstream link |
| 21:06.14 | mvanbaak | hhmm, must be true in the .us |
| 21:06.38 | mvanbaak | we actually have companies with a clue here. they do the network setup as they should |
| 21:06.44 | kpfleming | reverse-route filtering has to be done close to the injection point... it can't be done at the destination |
| 21:06.53 | mvanbaak | I know |
| 21:06.57 | mvanbaak | my dsl provider is doing it |
| 21:07.01 | mvanbaak | and my colo provider as well |
| 21:07.23 | putnopvut | Um, so here's something a bit strange. |
| 21:07.24 | kpfleming | how? they have upstreams, if the packet arrives from upstream #1 and replies would go back to upstream #1, they have to accept it |
| 21:07.30 | kpfleming | and upstream #1 could be all of .us |
| 21:07.33 | putnopvut | I am having weird compiler errors while trying to compile the CCSS branch. |
| 21:07.50 | putnopvut | And, without changing any files, I can sometimes make two different sets of compiler errors appear. |
| 21:07.51 | russellb | putnopvut: missing/extra/backwards curly brace is my bet. |
| 21:08.07 | kpfleming | that does sound strange |
| 21:08.28 | russellb | Corydon76-dig: ping? |
| 21:08.42 | mvanbaak | kpfleming: that's what peering contracts are for. |
| 21:08.58 | kpfleming | how does that help? |
| 21:09.19 | mvanbaak | well, you can regulate that all members in a pool do it |
| 21:09.33 | kpfleming | but it doesn't help |
| 21:09.39 | putnopvut | I'll go my usual pastebin route to show the errors I'm seeing. |
| 21:09.45 | kpfleming | let's say you have a peer you trust on an ARIN-assigned IP address, ok? |
| 21:10.01 | mvanbaak | uhhuh |
| 21:10.12 | kpfleming | and that IP address happens to be routed to Level3 at the moment |
| 21:10.49 | kpfleming | that means anyone connected to level3 can send you a packet spoofed with that trusted peer's IP |
| 21:11.04 | kpfleming | and anyone connected to your other peers who could transit to level3 could as well, unless you disallow transit |
| 21:11.12 | mvanbaak | unless level3 does the same checking |
| 21:11.23 | kpfleming | right... but this does not happne. |
| 21:11.33 | mvanbaak | I know |
| 21:11.36 | kpfleming | in general, ISPs do not do reverse route filtering at their ingress points |
| 21:11.38 | mvanbaak | and that's sad |
| 21:11.41 | kpfleming | yes it is |
| 21:11.51 | kpfleming | but... it leads to our current issues |
| 21:11.56 | mvanbaak | yup |
| 21:12.01 | mvanbaak | and I'm glad you fixed it |
| 21:12.09 | kpfleming | we are too |
| 21:12.11 | mvanbaak | now all I have to do is backport it to 1.0.9 |
| 21:12.14 | kpfleming | it was hard, long and painful |
| 21:12.18 | putnopvut | Actually I'm going to mess around here a bit more before I give up and defer to -dev with this one. |
| 21:12.45 | mvanbaak | we still have some border IAX2 boxen running that |
| 21:12.57 | kpfleming | and it consumed tons of man-hours that could have been better spent actually improving asterisk :-( |
| 21:13.48 | kpfleming | but spoofability was only part of the problem... if you trusted someone, they could take down your system quite easily, and there were no settings to allow to you stop it |
| 21:14.29 | russellb | We spent 834570298374912347 hours trying to come up with a backwards compatible solution ... |
| 21:14.39 | russellb | and eventually realized one didn't exist, heh. |
| 21:15.29 | mvanbaak | gheh |
| 21:15.34 | mvanbaak | happens from time to time |
| 21:16.51 | mvanbaak | damn, I'm really suprised by the fact not all ISP's do reverse-route filtering |
| 21:17.29 | kpfleming | at the network edges it's ridiculously cheap to implement |
| 21:17.38 | kpfleming | if all the edges had it, none of the core would have to |
| 21:17.45 | mvanbaak | indeed |
| 21:18.29 | mvanbaak | that's what I remember from the classes |
| 21:20.18 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.233.173) |
| 21:20.26 | Marquis42 | The problem is everybody still thinks edge router horsepower is at a premium, when it just isn't. That may have been true when the edges were all Cisco 2501s or similar, but not so much anymore. |
| 21:21.09 | kpfleming | well, and line cards have plenty of horsepower to drop incoming IP packets that don't belong to the subnet(s) on that line |
| 21:21.37 | ZX81 | hi all, any idea when the new releases for the IAX2 bug will be? |
| 21:21.41 | Marquis42 | Very much so |
| 21:21.42 | kpfleming | any moment |
| 21:21.47 | ZX81 | kewl |
| 21:22.20 | mvanbaak | kpfleming: that's why OpenBSD has this by default in their pf setup: antispoof on $ext_if |
| 21:22.45 | kpfleming | sure, that protects your internal networks from spoofing by external ones |
| 21:22.55 | kpfleming | linux has the same thing, usually on by default |
| 21:23.34 | kpfleming | i suppose it keeps people behind that box from being able to spoof outwards too, which is good |
| 21:23.41 | mvanbaak | yup |
| 21:23.52 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 21:23.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:23.53 | mvanbaak | and it works on non-natting boxen as well |
| 21:23.58 | kpfleming | yes |
| 21:24.06 | mvanbaak | you can use OpenBSD as router as well, and pf is still working |
| 21:24.32 | mvanbaak | $ext_if is just the interface that talks to machines you 'dont trust' |
| 21:25.04 | mvanbaak | on a routing box I add more interfaces to that rule |
| 21:25.13 | mvanbaak | basically, all interfaces in the system |
| 21:32.33 | mvanbaak | meh, the patch works :) |
| 22:00.18 | Corydon76-dig | russellb: pong |
| 22:00.34 | russellb | Corydon76-dig: I just had a question about testing sendast |
| 22:00.45 | russellb | wanted to make sure it's just a 2nd non-empty arg |
| 22:01.13 | russellb | my perl foo is weak :-) |
| 22:01.16 | *** join/#asterisk-dev xpot-mobile (n=james@mx0.synergyconsultant.net) |
| 22:02.35 | Corydon76-dig | russellb: yes, that's correct |
| 22:03.12 | russellb | okay, great. thank ya |
| 23:01.03 | *** join/#asterisk-dev bkruse (n=Administ@76.73.154.120) |
| 23:01.03 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 23:53.11 | *** join/#asterisk-dev obnauticus (n=l@about/windows/regular/obnauticus) |