| 00:15.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 00:22.30 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 00:41.43 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 01:07.50 | dan_j | When an endpoint is loaded and qualify is set to 0, should it automatically be considered online and not in use? |
| 01:08.22 | dan_j | I'm looking at this issue which is also affecting me. https://issues.asterisk.org/jira/browse/ASTERISK-26599?filter=13158 |
| 01:09.58 | dan_j | Actually, ignore that. Looking at the current functionality, it is considered online and notinuse. Correct me if i'm wrong. |
| 01:20.19 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:20.19 | *** 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 |
| 03:34.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 03:35.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 05:32.15 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 06:54.38 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.182.47) |
| 07:34.25 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 07:38.21 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.182.47) |
| 07:42.39 | *** join/#asterisk-dev ixyd (~denzs@b2b-46-252-133-250.unitymedia.biz) |
| 07:49.55 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:52.43 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:02.39 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:12.24 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:17.10 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::141c) |
| 08:43.36 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:06.36 | *** join/#asterisk-dev tuxian_ (~tuxian@194.12.3.78) |
| 09:25.12 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 09:26.24 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 09:26.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:32.00 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.45) |
| 12:18.56 | tsearle | good afternoon all |
| 12:30.54 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 13:31.08 | tsearle | guess fridays are rough here, heh |
| 14:13.40 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-rllbkohcjortsugc) |
| 14:13.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:47.33 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:47.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:11.12 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-nzobpkeevzfmuzyv) |
| 15:11.12 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:14.53 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 15:15.39 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 15:39.41 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 15:40.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:45.59 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-affebwtjhahywfbl) |
| 15:45.59 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:47.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:59.42 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:45.25 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 16:52.12 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-srjakwawaoccqanx) |
| 16:52.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:52.24 | mjordan | Bike-shedding question! |
| 16:52.41 | mjordan | we currently have a set of CLI commands that allow inspection of the PJSIP identify object |
| 16:52.56 | mjordan | pjsip list identifies, pjsip show identifies, pjsip show identify, etc. |
| 16:53.20 | gtjoseph | yeeeees? |
| 16:53.37 | mjordan | IRC really needs to have typing indications |
| 16:53.46 | gtjoseph | :) |
| 16:53.49 | mjordan | if I added another identify module that exposes another config object - not really hypothetically called 'identify_header' - what would we want the CLI commands to be? |
| 16:55.08 | gtjoseph | does it NEED new CLI commands? |
| 16:55.39 | gtjoseph | does it even need to be a new object? |
| 16:55.47 | mjordan | welp |
| 16:55.57 | mjordan | the existing identify object is pretty IP specific. |
| 16:56.00 | gtjoseph | i.e. identify by username and auth_username don't have separate commands or objects |
| 16:56.17 | mjordan | true, but they're both identifying by some user name component |
| 16:56.33 | mjordan | if I'm trying to identify by an arbitrary token in a SIP header, that's not really the same as the existing identify moduels |
| 16:56.33 | gtjoseph | they're identifying by something in the header |
| 16:56.35 | mjordan | modules. |
| 16:56.40 | mjordan | Well, yes, but that's all of SIP :-) |
| 16:57.12 | mjordan | I would be happy to co-op the existing res_pjsip_endpoint_identifier_ip module, but what I'm doing has nothing to do with IP addresses |
| 16:57.27 | mjordan | which is why I asked this question a few days ago :-) |
| 16:57.30 | gtjoseph | yeah but to be honest since a single identify can only match 1 endpoint, i'm not sure why it's an object of it's own anyway |
| 16:57.51 | gtjoseph | how complex is the selector? |
| 16:58.12 | mjordan | the scenario is pretty easy: I can't rely on IP addresses (for various reasons) |
| 16:58.17 | mjordan | and I have two ingress proxies |
| 16:58.28 | mjordan | I need to match requests to those two proxies |
| 16:58.39 | mjordan | So they're going to slap a magic header + token into the requests/responses |
| 16:58.53 | mjordan | which Asterisk can then match to the appropriate endpoint(s) |
| 16:59.03 | mjordan | so pretty simple |
| 16:59.12 | mjordan | (it took me 45 min to write) |
| 16:59.19 | seanbright | 45 minutes? |
| 16:59.22 | seanbright | filthy casual |
| 16:59.24 | mjordan | heh |
| 16:59.32 | mjordan | copy + paste from the other identify modules, and I knew which PJSIP functions to use |
| 16:59.43 | mjordan | the AMI/CLI commands are taking longer, not surprisingly |
| 16:59.58 | gtjoseph | gotcha |
| 17:00.11 | gtjoseph | so i can think of 2 ways to go... |
| 17:01.02 | gtjoseph | 1. just a match_header_regex parameter to endpoint and add a new identify_by value called "header_regex" |
| 17:01.25 | mjordan | it would end up being two parameters - the header to lookup and the value, but yes |
| 17:02.28 | gtjoseph | the downside being that you'd have to scan all endpoints to match |
| 17:02.34 | file | yup. |
| 17:03.09 | mjordan | ew. |
| 17:03.19 | gtjoseph | 2. create the new object and make the CLI commands more generic |
| 17:03.20 | file | there are consequences to stuffing everything in endpoint. |
| 17:03.34 | mjordan | so, that's what I'm going with for option #2 |
| 17:03.45 | file | mjordan: to answer your original query though - everything uses the format of the object type name, single and pluralized |
| 17:04.14 | mjordan | right, so right now I would have 'pjsip list identify_headers', 'pjsip show identify_headers' and 'pjsip show identify_header' |
| 17:04.17 | gtjoseph | yep. i wouldn't create a new "identify" set of cli commands |
| 17:04.18 | mjordan | which is ... shameful. |
| 17:04.27 | mjordan | gtjoseph: I can do that, but that does mean a new header |
| 17:04.27 | gtjoseph | don't do that |
| 17:04.30 | mjordan | heh |
| 17:04.36 | mjordan | Hence why I stopped and started the discussion :-D |
| 17:04.40 | gtjoseph | new header. so what |
| 17:04.47 | gtjoseph | name it :criteria" |
| 17:05.15 | mjordan | I'd rather not change the existing commands at all, and just have them list out their type |
| 17:05.21 | gtjoseph | Match: <criteria...........................> |
| 17:05.24 | mjordan | which will answer the question of 'what does this match on' |
| 17:05.27 | mjordan | yeah. |
| 17:05.30 | mjordan | kk, I'll do that. |
| 17:05.43 | mjordan | You get a global symbol, you get a global symbol, EVERYONE GETS A GLOBAL SYMBOL |
| 17:06.19 | mjordan | actually |
| 17:06.23 | mjordan | it may not be as bad as I think. |
| 17:06.32 | mjordan | I really just need to put the configuration object structs into a header file. |
| 17:06.38 | mjordan | that's not super terrible. |
| 17:07.54 | gtjoseph | do it like auth |
| 17:08.15 | gtjoseph | depending on the type, some options are valid and some not |
| 17:08.49 | gtjoseph | the only thing in identify that's ip specific is srv_lookups and that was only just released |
| 17:11.10 | gtjoseph | [my_ident] |
| 17:11.10 | gtjoseph | type = identify |
| 17:11.10 | gtjoseph | match = "192.168.0.0/32 |
| 17:11.10 | gtjoseph | endpoint = my_ep |
| 17:11.10 | gtjoseph | [my_ident] |
| 17:11.11 | gtjoseph | type = identify |
| 17:11.13 | gtjoseph | identify_type = header |
| 17:11.15 | gtjoseph | match = X-some-header: <regex> |
| 17:11.17 | gtjoseph | endpoint = my_ep |
| 17:11.19 | seanbright | PASTEBIN! |
| 17:11.21 | seanbright | (kidding) |
| 17:18.32 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:19.56 | mjordan | hm |
| 17:20.32 | mjordan | is unsure. |
| 17:20.43 | mjordan | I'll think about it, but co-opting something like this always makes me uneasy. |
| 17:20.54 | mjordan | not to mention repurposing the 'match' field. |
| 17:21.06 | gtjoseph | a match is a match |
| 17:21.25 | mjordan | with a completely different syntax based on some other parameter. I'm not struggling with the concept, I just don't like it. |
| 17:22.26 | mjordan | actually, let me reverse this slightly. |
| 17:23.02 | mjordan | @file / @putnopvut and wherever creslin is - you guys let me know the path you'd prefer me to take. Either a separate module, as I was going down, or co-op the existing one, as @gtjoseph recommended. |
| 17:23.11 | mjordan | I don't want to do the work twice, but I actually don't care that much. |
| 17:23.27 | gtjoseph | i'm not saying not to use a new module |
| 17:24.01 | gtjoseph | you might need to make a new identify module that does the sorcery bits then calls ip or header |
| 17:25.02 | file | that seems like it is needlessly complicating things |
| 17:25.34 | mjordan | the code that does the actual header matching is 60 lines long. |
| 17:25.39 | mjordan | is just sayin |
| 17:26.22 | file | the identify type was original made for IP based matching, we probably should have named it differently but c'est la vie |
| 17:26.48 | putnopvut | Sorry got a lot of catching up to do before I can express an opinion here. |
| 17:26.53 | putnopvut | (was makin' some lunch) |
| 17:28.25 | file | why were folks against separate CLI/AMI commands? just more work? |
| 17:29.01 | mjordan | The work doesn't bother me. I agree with gtjoseph that they are ugly. |
| 17:29.26 | gtjoseph | it just adds new commands that do the same thing |
| 17:29.38 | gtjoseph | list ways to identify an endpoiint |
| 17:30.16 | gtjoseph | if ident_by_ip were super complicated then i'd not have so much of a problem |
| 17:30.22 | gtjoseph | it's not though |
| 17:30.57 | gtjoseph | the only thing specific to the (from a naming perspective) is srv_lookups and we just added that |
| 17:31.01 | putnopvut | I don't have a problem with co-opting the identify sections to be able to identify by some other means (although the default table name of ps_endpoint_id_ips would be confusing then). |
| 17:31.14 | gtjoseph | it's confusing now :) |
| 17:31.18 | putnopvut | heh |
| 17:31.38 | putnopvut | Because the thing is, we sort of had the idea in our heads that people would want to be able to identify endpoints by ... some means. |
| 17:31.47 | putnopvut | And so that's why there are the separate modules for endpoint identifiers. |
| 17:31.48 | gtjoseph | it should have been named ps_indentified but no. :) |
| 17:31.54 | putnopvut | However, configuration is kind of a train wreck right now |
| 17:32.11 | putnopvut | Because it's not clear how new methods should be done. |
| 17:32.54 | gtjoseph | it's also confusing because we use "identify by" for 2 different things |
| 17:32.55 | putnopvut | This is the time where we can decide how things should be moving forward. |
| 17:33.08 | putnopvut | which 2 things? |
| 17:33.11 | file | the module name and the table specify IP, changing that has consequences |
| 17:33.43 | putnopvut | Yeah, and the object type is tied closely to the module because of how sorcery works. |
| 17:34.13 | gtjoseph | there could be a new wrapper module that does the sorcery bits |
| 17:34.35 | gtjoseph | res_pjsip_endpoint_identify" |
| 17:36.12 | file | does what sorcery bits? the option mapping and handling? |
| 17:36.30 | gtjoseph | yep |
| 17:36.30 | dan_j | Hi. How do I access a pjsip endpoints aors so I can loop through them? Or is there a way to query an endpoints aors to get only the ones that have qualify=0 ? |
| 17:36.48 | file | so, every time you need to do a new identify you then have to modify another module? |
| 17:37.11 | gtjoseph | the new identify could register to the main one |
| 17:37.16 | gtjoseph | dan_j: give me a sec |
| 17:37.44 | seanbright | rmudgett: you seem like the type of fella that has a red-black tree implementation floating around on your computer somewhere |
| 17:38.14 | gtjoseph | ao2 containers have a rb-tree implementation |
| 17:38.40 | seanbright | not for asterisk |
| 17:38.50 | seanbright | for my own personal consumption |
| 17:38.51 | rmudgett | Its in the astobj2_rbtree file. |
| 17:38.53 | file | register and do what? and if the type was loaded before registration you'd get an error message, and subsequently reloading it again wouldn't do anything |
| 17:39.04 | file | that is - the configuration in .conf was loaded before registration |
| 17:39.27 | seanbright | ok cool. i can work with that. |
| 17:39.27 | dan_j | gtjoseph: was that for me? |
| 17:39.40 | gtjoseph | dan_j: no hold on a sec |
| 17:39.42 | dan_j | k |
| 17:39.50 | file | and what exactly would the module provide/do? |
| 17:39.55 | gtjoseph | dan_j: look in pjsip_options.c qualify_and_schedule_all |
| 17:40.06 | dan_j | Just found ast_sip_for_each_aor |
| 17:40.12 | dan_j | Will look. thanks. |
| 17:40.50 | file | mjordan: please hold - your business is important to us |
| 17:41.33 | gtjoseph | sorry, my asterisk was filling up my /tmp with coredumps :) |
| 17:42.35 | gtjoseph | ok, so phoneprov uses the paradigm i'm thinking of |
| 17:43.22 | gtjoseph | phoneprov itself does the common work (and for chan_sip because it's legacy) but res_pjsip_phoneprov_provider the the work for pjsip |
| 17:43.34 | file | right, and I'm trying to understand the "common work" that would be done |
| 17:44.11 | gtjoseph | handling the call from distributor, and sorcery |
| 17:46.09 | file | there's an API for endpoint identifiers so it doesn't handle the distributor directly, it's already taken care of |
| 17:46.47 | gtjoseph | ok, fine. i'm too hungry to continue. |
| 17:46.54 | file | so you're down to sorcery |
| 17:47.09 | file | to me it doesn't feel as though it would add enough value |
| 17:48.50 | file | putnopvut: thoughts? |
| 17:49.55 | putnopvut | In all honesty, I've stopped caring that much. But that's a bad position for me to take... |
| 17:50.01 | file | :D |
| 17:50.16 | gtjoseph | btw, we could have alembic add a view "ps_identifies" over the existing table |
| 17:50.17 | seanbright | apathy is an opinion |
| 17:51.04 | file | my personal opinion is that endpoint identifiers should be separate, and that we should eventually alias type=identify to a different name |
| 17:51.04 | putnopvut | Basically, the API is there for someone to add a new way of identifying an endpoint. How that information gets conveyed to that module is something I'm willing to bend on, because we haven't done a good job of setting forth how that should be done. |
| 17:52.12 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:52.31 | file | trying to lump multiple implementations into the same 'thing' would make the documentation more confusing and complicate things |
| 17:52.55 | gtjoseph | we _could_ write better documentation :) |
| 17:54.22 | gtjoseph | anyway, i'm off to lunch. maybe i'll do an RFC review over the weekend |
| 17:54.46 | file | mjordan: for now do it separate |
| 17:55.22 | rmudgett | Horrors. That would require us to write comprehensible English |
| 18:14.00 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-168-19.w92-135.abo.wanadoo.fr) |
| 18:24.58 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 19:04.43 | putnopvut | rmudgett: Mind having a chat about some of your comments on https://gerrit.asterisk.org/#/c/5138/2 ? |
| 19:05.02 | rmudgett | k |
| 19:05.42 | putnopvut | For this comment: https://gerrit.asterisk.org/#/c/5138/2/include/asterisk/res_pjsip.h@676 , I agree that ABI gets broken, but I'm not sure what to do otherwise. Got any ideas? |
| 19:06.00 | putnopvut | I guess I could just put the option at the end of the ast_sip_endpoint def... |
| 19:06.17 | putnopvut | Is that what you were going for? |
| 19:06.23 | rmudgett | That's what I was going to suggest |
| 19:06.28 | putnopvut | Okay, cool. |
| 19:06.31 | putnopvut | One more thing |
| 19:06.41 | rmudgett | Master should have it where you got it now. |
| 19:06.51 | rmudgett | It groups better there. |
| 19:07.23 | putnopvut | On this comment: https://gerrit.asterisk.org/#/c/5138/2/res/res_rtp_asterisk.c@4572 , got any suggestions on a good alternative? Not sure if you saw my discussions in here yesterday (or maybe Wednesday) about why we're not reading into rtp->rawdata any more there. |
| 19:07.44 | rmudgett | We should clean up master for other options that have been added to the non ABI breaking place but better belong in a different location. |
| 19:08.16 | rmudgett | I didn't read that discussion. |
| 19:08.47 | putnopvut | Let me see if I can use infobot to pull that back up. |
| 19:09.56 | rmudgett | Is there really a need to not put it in the original buffer? Seems like we just read it out of the rtp socket. Also any packets we pull up into ast_read would get copied out by ast_frisolate() anyway. |
| 19:11.20 | putnopvut | https://paste.fedoraproject.org/paste/6vRfTREGpruF-uIdb2QklV5M1UNdIGYhyRLivL9gydE= |
| 19:11.56 | putnopvut | Actually: https://paste.fedoraproject.org/paste/0fG0KFG5KE92P3-RghsVvF5M1UNdIGYhyRLivL9gydE= |
| 19:12.02 | putnopvut | Ignore the first link. It's incomplete |
| 19:14.37 | putnopvut | So one thing I could do is that since rtp->rawdata is an 8K buffer, I could read into that, and mark where the end of the read packet is. Then I could use the remaining buffer space for frame data. |
| 19:14.52 | rmudgett | Isn't all rtp carried by udp? Thus there is only one packet per message |
| 19:15.14 | putnopvut | Yes, there's one UDP packet, but RTCP is a chain of RTCP packets all encapsulated in one UDP packet. |
| 19:15.32 | putnopvut | Always starts with an SR or RR, but then can have SDES, BYE, etc. |
| 19:16.19 | putnopvut | "Multiple RTCP packets can be concatenated without any intervening |
| 19:16.20 | putnopvut | <PROTECTED> |
| 19:16.20 | putnopvut | <PROTECTED> |
| 19:16.37 | rmudgett | How about putting another buffer in the rtp instance? |
| 19:17.06 | putnopvut | Yeah, that could work, too. Just another 8K? |
| 19:17.26 | rmudgett | It's just allocated memory then and not a stack buffer. And you wouldn't need to do the extra copy. |
| 19:17.27 | putnopvut | My worry there was that RTP instances might be getting a bit on the big side by doing that. |
| 19:17.43 | putnopvut | Yeah, I figured if I fixed the stack buffer problem I'd also get rid of the copy |
| 19:18.13 | putnopvut | I'll just go with adding a write/frame buffer to struct ast_rtp |
| 19:18.54 | rmudgett | Probably have to put it at the end to avoid ABI problems. |
| 19:21.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d001da378ace618106f.ipv6.abo.wanadoo.fr) |
| 19:35.35 | seanbright | how long is the buffer needed? |
| 19:52.06 | putnopvut | Well, I'm just doing the work on it now, and it looks like it would need to be the size of an ast_rtp_rtcp_report + an ast_rtp_rtcp_report_block |
| 19:52.07 | putnopvut | BUT |
| 19:52.09 | putnopvut | What's fun |
| 19:52.22 | putnopvut | is that I think I see why file was so confused about the rtp->rawdata stuff |
| 19:52.42 | putnopvut | It's because 13 and master have diverged in their RTCP interpretation routines. |
| 19:54.05 | putnopvut | In 13, the raw data is not ever used for anything in rtcp_read (but it does still read into a stack-allocated buffer, presumably so there's no need to lock the RTP structure while reading?) |
| 19:54.56 | putnopvut | In master, if a receiver report is received, then an ast_rtp_rtcp_report + an ast_rtp_rtcp_report_block are copied into the rtp->rawdata and made into an AST_FRAME_RTCP |
| 19:55.25 | putnopvut | So in 13, you could presumably safely read either RTP or RTCP into the rtp->rawdata and nothing bad would happen. |
| 19:55.38 | putnopvut | In master, though, the behavior of making the frame using the rtp->rawdata was added. |
| 19:56.24 | putnopvut | So maybe it's just a good idea to change how those frames are created instead since that's new to master. |
| 19:56.31 | putnopvut | 14 behaves the same as 13. |
| 19:56.35 | file | it'd be nice |
| 19:56.56 | file | the second buffer for rtcp that is returned in the frame would be nice, then the normal RTP path would just keep the rawdata and be happy |
| 19:57.20 | putnopvut | Agreed. |
| 19:57.34 | putnopvut | And that change only needs to go into master as well. |
| 20:53.09 | kharwell | is https://issues.asterisk.org/jira/browse/ASTERISK-26515 master only? |
| 21:01.07 | file | it's likely invasive enough that I'd lean towards master only yeahhhhh |
| 21:01.20 | file | invasive is the wrong word |
| 21:01.38 | file | I think changing payloads is substantial enough to be master only |
| 21:02.21 | kharwell | that's kinda where I was leaning. Plus it doesn't cherry-pick cleanly into 13 and who wants to do all that extra work :-D |
| 21:02.51 | file | :D |
| 21:06.53 | seanbright | rmudgett: hi buddy. got a sec? |
| 21:07.03 | rmudgett | k |
| 21:07.15 | seanbright | so, let's say my queue member is Local/foo@bar/n |
| 21:08.04 | seanbright | and said queue member transfers the caller somewhere else directly from their phone |
| 21:08.22 | seanbright | so after the fact, i have 2 local channels and a SIP channel in my channel list |
| 21:08.25 | seanbright | how would i track that? |
| 21:09.02 | seanbright | how would i know that the actual member channel is no longer there |
| 21:11.05 | rmudgett | Well one end of the local channel is still in the queue bridge which is all the queue app can track. Walking down a channel chain is difficult at best and likely to fail anyway. |
| 21:11.41 | rmudgett | The queue app can see the interface state of the member though. |
| 21:14.36 | seanbright | hm |
| 21:15.01 | rmudgett | This is starting to look like another repercussion of https://issues.asterisk.org/jira/browse/ASTERISK-16115 |
| 21:15.26 | rmudgett | of which there have been a few.. |
| 21:15.47 | file | ripples... |
| 21:15.54 | seanbright | so if one of my queue members is a non-optimizing local channel |
| 21:15.59 | seanbright | and i don't specify a state interface |
| 21:16.04 | rmudgett | file only ripples? |
| 21:16.09 | rmudgett | more like shudders |
| 21:16.10 | seanbright | i should have no expectation of it actually working, is that correct? |
| 21:16.47 | rmudgett | yes. the queue needs the interface state to know if the member is available. |
| 21:17.42 | rmudgett | It needs a real endpoint to know the state which a local channel cannot provide. |
| 21:17.47 | seanbright | right |
| 21:17.47 | seanbright | ok |
| 21:18.20 | rmudgett | file: or tidal waves |
| 21:19.24 | file | owwwwwwwwwwwwwwwww |
| 21:20.03 | file | hurt shoulder |
| 21:20.40 | rmudgett | app_queue has a tendency to do that. ;) |
| 21:34.51 | seanbright | ugh... ok, so asterisk-26400 appears to be fixed for the reporter |
| 21:34.58 | seanbright | the sip transfer stuff is still not working |
| 21:35.06 | seanbright | i'm not sure the best path forward |
| 21:41.52 | rmudgett | I'd say the key is going to be in the state interface of the local channel member since that is the only thing the queue has left it knows about. |
| 21:42.21 | rmudgett | Determining when to believe a state change in the interface is going to be tricky. |
| 21:45.15 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 22:05.55 | seanbright | yeah |
| 23:05.49 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-nzobpkeevzfmuzyv) |