| 05:33.07 | jkroon | seanbright, file - and pjsip uses getifaddrs underlying as preferred mechanism, so we won't be more broken on bsd that what's currently the case (bsd's getifaddrs only returns max one IP address per interface, so either a v4 or v6 address, and I don't think we can know/predict which) |
| 05:34.19 | jkroon | it's also the only mechanism that handles IPv6 sensibly other than the "we jut retrieve the default route and use that" mechanism. |
| 05:38.55 | jkroon | and by implementing in-asterisk we can avoid at least a handful of pointless system calls (quick count looks like getifaddrs even on my laptop generates around 8 system calls). |
| 06:47.52 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:51.42 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.119) |
| 06:59.44 | *** join/#asterisk-dev pchero_work (~pchero@109.38.134.41) |
| 07:14.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:31.35 | jkroon | file, seanbright - right, so pjsip seems to ignore any addresses assigned to lo device ... this may in some cases be a really bad idea. consider a setup where I'm assigning a public /32 onto lo, and my link addresses are private, with routing set up to use the public from lo ... |
| 07:32.59 | jkroon | should I follow suite and do the same, or should I rather add an implicit blacklist on 127.0.0.0/8, 0.0.0.0/8 and ::1/128 ? |
| 07:37.49 | jkroon | (pjsip simply states "Ignore 0.0.0.0/8 address. This is a special address which doesn't seem to have practical use." - a more complete definition is "This host on this network", RFC1122 makes this look similar to fe08::/16 from v6 (ie, link-local, but restrictions are super crazy, so I'd keep this filter) |
| 08:39.12 | jkroon | on a different front ... what's the recommended way of initializing an ast_sockaddr from a sockaddr struct? |
| 09:08.27 | jkroon | ther eis ast_sockaddr_from_sin ... but it only handles AF_INET ... not AF_INET6 at all ... and I can't find a more generic version that doesn't care about AF_* |
| 12:20.01 | AsteriskRoss | Hey, has anyone seen this before: ERROR[179569][C-00016048]: chan_pjsip.c:632 chan_pjsip_answer: Can't increase the session reference counter |
| 13:00.31 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.107) |
| 13:53.10 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 13:58.55 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:53.07 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-jhbkipvffmogeilg) |
| 14:53.07 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:19.37 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-wclthneldmlmfcbl) |
| 15:19.37 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:23.03 | jkroon | file, you around? |
| 15:23.25 | file | yes |
| 15:23.39 | jkroon | i think I've mostly managed to sort out the initial workings of this whole thing, but the STUN portion is getting at me, and I'm afraid unless I understand the intent of that code I'm going to inadvertantly end up changing logic ... |
| 15:24.01 | jkroon | rtp_add_candidates_to_ice ONLY gets called for PJSIP if I'm not mistaken. |
| 15:24.23 | file | ICE is also available on chan_sip |
| 15:24.35 | jkroon | so from the line "if (count && stunaddr.sin_addr.s_addr && ...) " ... I'm completely stumped. |
| 15:24.41 | jkroon | oh? wasn't aware of that ... interesting. |
| 15:24.55 | jkroon | but obviously ICE support requires pjproject :). |
| 15:25.02 | file | yes. |
| 15:25.16 | file | it uses a STUN client to discover the external IP address and port |
| 15:26.05 | jkroon | ok, so i see you've got a loop there comparing addresses to stuff we've already iterated through locally, and then filters the response if it's already loaded as an ICE candidate? |
| 15:26.40 | file | probably? |
| 15:27.05 | jkroon | what is srflx? |
| 15:27.15 | file | server reflexive, it's part of ICE |
| 15:27.34 | file | it is a candidate discovered as a result of STUN |
| 15:29.49 | jkroon | ok, so in the stun code, the candidate retrieved by stun gets added if (and only if) srflx ends up being true, which it will be unless it's one of the addresses we already added via ast_rtp_ice_add_cand. |
| 15:29.57 | file | yes. |
| 15:30.18 | file | having a host candidate and a server reflexive for the same thing is redundant and silly, so it doesn't |
| 15:30.20 | jkroon | that function (if I'm not mistaken) already filters duplicates. |
| 15:30.39 | jkroon | so is it really required to filter those from the outer function already? |
| 15:31.05 | file | it doesn't filter to the same degree |
| 15:31.13 | file | it filters based on all attributes of a candidate, including type |
| 15:31.39 | file | the type and other aspects would be equivalent, so it would not prevent the addition of the server reflexive |
| 15:31.41 | jkroon | so the outer does a more comprehensive filtering ... |
| 15:32.00 | file | I was referring to rtp_ice_add_cand and it's operation |
| 15:32.17 | file | comparison function being ice_candidate_cmp |
| 15:32.44 | jkroon | so we need to retain the filtering in rtp_add_candidates_to_ice ... ? |
| 15:32.58 | file | yes |
| 15:33.35 | jkroon | ok, i see the inner will only match if everything matches exactly, whereas for the outer we only match on address. |
| 15:35.22 | jkroon | if I were to add ice_candidate_cmp_addronly as a comparitor func which only looks at ->address, that should work right? compare against list of added, barring of course that the address returned from STUN is ice blacklisted ... so check the BL, then add if not already added (by address comparison only)? |
| 15:35.29 | jkroon | s/BL/ACL/ |
| 15:36.04 | file | you could... I'm not really sure what value that would |
| 15:38.11 | jkroon | trying to maintain working of current STUN code to be "exactly as is" without having to store a list of added addresses as per the old addresses array (which I no longer maintain since I really don't need it up to now) |
| 15:38.45 | jkroon | and since the candidates are already added at this stage, and we thus have a list of those addresses in candidates, I'm trying to re-use the list rather than maintaining a secondary one. |
| 15:38.51 | file | then yes. |
| 15:39.22 | jkroon | basically: i'm trying to fix my rather insane use-case with more than 32 addresses assigned on the host without breaking things for anybody else. |
| 15:42.38 | jkroon | ok, i note the cmp function is assigned at list creation time, is it possible to use an alternate cmp function when calling (alternate to) ao2_find? |
| 15:43.04 | jkroon | or should I just iterate the entire container by hand? |
| 15:43.13 | jkroon | (easy enough, we effectively do it currently anyway) |
| 15:44.06 | jkroon | possible optimization, all invocations of ast_rtp_ice_add_cand that I can locate pass base_addr and rel_addr as the same pointer ... which basically ends up setting the port of base_addr to the port of rel_addr ... that seems somewhat inefficient? |
| 15:48.19 | file | you can't use an alternate when calling ao2_find |
| 15:48.24 | file | you have to use ao2_callback |
| 15:48.39 | file | and I don't know |
| 15:48.47 | file | I'd hesitate to alter any code needlessly just because |
| 15:49.13 | jkroon | thanks. learning quite a bit here today. and this is rather core functionality, so getting it wrong is going to go *boom* for someone. |
| 15:49.29 | jkroon | so really would like a few eye-overs on this one after I've done my own testing. |
| 15:52.19 | jkroon | i think I'm going to follow the ao2_iterator_* methodology. it's basically what the current code does anyway. |
| 15:53.07 | seanbright | there have to be at least 3 sets of eyes on it for it to be merged, so you're covered in that regard |
| 15:53.39 | jkroon | seanbright, i hope that three excludes my own. |
| 15:53.44 | seanbright | it does |
| 15:53.47 | jkroon | good. |
| 15:54.13 | jkroon | and since file wrote the original code i'm hoping he'd be willing to once-over this too. |
| 15:54.43 | seanbright | he might, but there are plenty of us that can take a look |
| 15:54.59 | jkroon | and ideally test it somewhere where STUN is properly configured and required (I think I can activate STUN on my test box which has public's but that's kinda pointless I reckon) |
| 15:55.13 | file | anything that goes up on Gerrit I generally look at |
| 15:55.48 | jkroon | file, if you don't mind looking at my existing WIP ... it's the first portion of this so long. I may squash this into that later if requested. |
| 15:59.59 | jkroon | hmm, ipv6 link-locals should be included in ICE? |
| 16:00.28 | file | they are currently, if you want within the official recommendations you'd need to look at the RFC and such |
| 16:00.43 | file | as for review I'd prefer to review upon completion so I can see things over all |
| 16:07.54 | jkroon | then i'm going to leave them in. |
| 16:08.14 | jkroon | is there an easy way to compare IPv6 for being ::1 ? |
| 16:08.43 | file | I know nothing |
| 16:09.01 | seanbright | i think there is something in netsock2 for that purpose |
| 16:09.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 16:10.04 | jkroon | This is one thing where I'm deviating ... PJSIP will filter all addresses assigned to lo ... but I have a few setups where I've got multiple routes out over different interfaces, but only a single public assigned to lo ... so for those use-cases I'd prefer to not outright filter everything assigned to lo, only 127.0.0.0/8 and ::1 |
| 16:10.32 | jkroon | seanbright, there is ast_sockaddr_is_any() but I'm not seeing something for loopback address, maybe I'm just missing it? |
| 16:10.33 | seanbright | i was wrong, there doesn't appear to be |
| 16:10.57 | seanbright | i've never seen a public ip assigned to the loopback interface, what's the purpose of that? |
| 16:11.18 | jkroon | more generally used in networking to have an "always up" address. |
| 16:12.26 | jkroon | however, we've started using that in severely ip deprived environments to conserve v4 address space on servers, so 10.0.0.X/? on links, and then ip ro pub via 10.0.0.X of server requiring pub. |
| 16:12.34 | jkroon | it's somewhat fugly but it does work. |
| 16:13.34 | jkroon | ends up with some rather nasty /32 routes flying around, but if for an organization you only have a single /24 having 256 /32 routes flying through your WAN is a small price to pay to make those stretch as far as you possibly can. |
| 16:15.59 | *** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/matrix.org/x-vqnvxprxmyrquyuh) |
| 16:15.59 | *** mode/#asterisk-dev [+o danjenkins] by ChanServ |
| 16:16.00 | danjenkins | Bonjour |
| 16:16.35 | danjenkins | ARI SFU question on this Tuesday afternoon |
| 16:17.52 | danjenkins | i create a mixing/sfu bridge using ARI but I get some audio back from the bridge when its only be in the bridge (like a delayed version of my audio but doesnt cause feedback, its just odd weird audio) |
| 16:18.21 | danjenkins | I'm assuming I should just pass in the mixing and sfu flags and thats all for an ARI bridge that has sfu capabilities? |
| 16:21.42 | file | yes |
| 16:21.58 | file | I'm not aware of any known issue like that, it's the same audio mixing as ConfBridge |
| 16:22.02 | file | or audio conferences in ARI |
| 16:23.04 | danjenkins | thanks file |
| 16:23.20 | danjenkins | yeah its an odd one... like occasionally i'll hear a delayed version of me typing |
| 16:23.27 | danjenkins | but if i speak i dont hear myself |
| 16:23.44 | file | are you sure it's not AGC and echo cancellation having fun? |
| 16:24.17 | danjenkins | it could well be? I havent looked into it enough yet.... |
| 16:24.39 | danjenkins | my first thought was i wasnt passing the right flags |
| 16:25.08 | file | there's no flags to pass for anything like that, the audio is inherently not mixed into the stream you receive |
| 16:25.44 | danjenkins | yeah |
| 16:25.57 | danjenkins | merci beaucoup |
| 16:38.25 | jkroon | so this is interesting ... debian and derivatives are going to have fun, 127.0.0.0/8 is available for traditional loopback (unexposed) addresses in v4, but it's ONLY ::1 in v6... |
| 16:39.01 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 16:41.28 | jkroon | file, i see before doing stun you check that count > 0 ... I'm assuming that's to know if we've got at least one local address? |
| 16:41.42 | seanbright | i mean... |
| 16:41.42 | file | probably |
| 16:42.03 | seanbright | it answers the question "is count greater than zero" |
| 16:42.11 | seanbright | so your interpretation sounds correct |
| 16:42.46 | jkroon | ok, i'm going to drop that, and just assume that we do ... count now counts the number of ICE candidates added, and all local addresses could in theory be blacklisted, relying completely on STUN to get a workable address (unlikely but possible) |
| 16:45.14 | file | assume that we do what? |
| 16:45.26 | jkroon | that we do have at least one local address. |
| 16:45.41 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 16:46.05 | jkroon | if we transmit a STUN request and we don't the OS will in any case generate an error on send() which should short the call to ast_stun_request() out quickly. |
| 16:46.34 | file | if you don't have a local address, you don't have a base address, and I believe that's required for a server reflexive |
| 16:48.23 | jkroon | does it have to be a v4 or v4_mapped address? |
| 16:48.50 | file | the STUN client used only supports V4 |
| 16:48.57 | file | so the base address would need to be v4 |
| 16:49.19 | jkroon | obviously. i'm being a moron. |
| 17:09.28 | jkroon | file, is there an issue with using the passed ast_sockaddr *addr as the base? |
| 17:31.08 | file | you'd have to consult the RFC for what it should be and why |
| 17:33.37 | danjenkins | gtjoseph: when you were makin g the demo app with gogle's speech to text did you come across either of these issues? https://github.com/nimbleape/dana-tsg-rtp-stt-audioserver/issues |
| 17:33.48 | gtjoseph | looks |
| 17:34.39 | danjenkins | I didnt use your adapted version of their demo app on infinite streaming |
| 17:34.42 | danjenkins | i adapted theirs |
| 17:34.50 | danjenkins | we ended up with something very similar |
| 17:35.21 | gtjoseph | yeah, the deadline_exceeded one i've seen but not the audio timeout error |
| 17:35.30 | danjenkins | and i thought id written into it enough to catch these errors but obviously not..... i need to track back whats throwing the fatal error |
| 17:35.54 | danjenkins | yeah so the audio timeout is where my browser dies and stops sending audio so tahts fine |
| 17:35.57 | gtjoseph | yeah it's kinda weird. their sampe code doesn't handle errors and reconnection very well |
| 17:36.04 | gtjoseph | gotcha |
| 17:36.11 | danjenkins | its odd that it throws a fatal error wherever it is |
| 17:36.19 | danjenkins | because im listening for the error and logging it |
| 17:36.29 | danjenkins | meh |
| 17:36.29 | danjenkins | ok thanks! |
| 17:36.35 | gtjoseph | no problem! |
| 17:37.15 | danjenkins | Dana's almost at a point of it having transcription on multiple bridges and multiple participants |
| 17:37.38 | danjenkins | its just that fatal throwing thats causing the main problem now |
| 17:37.55 | gtjoseph | Nice!! |
| 17:38.05 | gtjoseph | not the fatal errors part. :) |
| 17:38.10 | danjenkins | yeah |
| 17:38.15 | danjenkins | ill track it down later |
| 17:38.37 | danjenkins | havent decided how to show it all off without you know... it costing me a fortune in people using it |
| 17:38.55 | gtjoseph | HA! |
| 17:43.40 | jkroon | danjenkins, have them provide you a google auth token for use :). |
| 17:44.25 | danjenkins | wouldnt be difficult to pass along with the mqtt message |
| 17:44.34 | gtjoseph | or a paypal address :) |
| 17:45.01 | danjenkins | yeah i did think about a coffee donate button type thing |
| 17:45.12 | danjenkins | but no-one knows how much transcription really costs right |
| 17:45.58 | jkroon | quite a bit more than the related bandwidth :) |
| 17:46.21 | danjenkins | plus i could just put it up for a week..... but someone would screw me over |
| 17:46.29 | danjenkins | OR id forget and just leave it up there |
| 17:47.08 | danjenkins | auth key and project id as part of the dana settings would work |
| 17:47.27 | danjenkins | oh but then id have to pass it up from the browser |
| 17:48.50 | danjenkins | meh - i'll prob just run it for a few weeks and put a max spend on the google cloud account |
| 17:48.55 | danjenkins | i think you can do that |
| 17:56.46 | jkroon | file, looks like base address should be the address+port FROM WHICH the stun request was sent. which isn't addr, nor what used to be called base, but rather rtp->rtcp->s or rtp->s (unless addr happens to be exactly that) |
| 17:57.05 | jkroon | The host candidate associated with a given server-reflexive candidate is the "base". |
| 17:58.27 | jkroon | in reality I'm not sure it matters, what is interesting is that the RFC seems to assume that you're opening a socket for each and every host candidate, binding it to the specific IP:PORT, and then sending STUN/TURN requests from each and every one of those (which explains why when I activate STUN in browsers it takes some ridiculous amount of time to gather all ICE candidates) |
| 17:58.56 | file | rtp->rtcp->s can be set to wildcard, in which case you don't know except using the host candidate which has worked fine for many many years |
| 17:59.32 | jkroon | reality is i don't think it actually matters. base was previously set to the first found candidate address. |
| 17:59.38 | jkroon | i'll just follow suit. |
| 17:59.57 | jkroon | not given that we're binding a single socket anyway ... |
| 18:06.11 | jkroon | given the calls to rtp_add_candidates_toice, using addr is as good as any looking at it in more depth. would have been nice if ast_stun_request also gave us the responded to address in &answer. |
| 18:06.26 | jkroon | so an extra sockaddr ... but i don't think that's going to fly. |
| 19:03.10 | jkroon | file, if by the time I get to STUN I already have PJ_ICE_MAX_CAND ... do I simply completely skip STUN? |
| 19:04.20 | file | whatever the existing behavior is |
| 19:04.48 | seanbright | this seems like the edgiest of edge case configurations |
| 19:06.48 | jkroon | file, undefined. |
| 19:07.17 | jkroon | what will pjproject do if we try to add more than PJ_ICE_MAX_CAND candidates? |
| 19:07.38 | jkroon | that's the current behaviour, but seanbright is right, if you're running into that you've probably got bigger issues. |
| 19:07.53 | seanbright | there are only PJ_ICE_MAX_CAND slots in the array |
| 19:08.03 | seanbright | so that's like... the max number of ice candidates |
| 19:08.17 | seanbright | you can change it and recompile if you want |
| 19:08.23 | seanbright | it's in third-party/... somewhere |
| 19:08.39 | jkroon | ok, so if we reach that prior to STUN, then tough, skip STUN because pjproject is going to discard the added entry anyway. |
| 19:08.47 | seanbright | third-party/pjproject/patches/config_site.h |
| 19:09.18 | seanbright | i don't think you can safely even add it |
| 19:13.15 | jkroon | pushed. i really don't like the way gerrit handles multi-patch reviews. |
| 19:13.23 | jkroon | or I did something fundamentally wrong. |
| 19:14.51 | jkroon | https://gerrit.asterisk.org/q/topic:%22rtp_ice_stun_acl%22+(status:open%20OR%20status:merged) |
| 19:25.16 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 19:25.16 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 19:52.18 | danjenkins | gtjoseph think I figured it out. Will test tomorrow |
| 19:52.26 | gtjoseph | cool. what was it? |
| 19:54.19 | danjenkins | I was removing my error handler and I hen calling destroy on the stream. That in turn meant it never got back a response to the end and would emit an error saying it never got a response , no error handler = quit program with fatal |
| 19:54.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.107) |
| 19:54.50 | danjenkins | So move destroy to end() and leave a logging error event listener |
| 19:55.09 | gtjoseph | ah. makes sense |
| 19:55.39 | danjenkins | I'll test it tomorrow |
| 20:37.01 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-68-217.w90-49.abo.wanadoo.fr) |
| 21:33.25 | seanbright | so i think ASTERISK-28445 is pretty straight-forward |
| 21:33.52 | seanbright | we copy the pointer returned by ast_sorcery_object_get_id(session->endpoint) |
| 21:34.07 | seanbright | ao2_cleanup(session->endpoint) |
| 21:34.13 | seanbright | and then try to use the saved pointer |
| 21:34.19 | seanbright | so use-after-free |
| 21:34.25 | seanbright | or am i taking crazy pills? |
| 21:43.54 | kharwell | are you saying the solution is to just copy the string at the beginning of the destructor? |
| 21:44.05 | kharwell | copy the "endpoint_name" that is? |
| 21:44.22 | seanbright | i believe so, that fixes it in my tests |
| 21:44.39 | seanbright | https://gerrit.asterisk.org/c/asterisk/+/13364 |
| 21:44.41 | kharwell | looking at the code that seems reasonable. |
| 21:44.58 | seanbright | thanks to your detailed setup instructions |
| 21:45.27 | kharwell | I aim to please |
| 21:45.44 | seanbright | except endpoints.2000.sql is identical to endpoints.1000.sql |
| 21:45.49 | seanbright | but i was able to make due |
| 21:45.53 | kharwell | whoops |
| 21:47.07 | kharwell | only thing is I'm trying to find where the session object would disappear before the json blob is written to |
| 21:48.24 | kharwell | as in the sorcery object would have to disappear before the json blob gets created right? |
| 21:49.37 | kharwell | oh wait I see it |
| 21:49.51 | kharwell | was thinking it was the session object, but it is the session->endpoint object |
| 21:50.07 | kharwell | just what you said above heh |
| 21:55.24 | seanbright | maybe it would be better to move the endpoint cleanup to the end of the function after the test suite event is fired? |
| 21:55.43 | seanbright | but i'm worried that might have unintended consequences |
| 21:59.50 | kharwell | hrm yeah what you currently have is certainly the "safest" route |
| 22:48.49 | seanbright | rmudgett: you always have good ideas |
| 23:30.46 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |