| 01:23.45 | *** join/#asterisk-dev opticron (~opticron@75.76.59.35) |
| 01:23.45 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 01:23.48 | *** join/#asterisk-dev _skrusty (~skrusty@88.150.145.104) |
| 01:23.48 | *** mode/#asterisk-dev [+o _skrusty] by ChanServ |
| 01:35.50 | *** join/#asterisk-dev file (uid178970@asterisk/developer-and-muffin-lover/file) |
| 01:35.50 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 02:37.01 | *** join/#asterisk-dev KaliLinuxGR (~KaliLinux@unaffiliated/kalilinuxgr) |
| 02:39.05 | *** join/#asterisk-dev KaliLinuxGR (~KaliLinux@unaffiliated/kalilinuxgr) |
| 03:00.37 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 03:00.37 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 06:58.22 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:59.37 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:19.02 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:03.13 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:06.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:09.32 | *** join/#asterisk-dev matsk (~matsk@vpnbl.borderlight.net) |
| 08:21.36 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::da1) |
| 08:56.20 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:13.51 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 10:35.41 | *** join/#asterisk-dev KaliLinuxGR (~KaliLinux@unaffiliated/kalilinuxgr) |
| 12:34.56 | *** join/#asterisk-dev KaliLinuxGR (~KaliLinux@unaffiliated/kalilinuxgr) |
| 13:05.29 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 13:13.17 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 13:13.17 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 13:47.51 | *** join/#asterisk-dev snuff-work (~snuff-wor@203.87.61.22) |
| 13:47.51 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:32.48 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mxmkbqzpyhsutiek) |
| 14:32.49 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:49.09 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 14:56.59 | *** join/#asterisk-dev oej (~oej@178-78-201-42.customers.ownit.se) |
| 14:56.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:00.10 | *** join/#asterisk-dev oej (~oej@178.78.201.42) |
| 15:00.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:00.17 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 15:04.37 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-axppakzwivnpgdyb) |
| 15:04.37 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:19.28 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-vhbngjmatwjqlaix) |
| 15:19.28 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:26.16 | *** join/#asterisk-dev scgm11_ (~nobody@ec2-52-207-226-93.compute-1.amazonaws.com) |
| 15:35.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:35.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:36.16 | file | cresl1n! |
| 15:39.33 | cresl1n | file!!!!!!!!!! |
| 15:39.38 | *** part/#asterisk-dev scgm11_ (~nobody@ec2-52-207-226-93.compute-1.amazonaws.com) |
| 15:40.32 | *** join/#asterisk-dev scgm11_ (~nobody@ec2-52-207-226-93.compute-1.amazonaws.com) |
| 15:40.43 | cresl1n | So file... |
| 15:40.53 | *** part/#asterisk-dev scgm11_ (~nobody@ec2-52-207-226-93.compute-1.amazonaws.com) |
| 15:41.05 | cresl1n | Can I ask some questions to get inside that great big brain of yours? |
| 15:41.08 | file | maybe |
| 15:41.27 | cresl1n | :-P |
| 15:41.28 | cresl1n | https://gerrit.asterisk.org/#/c/4701/1 |
| 15:41.54 | cresl1n | So do we set the optimistic flag if we detect at crypto line? |
| 15:42.40 | cresl1n | looks like we do |
| 15:43.19 | cresl1n | So your response that in addition to detecting the fingerprint line, he needs to verify that it's set to UDP/TLS/RTP/SAVPF as well? |
| 15:43.26 | file | no |
| 15:43.32 | file | I was referring to an offer |
| 15:43.35 | file | that is: an outgoing call |
| 15:43.39 | file | if optimistic is on then it should be RTP/AVP |
| 15:43.51 | cresl1n | Oh intersting |
| 15:43.55 | cresl1n | let me read that code some more |
| 15:43.59 | cresl1n | I didn't check context enough |
| 15:44.44 | file | the specific code in question is for determining if an SDP from the remote side is optimistic |
| 15:45.09 | file | if it's not the right transport type and it has crypto (or fingerprint in the case of DTLS) then it is optimistic |
| 15:45.33 | cresl1n | Ok |
| 15:46.09 | cresl1n | So that's what I was assuming - that that code executes on an inbound offer |
| 15:46.37 | cresl1n | inbound to asterisk |
| 15:46.53 | file | yup yup |
| 15:47.59 | cresl1n | So what's this business you're talking about with an outgoing call (and an outbound offer)? |
| 15:48.48 | file | if you turn on optimistic and do DTLS, the offer isn't optimistic |
| 15:49.28 | cresl1n | maybe he was talking about optimistic inbound? |
| 15:49.35 | cresl1n | not optimistic from an outbound perspective |
| 15:49.41 | file | that is what his change implements |
| 15:49.53 | cresl1n | optimistic outbound? |
| 15:50.04 | file | no, support for optimistic DTLS on an inbound offer |
| 15:50.21 | cresl1n | yeah, that's what I was getting too |
| 15:50.24 | cresl1n | so what's the problem? |
| 15:50.36 | file | that he's only half implemented it? |
| 15:50.45 | file | DTLS was never supported for optimistic, only SDES |
| 15:51.07 | file | the specification didn't exist to say that it should, well, exist - but it now does |
| 15:51.24 | cresl1n | I'm totally confused now |
| 15:51.31 | cresl1n | so which half didn't he implement? |
| 15:51.39 | file | outbound |
| 15:51.48 | cresl1n | OH |
| 15:51.50 | cresl1n | gotcha |
| 15:51.51 | file | if I send an INVITE with DTLS and optimistic on, it's not optimistic |
| 15:51.53 | cresl1n | soâ¦.. |
| 15:52.02 | cresl1n | is that a big deal though? |
| 15:52.16 | cresl1n | inbound optimistic is a big start, no? |
| 15:52.21 | cresl1n | well, not big start |
| 15:52.26 | cresl1n | but seemingly separable |
| 15:52.32 | cresl1n | I agree about the testing, btw |
| 15:52.34 | file | it's something - but should we really accept something that only implements half of it? |
| 15:52.53 | file | if we're going to support optimistic DTLS then that means both inbound and outbound imo |
| 15:54.44 | cresl1n | I guess my opinion (as a developer) is that if it works for one direction that's a separable portion of the work. I guess we can see if he wants to do the outbound side too though |
| 15:55.07 | file | and as a user? that's rather conflicting behavior :D |
| 15:55.24 | file | (there is an explicit option for optimistic you have to turn on) |
| 15:55.44 | cresl1n | maybe that's the angle I'm disregarding |
| 15:56.37 | cresl1n | discuss after standup? |
| 15:56.42 | file | sure |
| 16:15.33 | file | the future is now |
| 16:17.05 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-dfhnwdzjdctkrzpu) |
| 16:17.05 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:18.38 | cresl1n | So file⦠|
| 16:18.43 | cresl1n | the future *is* now. |
| 16:18.46 | file | hello! |
| 16:20.47 | cresl1n | So, it seems to me that we should always be optimistic on inbound, no? |
| 16:20.57 | cresl1n | Crud |
| 16:21.04 | cresl1n | this is encryption though |
| 16:21.13 | cresl1n | well yeah |
| 16:21.20 | cresl1n | so optimistic on inbound is a good thing |
| 16:21.29 | file | you still need an option |
| 16:21.36 | cresl1n | good protocol stacks are: tolerant on one they receive, and strict on what they send out |
| 16:21.42 | cresl1n | s/one/what/ |
| 16:21.50 | file | ie: I want to REQUIRE encryption |
| 16:22.12 | file | which is what you can do now with encryption on, and optimistic off |
| 16:23.35 | cresl1n | That doesn't seem consistent though with the line above it though |
| 16:23.37 | cresl1n | } else if (media_stream_has_crypto(stream)) { |
| 16:23.38 | cresl1n | *optimistic = 1; |
| 16:23.38 | cresl1n | return AST_SIP_MEDIA_ENCRYPT_SDES; |
| 16:23.45 | cresl1n | which already exists, no? |
| 16:24.01 | file | I don't understand what you mean |
| 16:24.11 | cresl1n | I'm probably misunderstanding what you're saying :-) |
| 16:24.13 | file | that function just determines what crypto is in use, and if it is an optimistic or not |
| 16:24.14 | cresl1n | thanks for being patient |
| 16:24.20 | file | the logic which enforces the configuration is elsewhere |
| 16:24.22 | cresl1n | cool |
| 16:25.20 | file | specifically check_endpoint_media_transport |
| 16:25.56 | cresl1n | let me go grok that funciton |
| 16:27.35 | file | noms lunch |
| 16:30.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 16:30.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:46.36 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 16:46.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:50.35 | cresl1n | file: question 2 |
| 16:50.39 | cresl1n | on https://gerrit.asterisk.org/#/c/4699/3 |
| 16:50.58 | file | what what oh |
| 16:51.14 | cresl1n | Should srv_lookups default to "no" on release branches? |
| 16:51.19 | cresl1n | principle of least surprise and all that? |
| 16:51.32 | cresl1n | I'd be ok with defaulting to yes on master |
| 16:51.42 | cresl1n | but 13 and 14, this could cause behavior changes for people |
| 16:51.47 | cresl1n | what do you think? |
| 16:51.51 | file | only better behavior |
| 16:51.55 | file | :D |
| 16:51.57 | cresl1n | heh |
| 16:52.01 | cresl1n | I like how you put that :-) |
| 16:52.41 | cresl1n | I accept what you say based on your vastly greater experience than my own |
| 16:52.51 | cresl1n | :-P |
| 16:53.49 | file | you're no fun |
| 16:54.18 | cresl1n | <ââ Just some guy trying to learn |
| 16:54.19 | file | I'm a bit iffy myself - I leaned towards yes because it'll improve the experience for people, and we don't have an option for on/off for SRV - people just expect it to work (or don't know and it just works in the background) |
| 16:54.54 | cresl1n | If it there's no potential negative behavior, I say leave it on by default |
| 16:55.06 | cresl1n | and that's what I was interpreting your response as |
| 16:55.13 | file | seems to be very pro-user today |
| 16:55.18 | cresl1n | "only better behavior" |
| 16:55.32 | gtjoseph | the potential negative behavior is that there are now extra lookups being done that weren't before |
| 16:55.34 | cresl1n | file: nothing wrong with being pro user |
| 16:55.47 | gtjoseph | but since file added the option to disable it |
| 16:55.56 | cresl1n | gtjoseph: which seems almost 'meh'-ish to me |
| 16:55.58 | gtjoseph | i'm thinking ity's ok |
| 16:56.05 | gtjoseph | why? |
| 16:57.02 | cresl1n | oh, well, it seems like there'd be so many dns lookups involved in sip processing and call creation anyway that... |
| 16:57.11 | cresl1n | unless I'm wrong in my assumption |
| 16:57.18 | cresl1n | that's where the 'meh' was from |
| 16:57.31 | file | that's a complicated statement |
| 16:57.34 | gtjoseph | maybe but we shouldn't add to the proliferation unnecessarily |
| 16:57.51 | cresl1n | yeah |
| 16:57.56 | cresl1n | but this is one that I don't know how to get out of |
| 16:58.09 | cresl1n | and you can disable the behavior too, right? |
| 16:58.18 | gtjoseph | correct. that was my point. |
| 16:58.28 | cresl1n | oyes. |
| 16:58.29 | cresl1n | :-) |
| 16:58.30 | cresl1n | sorry |
| 16:58.32 | gtjoseph | file added the option to enable/disable |
| 16:58.51 | cresl1n | if nobody's opposed, I'm about to +2 them |
| 16:59.00 | file | I'm pro-gerrit |
| 16:59.36 | cresl1n | what does that even mean? :-P |
| 16:59.51 | file | I'm pro review and merging |
| 16:59.52 | cresl1n | file: i.e. you want me to leave them up longer? |
| 17:00.06 | file | no? |
| 17:00.09 | cresl1n | cool |
| 17:00.10 | file | stop reading too far into things! |
| 17:00.18 | cresl1n | heh |
| 17:01.04 | cresl1n | lot of missing information in text communication |
| 17:05.46 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 17:05.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:31.24 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 18:18.37 | *** join/#asterisk-dev oej (~oej@87.96.134.129) |
| 18:18.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:24.17 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-vqbxqebxialdxqmr) |
| 20:24.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:39.41 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 20:39.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:05.57 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rbafdrzxhldvuepp) |
| 21:05.57 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:53.17 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 22:23.38 | *** join/#asterisk-dev sgriepentrog (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 22:44.45 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 22:44.45 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 23:42.41 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 23:42.41 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |