| 00:26.57 | *** join/#asterisk-dev suneye (~atcmmi@119.122.152.56) |
| 02:31.10 | *** join/#asterisk-dev atcmmi (~atcmmi@121.34.41.118) |
| 02:53.47 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 02:58.14 | *** join/#asterisk-dev suneye (~atcmmi@121.34.41.118) |
| 02:59.35 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 05:03.33 | *** join/#asterisk-dev suneye (~atcmmi@121.34.41.118) |
| 05:03.33 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 05:03.33 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 05:03.33 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 05:03.33 | *** mode/#asterisk-dev [+o opticron] by leguin.freenode.net |
| 05:20.20 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 05:58.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 05:58.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:01.09 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 10:15.08 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 10:15.08 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 10:49.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 10:49.19 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:30.22 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:08.05 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 12:17.44 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:56.05 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ydrkhrsrhgqsavpf) |
| 13:21.39 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-kafaadvbfowokmdq) |
| 13:48.25 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ehehzkeecrgmwkxq) |
| 13:48.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:52.36 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-lfggvzryncjdgkvi) |
| 14:02.50 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:37.30 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:37.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:46.45 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:46.45 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:47.45 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:47.45 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:48.11 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 14:53.38 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 15:22.00 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 16:02.20 | *** part/#asterisk-dev leedm777 (~leedm777@nat/digium/x-kafaadvbfowokmdq) |
| 16:08.24 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-kafaadvbfowokmdq) |
| 16:18.15 | file | nudges seanbright |
| 16:24.35 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 16:39.19 | file | leedm777, my thinking re: my playback comment was queueing with announcements |
| 16:40.26 | leedm777 | file: yeah. for that, having a play-this-now-and-then-go-back-to-what-you-were-doing parameter would be useful. |
| 16:40.37 | file | leedm777, yup |
| 16:40.38 | leedm777 | although we might want a shorter name |
| 16:41.33 | leedm777 | Actually, that should be very doable. |
| 16:42.29 | file | leedm777, also - since it's async wouldn't cancelling the queue also make it possible for some part of the file to slip out? |
| 16:43.04 | leedm777 | file: not if you start canceling from the most recent playback to the oldest. |
| 16:43.45 | leedm777 | The cancellation itself is synchronous. |
| 16:45.37 | file | sure but if I cancel the head it'll start playing the next file, aye? |
| 16:45.45 | leedm777 | aye |
| 16:46.09 | file | and I then cancel that file, but it will have started playing |
| 16:46.20 | leedm777 | also true. |
| 16:46.30 | leedm777 | which is why you should cancel that second one first. |
| 16:46.42 | file | ah tail |
| 16:46.43 | file | aye aye |
| 16:47.01 | leedm777 | gotta run. bbiab |
| 16:47.02 | file | methinks the ability to do this should exist earlier instead of later |
| 16:47.05 | file | k |
| 16:53.20 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:55.41 | file | kharwell, before you go down the road of adding code it would be nifty to see your approach generally written up re: alwaysauthreject since it's important |
| 16:56.20 | putnopvut | file: I think kharwell wanted to get together with me to talk about it some. We could do that here so you (and anyone else) can follow along |
| 16:56.32 | file | that would be nifty |
| 16:58.19 | kharwell | file, putnopvut: sounds good to me |
| 16:59.25 | putnopvut | kharwell: whenever you get to a point where you want to start discussing that stuff, just ping us in here. |
| 17:00.15 | kharwell | okay will do |
| 17:49.13 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:49.17 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:49.23 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:58.07 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 17:58.44 | jmls | hey guys. Sorry couldn't get to comment on ASTERISK-21374 |
| 17:58.45 | LieutPants | [ASTERISK-21374] [Status: Closed] [Assigned: elguero] [patch] One-way Audio With auto_* NAT Settings When SIP Calls Initiated By PBX - https://issues.asterisk.org/jira/browse/ASTERISK-21374 |
| 17:59.05 | jmls | was dealing with family bereavement overseas |
| 17:59.10 | jmls | apologies again |
| 18:15.07 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:34.23 | *** join/#asterisk-dev asilva (~asilva@gandalf.ai.unesp.br) |
| 18:39.17 | seanbright | is nudged by file |
| 18:41.13 | file | seanbright, :D |
| 18:44.35 | kharwell | putnopvut, file: ready to talk alwaysauthreject when you guys are |
| 18:44.53 | putnopvut | seanbright: woot on the review. |
| 18:44.55 | file | launch the barrage |
| 18:45.00 | putnopvut | kharwell: okay, sounds good. |
| 18:46.38 | mjordan | zomg w/ tests |
| 18:46.46 | putnopvut | no kidding |
| 18:46.57 | mjordan | I might just have to like, I don't know, crack a beer or something |
| 18:47.13 | putnopvut | please drink it |
| 18:47.19 | mjordan | we have a snom somewhere, don't we? |
| 18:47.35 | putnopvut | I used to have two 720s on my desk, but I don't know where they ended up. |
| 18:48.35 | mjordan | I blame .... jrose_atDigium |
| 18:48.54 | jrose_atDigium | ? |
| 18:49.09 | file | I vaguely remember one behind me in the office I grabbed my last visit |
| 18:49.33 | mjordan | jrose_atDigium: no logic or reasoning. |
| 18:49.38 | mjordan | I just picked you at random |
| 18:50.09 | jrose_atDigium | ! |
| 18:52.08 | kharwell | file, putnopvut: I guess for starters it sounds like there should be a new res_sip_security module that will contain/handle the alwaysauthreject stuff, tying in with the acl module. I guess if it gets rejected by acl how will it notify the authreject module so it can transmit a fake auth response? |
| 18:52.55 | file | I think you can't get away with making it a separate module like that, it has to be ingrained in the auth related stuff |
| 18:53.43 | kharwell | that's what I thought. so does it make sense to add this to acl or create a new security mod with acl in it? |
| 18:54.16 | putnopvut | file and I have discussed this a couple of times before and have a rough outline of an approach to take. |
| 18:54.24 | file | this isn't related to acl, really |
| 18:54.47 | putnopvut | So right now, the issue is that if no endpoint identifier recognizes who the message is from, we immediately send a 403. That needs not to happen with alwaysauthreject enabled. |
| 18:55.15 | putnopvut | So instead of immediately sending a 403, the idea is instead to use a "dummy" endpoint and pass that up to the auth layer. |
| 18:55.38 | putnopvut | The dummy endpoint is configured in such a way as to require authentication, but never actually be able to authenticate properly. |
| 18:56.09 | putnopvut | So when the authenticator will just attempt to authenticate, using 401 responses, but the endpoint can never actually authenticate properly. |
| 18:56.25 | putnopvut | There are a couple of problems with this approach, though, but they shouldn't be too difficult to iron out. |
| 18:56.33 | kharwell | aah I see now. I was thinking about it wrong. |
| 18:57.13 | putnopvut | The biggest problem is that it requires that an authenticator module be registered. Right now, if no authenticator is registered, we'll just assume that no authentication is required and let the message pass up into the application layer. |
| 18:57.51 | putnopvut | So if someone were to turn alwaysauthreject on and not have an authenticator loaded (which would be silly, btw) then the approach would result in the dummy endpoint always reaching application code. |
| 18:58.28 | file | yeah, I think you can't get away from a hard coding of if endpoint == dummy somewhere |
| 19:00.24 | putnopvut | It's not required that that approach be taken. You could just have something in the endpoint identifier module that sends some sort of pre-fabricated 401 response if no endpoint is identified and alwaysauthreject is enabled. |
| 19:01.28 | putnopvut | The first approach was thought of because 1) The use of dummy endpoints may be useful for other reasons and 2) The authentication challenges sent would be more ... genuine(?) in that they would actually be made by a real authenticator trying to challenge. |
| 19:01.50 | file | they should be genuine |
| 19:02.03 | file | because if they aren't and you can notice that, then that defeats the purpose |
| 19:02.13 | putnopvut | Yep |
| 19:03.01 | file | kharwell, this is all done so that a scanner can't know if the account they are trying is a real configured account or not |
| 19:04.26 | kharwell | right |
| 19:06.52 | kharwell | so the first approach sounds good, I guess I will start with that in mind |
| 19:06.59 | file | kk |
| 19:16.22 | seanbright | post-review sucks so bad |
| 19:17.42 | mjordan | Yes. Yes it does. |
| 19:18.06 | mjordan | we're working on that, but we hit a snag last week and the 'hopefully this fixes it' solution has a bit of a longer timetable |
| 19:20.33 | seanbright | just need to put a wrapper around it |
| 19:20.40 | seanbright | so that it keeps trying until it succeeds |
| 19:20.47 | seanbright | on my side, that is. |
| 19:25.10 | mjordan | heh |
| 19:25.18 | mjordan | I've been known to loop it. Which is sad. |
| 19:29.05 | file | I just use diffs, it works, plus I have backups of all iterations locally too plus SVN plus reviewboard |
| 19:29.27 | pabelanger | what ever happened to the git migration? |
| 19:29.34 | pabelanger | there was some steam a few months ago |
| 19:31.18 | mjordan | there was discussion, but we haven't started any migration |
| 19:31.50 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:31.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:32.19 | file | It'll happen though |
| 20:05.20 | file | Hey putnopvut! |
| 20:05.57 | file | I have been giving thought to the annoying one event name to rule them all in pjsip and I think we can work around it |
| 20:06.53 | file | (Where you can only register an event once with types) |
| 20:08.05 | mjordan | file: orly |
| 20:08.51 | file | Yes. They all flow through the pub sub module regardless so really the only issue is the accept types which are only used in the header |
| 20:09.30 | file | If we attach the header ourselves then we can manage the accept types ourselves |
| 20:10.50 | file | That bypasses the restriction within pjsip evsub |
| 20:14.34 | file | The sun is burning me. |
| 20:17.13 | putnopvut | file: interesting, so on an incoming SUBSCRIBE, the evsub module doesn't actually pay attention to the accept header? |
| 20:17.32 | file | It does not appear to from my reading if I remember right |
| 20:17.40 | putnopvut | takes a look |
| 20:18.20 | putnopvut | Actually, I guess you're right. On an initial SUBSCRIBE, the evsub module is not called into at all. It's really a matter of re-subscribes... |
| 20:19.28 | file | You can attach custom headers... So those must be preserved... Could use that |
| 20:20.17 | kharwell | file, putnopvut: does it make sense to have a separate module that checks for a null endpoint on the incoming request, if so create/set a dummy one? or have the distributor create one if not found during lookup? |
| 20:21.43 | file | I suppose it could be a module but I think it should be part of the core modulea |
| 20:21.55 | file | Or modules |
| 20:22.12 | kharwell | yeah I was just thinking if the module didn't get loaded then what. |
| 20:22.37 | file | So IMO distributor |
| 20:29.04 | putnopvut | Yes, I agree with file. It's a better idea to modify code in sip_distributor.c. |
| 21:00.04 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:00.04 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 22:08.11 | file | my thoughts appear to be correct |
| 22:08.47 | mjordan | my thoughts appear to be sideways |
| 22:09.25 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 22:29.55 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:29.55 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:43.18 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 23:27.06 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ehehzkeecrgmwkxq) |
| 23:32.19 | *** part/#asterisk-dev jmls (~julian@77.107.171.82) |