00:18.46 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
00:18.46 | *** topic/#asterisk is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.28.0 (2019/7/25) 16.5.0 (2019/7/25), Security Only: 15.7.3 (2019/7/11); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
00:28.12 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-103-241-155.ks.ok.cox.net) |
00:46.14 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
01:52.37 | *** join/#asterisk ganbold (~ganbold@202.21.108.104) |
02:32.39 | *** join/#asterisk mindthelion (techquila@gateway/vpn/protonvpn/techquila) |
04:09.20 | *** join/#asterisk Oatmeal (~Suzeanne@2600:8802:1500:66b:ec67:25d9:a203:94aa) |
13:04.43 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
13:04.43 | *** topic/#asterisk is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.28.0 (2019/7/25) 16.5.0 (2019/7/25), Security Only: 15.7.3 (2019/7/11); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
13:15.18 | *** join/#asterisk ganbold (~ganbold@202.21.108.104) |
13:24.28 | *** join/#asterisk NWATechSupport (~NWARSciGu@wsip-72-204-193-12.ks.ks.cox.net) |
13:42.20 | *** join/#asterisk ganbold (~ganbold@202.21.108.104) |
13:50.28 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
13:51.12 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
13:57.48 | *** join/#asterisk waldo323 (~waldo323@75-151-31-89-Michigan.hfc.comcastbusiness.net) |
14:17.24 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
14:21.00 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-zbmltosdonattyne) |
14:21.00 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:25.59 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-dxfiuvpuzwjfowpc) |
14:25.59 | *** mode/#asterisk [+o bford] by ChanServ |
14:26.44 | *** join/#asterisk FuriousGeorge (aec801ab@171.sub-174-200-1.myvzw.com) |
14:26.50 | FuriousGeorge | hey all |
14:27.20 | FuriousGeorge | trying to enable app_macro, but not finding it in make menuselect / applications menu |
14:27.42 | FuriousGeorge | this is asterisk 16. i would assume it's enabled by default, but im getting No application 'Macro' for extension |
14:28.59 | file | it's in Applications under the "Deprecated" list at the bottom |
14:29.03 | file | it is not enabled by default |
14:31.48 | FuriousGeorge | thanks, file. |
14:32.46 | FuriousGeorge | what is preferred to macro these days? for instance, how should i implement the famous stdexten macro? i can imagine doing it pretty easily with chanvars in the regular dialplan |
14:33.30 | *** join/#asterisk twanny796 (~user@antazzo.com) |
14:34.33 | file | GoSub |
14:34.50 | file | it's documented in UPGRADE.txt that it should be used instead |
14:35.24 | [TK]D-Fender | There is also nothing "famous". It's a basic idea, which can (and should) be different for every user based on their flow. |
14:36.48 | FuriousGeorge | thanks again file |
14:41.11 | twanny796 | Is there a good updated book about sip? |
14:43.20 | *** join/#asterisk billxx (49b69010@c-73-182-144-16.hsd1.nh.comcast.net) |
14:47.23 | [TK]D-Fender | What are you missingà |
14:47.26 | [TK]D-Fender | ? |
14:53.38 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
14:55.24 | vlt | Hello. I have two asterisk machines with mutual type=friend sip peers, a gateway sip peer and a bunch of "local" users. *One* of the users that can place local and gateway calls just fine gets a "Failed to authenticate on INVITE" when placing calls via the other asterisk. What is the usual reason for this? |
14:55.37 | vlt | I enabled sip debug for the peer. These are two calls: https://termbin.com/oleh |
14:55.48 | vlt | The first one failed, the second one is successful. |
14:55.59 | vlt | Any idea what could be the difference here? |
14:59.32 | [TK]D-Fender | First you're redacting the information |
14:59.40 | [TK]D-Fender | that;s fucking with the body and expecting an autopsy. |
14:59.49 | [TK]D-Fender | Second you're not looking at the RECEIVING end |
15:00.40 | [TK]D-Fender | We're also not looking at 2 calls so we can't determine "difference". |
15:00.55 | [TK]D-Fender | So let's start by looking at what the receiving end sees |
15:01.02 | [TK]D-Fender | UNREDACTED |
15:01.27 | vlt | [TK]D-Fender: Thank you. I'll try to preapre that. |
15:01.39 | vlt | [TK]D-Fender: (Not two calls?) |
15:02.51 | [TK]D-Fender | The receiving end doesn't like what it's being told. So basically only that side's opinion counts |
15:18.16 | vlt | [TK]D-Fender: Thanks for your help :) I have a SIP debug of the receiving end: https://dpaste.de/pu61 |
15:18.28 | vlt | for a failed call |
15:19.04 | [TK]D-Fender | Show us the config on the receiving end you think this should match |
15:28.39 | Samot | Asterisk PBX 1.8.10.1~dfsg-1ubuntu1 <-- Seriously? |
15:30.02 | Samot | Also the second debug isn't complete. It's missing the response to the challenge and any failure responses. |
15:30.46 | file | Date: Thu Mar 15 20:12:33 2012 +0000 |
15:30.50 | file | huh, newer than I expected |
15:31.16 | vlt | Samot: Should I enable more than `sip set debug peer leipzig`? |
15:32.07 | vlt | [TK]D-Fender: relevant sip.conf on the receiving end: https://dpaste.de/UCKX |
15:36.25 | qakhan | Hi all, I have setup park call, get list of parked calls and pickup parked calls(AMI Redirect Action). I am save caller channel (who dial in the call) in DB and use that channel to do all park call stuff. |
15:36.45 | [TK]D-Fender | vlt, it isn't looking at that peer at all |
15:36.53 | [TK]D-Fender | Found peer '0' for '0' from 192.168.3.129:5060 |
15:37.12 | [TK]D-Fender | The FROM header says "0" and THIS system has a [0] |
15:37.14 | qakhan | is there any way i get caller channel (who dial in the call) info from AMI actions or from somewhere else. |
15:37.25 | [TK]D-Fender | so it doesn't think it's coming from another PBX, it thinks it's the LOCAL peer |
15:37.35 | qakhan | or i have to keep that information in DB? |
15:39.18 | vlt | [TK]D-Fender: Any idea why it behaves like this? Is "type=friend" not a good choice for this setup? |
15:40.43 | Samot | localnet=192.168.1.0/8 <-- I'm not sure that is possible. |
15:40.56 | Samot | Since 192.168.0.0/16 is what is used. |
15:42.00 | vlt | wonders why it worked with "Contact: <sip:15@192.168.3.129:5060>". Because there is *no* local [15]? |
15:42.06 | Samot | qakhan: You really, really, really need to read documentation. |
15:44.17 | [TK]D-Fender | vlt, correct |
15:45.03 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
15:45.24 | qakhan | Samot documention do you suggest |
15:45.31 | Samot | The wiki? |
15:45.44 | Samot | Sample config details. |
15:46.05 | Samot | There are channel variables that are created that could hold information you are looking for |
15:46.07 | qakhan | I am talking about AMI |
15:46.11 | Samot | OK |
15:46.15 | Samot | So the wiki. |
15:46.25 | Samot | The events cover what details are sent. |
15:46.29 | qakhan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+AMI+Actions |
15:47.03 | Samot | 11:37:19 AM <qakhan> is there any way i get caller channel (who dial in the call) info from AMI actions or from somewhere else. <-- The answer is yes to both. |
15:47.08 | Samot | Because channel variables are set |
15:47.17 | qakhan | I am getting caller channel info fron AMI Events |
15:47.20 | Samot | And AMI events will have the channel details. |
15:47.31 | qakhan | but Events are Runtime. |
15:47.36 | [TK]D-Fender | vlt, for PBX to PBX calls like this here's what you should do for those peers: |
15:47.44 | Samot | 11:47:13 AM <Samot> Because channel variables are set |
15:47.44 | Samot | 11:47:13 AM <Samot> Because channel variables are set |
15:47.45 | Samot | 11:47:13 AM <Samot> Because channel variables are set |
15:48.20 | Samot | You can create your own global variables |
15:48.22 | [TK]D-Fender | vlt, "fromuser=THEOTHERPEERNAME", "trustrpid=yes", "sendrpid=pai" |
15:48.25 | Samot | You can put this in AstDB |
15:48.42 | Samot | There are numerous ways to hold and/or get the MASTER channel's details. |
15:48.52 | vlt | [TK]D-Fender: Thank you, I'll try that. |
15:48.57 | qakhan | therefore i get info from Event like AgentCalled and save caller channel info in DB |
15:51.49 | Samot | But that Event is being fired and pulled outside of Asterisk |
15:51.59 | Samot | So how are you storing that information in Asterisk for it to use again? |
15:53.02 | vlt | [TK]D-Fender: Works! :-* |
15:54.11 | qakhan | I am running an Event watcher. I have set if Event=AgentCalled. then get the [channel] => SIP/itc-vitel-inbound-000012b2 and insert into DB |
15:54.29 | qakhan | here is AgentCalled Event https://pastebin.com/b5Fk5BAE |
15:55.27 | Samot | [channel] => SIP/itc-vitel-inbound-000012b2 |
15:55.32 | Samot | Which is also set in a global VAR |
15:55.40 | Samot | That can be called on in the dialplan. |
15:55.59 | qakhan | I am getting all the information what i need. but i am curious. is there any other way to get [channel] => SIP/itc-vitel-inbound-000012b2 instead of save it in DB |
15:56.32 | [TK]D-Fender | vlt, this forces the name in the FROM, and trusts the callerid name & number passed through RPID |
15:57.06 | Samot | 11:55:37 AM <Samot> Which is also set in a global VAR |
15:57.08 | Samot | GD. |
15:57.13 | Samot | How many times do I need to say it?! |
15:57.40 | vlt | [TK]D-Fender: I was just about to ask about the trust* options because the calling seems to work also without them. |
15:57.43 | vlt | themayor: Thanks. |
15:58.06 | qakhan | what is the name of that variable? |
15:58.23 | vlt | themayor: ^ Sorry, that was for [TK]D-Fender. |
16:02.18 | [TK]D-Fender | vlt, It will Ãworkà with or without, but itès a question of making sure the CID comes over right |
16:02.41 | Samot | 11:42:11 AM <Samot> qakhan: You really, really, really need to read documentation. |
16:05.27 | vlt | [TK]D-Fender: Ok. |
16:06.09 | vlt | For testing I changed type to "peer". Why can that peer still place calls here? |
16:06.41 | vlt | I'm just trying to understand the difference to "friend". |
16:08.47 | Samot | A friend is both a peer and a user |
16:08.59 | Samot | Versus being one or the other. |
16:10.06 | vlt | Samot: And why can that peer place calls here if it's a user? |
16:10.19 | vlt | if it's *not* a user |
16:11.07 | Samot | I haven't seen a full debug. |
16:11.13 | Samot | I told you what was missing from your last one. |
16:13.38 | [TK]D-Fender | vlt, "friend" can match by the FROM. "Peer" requires the IP to match. |
16:13.44 | vlt | Samot: Yes, thank you. I solved my actual problem by specifying "fromuser=..." in each other's sip.conf. |
16:14.08 | vlt | [TK]D-Fender: Ok, then it's the IP that makes this work. Thanks!!! |
16:24.48 | velix | Can anyone recommend a nice web GUI for asterisk n00bs? I've been using linux shell for 14 years now. But configuration of asterisk seems to be harder than anything else :D |
16:25.23 | [TK]D-Fender | Only real player is FreePBX |
16:25.28 | [TK]D-Fender | in the smaller space |
16:26.25 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
16:26.46 | velix | Can I edit the config files and the webGUI adapts it or will it end in a chaos? |
16:27.54 | [TK]D-Fender | mostly donèt bet on tweaking too much |
16:28.01 | [TK]D-Fender | limited hook-ins |
16:28.12 | [TK]D-Fender | youère choosing to give away control |
16:28.24 | velix | So I should stay at config files? |
16:28.29 | [TK]D-Fender | hates KB language inversion.... |
16:28.35 | [TK]D-Fender | you should verify your goals |
16:28.57 | [TK]D-Fender | You're asking what's "best" without answering "best for WHAT" |
16:29.23 | [TK]D-Fender | You need to look at your actual needs & wants |
16:29.35 | velix | Okay, you're right. |
16:46.29 | *** join/#asterisk Samot_ (sid133316@gateway/web/irccloud.com/x-yqqmmtwcfsgbyqzo) |
16:56.42 | qakhan | Samot I used AMI GetVar Action and passed Variable = CHANNEL but it not returning the values |
16:57.23 | qakhan | I get response = success but there is no ${CHANNEL} value returned |
17:02.55 | Samot | That doesn't really mean anything. |
17:03.23 | Samot | No clue when you're calling it or any of your logic for any of this. |
17:03.39 | Samot | There may not be a channel when you call it, who knows. |
17:13.52 | *** join/#asterisk ChkDigit (~u388mw@74.3.144.66) |
17:23.50 | *** join/#asterisk themayor (~themayor@unaffiliated/themayor) |
17:27.58 | qakhan | Samot this is PAMI i am using https://github.com/marcelog/PAMI/blob/master/src/PAMI/Message/Action/GetVarAction.php |
17:28.13 | qakhan | here is the a phone call i made https://pastebin.com/8eNPTaG6 |
17:29.25 | qakhan | here is the respose i got from GetVar https://pastebin.com/Bkh4tzXg |
17:32.22 | [TK]D-Fender | You're looking at the response ... and not the REQUEST |
17:47.59 | qakhan | [TK]D-Fender I am pass the variabale name (CHANNEL) |
17:48.30 | [TK]D-Fender | I'm not trust you're doing anythign right |
17:48.36 | [TK]D-Fender | trusting* |
17:52.54 | qakhan | here is how i am calling it https://pastebin.com/9APrFKzN |
17:53.14 | qakhan | am I not sending correct infotmation? |
17:54.12 | [TK]D-Fender | ... |
17:55.19 | [TK]D-Fender | I don't see you specifying a CHANNEL to get that variable from |
17:56.58 | qakhan | i am looking for channel information like SIP/itc-vitel-inbound-000012d0 |
17:57.05 | [TK]D-Fender | No.... |
17:57.19 | [TK]D-Fender | You have no clue what you're doing here at all |
17:57.50 | [TK]D-Fender | to GET a variable you have to specify what channel to get it FROM. |
17:58.14 | [TK]D-Fender | that is not a means of getting a LIST of channels |
18:00.08 | qakhan | ok here, i think you did not read my question. I need caller channel (e.g SIP/itc-vitel-inbound-000012d0) using AMI. Samot told me to use Dialplan Global Var. so ${CHANNEL} contains that information. |
18:00.41 | qakhan | but Getvar action will not work if we have multiple calls. |
18:00.53 | [TK]D-Fender | Come up witha new plan |
18:01.21 | Samot | First, you asked if there was a way to get the channel via AMI ___or another way___ |
18:01.36 | Samot | The __another way__ was the Channel Variables. |
18:01.40 | qakhan | how we can get the unique Caller channel |
18:01.46 | Samot | I didn't say mix the two |
18:01.50 | [TK]D-Fender | CHANNEL is a RESERVED variable name as well |
18:02.00 | [TK]D-Fender | You made a very bad choice of name |
18:02.09 | [TK]D-Fender | and alo represents a FUNCTION |
18:02.12 | Samot | You can get in the dialplan. |
18:02.21 | Samot | Or AMI events will have that information. |
18:02.34 | Samot | Once you have it you can choose how to store and/or use it. |
18:02.47 | Samot | You can use AMI to SET the channel variable you want to use later. |
18:03.02 | Samot | Or you can use AMI to insert it in the AstDB and call it from there. |
18:03.33 | [TK]D-Fender | qakhan, You've been in this channel alone for almost 10 years now. You're clearly doing this for a living. If you can't put the basics together in your head from the command reference you shouldn't be doing this. |
18:04.09 | qakhan | right, so i asked simple question. I am already getting caller Channel on AgentCalled Event and saving it in DB |
18:05.28 | qakhan | I am just trying to make my code simple. if that information available in any AMI action to use it. instead of save it in DB and get it from DB. |
18:06.22 | Samot | AMI actions come from OUTSIDE Asterisk. |
18:06.31 | Samot | So they need to tell Asterisk specific things. |
18:07.06 | Samot | Unlike using variables in the dialplan that are linked to the channels the dialplan executing on or via a function to set child channel vars. |
18:07.43 | [TK]D-Fender | qakhan, Your description is a mess |
18:07.57 | [TK]D-Fender | It comes in broken pieces |
18:09.02 | qakhan | [TK]D-Fender i have given my information before |
18:09.15 | [TK]D-Fender | yes, as a broken description |
18:09.31 | [TK]D-Fender | your writing is a mess and the thought process a pain to try to make sense of |
18:10.35 | [TK]D-Fender | You mix HOW you think you have to do a thing with the description of WHAT you want to do and the pieces rarely match |
18:16.19 | qakhan | I dont know what part did you miss |
18:17.08 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
18:17.57 | [TK]D-Fender | The whole thing is a mess |
18:18.03 | [TK]D-Fender | I can't tell what part is even meaningful |
18:18.08 | Samot | qakhan: You're asking how to store a variable for later use. |
18:18.14 | Samot | This is not an Asterisk issue. |
18:18.18 | Samot | This is a developer issue. |
18:20.15 | [TK]D-Fender | I can't tell what you're trying to get, why, and what you're going to do with it. |
18:26.00 | qakhan | here is my question again. is there anyway using AMI Actions to get channel (e.g SIP/itc-vitel-inbound-000012d0). |
18:27.09 | [TK]D-Fender | WHAT channel? |
18:27.21 | [TK]D-Fender | You can have 500 calls going on at once |
18:27.31 | [TK]D-Fender | that question you just asked means nothing |
18:27.47 | [TK]D-Fender | WHICH one out of 500 possible channels that may be active are you looking for? |
18:29.31 | Samot | qakhan: Only via an AMI event |
18:29.38 | Samot | Which will tell you WHAT channel it happened on. |
18:29.47 | Samot | Again, AMI is OUTSIDE of Asterisk. |
18:29.57 | Samot | Do you understand that? |
18:30.12 | Samot | It's making an request into Asterisk so it needs to know exactly what it is requesting.... |
18:30.24 | Samot | AMI needs to know the channel first. |
18:30.35 | qakhan | Yes, I do, i was discussing the question. |
18:30.49 | [TK]D-Fender | Your question is still meaningless. |
18:30.59 | Samot | You can't just get the channel |
18:31.07 | Samot | Because AMI needs to know what channel to look for. |
18:31.13 | qakhan | I dont understand you guys get serious. |
18:31.14 | Samot | Which is what you are looking for. |
18:31.28 | qakhan | [TK]D-Fender here is what i am doing. |
18:32.55 | qakhan | I am using AMI Park Action to park the call. I need channel (e.g SIP/itc-vitel-inbound-000012d0) so I know what call need to parked. |
18:33.28 | file | what channel needs to be parked only has meaning to you and your application |
18:34.19 | qakhan | and i am also using channel (e.g SIP/itc-vitel-inbound-000012d0) to AMI Redirect Action |
18:34.26 | Samot | When that call comes in over the vitelity peer, it's going to raise and AMI Event. |
18:34.33 | Samot | With the, yup, channel name. |
18:34.38 | Samot | THAT is when you get it. |
18:34.42 | Samot | That is when you store it. |
18:34.45 | Samot | Track it, whatever. |
18:34.45 | [TK]D-Fender | qakhan, you're supposed to KNOW which channel you want to do this to |
18:35.27 | [TK]D-Fender | How can you even search? You haven't defined how to IDENTIFY the one to do this to. |
18:35.31 | qakhan | like [TK]D-Fender you said use Redirect to pickup the call in queue and parked calls |
18:35.40 | [TK]D-Fender | The entire premise of your request is broken. |
18:35.43 | Samot | How is the AMI Action being triggered? |
18:36.03 | [TK]D-Fender | Holy shit, we're still on this? |
18:36.08 | [TK]D-Fender | It's been a WEEK |
18:36.09 | Samot | What triggers this AMI Park action? |
18:36.13 | Samot | Just wait.. |
18:37.06 | qakhan | you even dont let me finish my question. |
18:37.16 | qakhan | let me start over. |
18:37.27 | Samot | No, just answer my question. |
18:37.36 | Samot | You said "I am using AMI Park action" |
18:37.46 | Samot | OK, that's fine. How or what is triggering that action? |
18:37.53 | Samot | Is there a user in a GUI? |
18:37.59 | qakhan | now here is what i am doing it. |
18:40.52 | qakhan | 1) I have AMI event listener which monitor the "AgentCalled" Event. if it found the "AgentCalled" Event it saves following info from "AgentCalled" Event in DB. |
18:41.04 | qakhan | channel |
18:41.13 | qakhan | calleridnum |
18:41.20 | qakhan | uniqueid |
18:41.27 | qakhan | destchannel |
18:41.36 | qakhan | queue |
18:41.42 | qakhan | interface |
18:41.56 | Samot | OK |
18:42.03 | Samot | What is 2? |
18:42.21 | qakhan | 2) now i know the Channel and uniqueid. |
18:43.10 | [TK]D-Fender | Why do we give a shit about AgentCalled? |
18:43.37 | [TK]D-Fender | You were supposed to hijack a call that is sitting in a queue AWAITING distribution |
18:43.50 | qakhan | if user wants to park the call he send me uniqueid. i query unique id in DB and get the Channel info. which is required in AMI Park Acion |
18:43.51 | [TK]D-Fender | We don't give a shit if there WAS a previous attempt to distribute him or not |
18:44.11 | [TK]D-Fender | So we don't CARE about "AgentCalled" |
18:44.43 | Samot | qakhan: And how does the user send you the uniqueid? |
18:44.53 | qakhan | and i am able to Park the call. |
18:44.56 | Samot | qakhan: And how does the user send you the uniqueid? |
18:45.25 | [TK]D-Fender | You're looking at the wrong thing completely |
18:45.45 | qakhan | user has GUI and i gave him php webservice where he passes me unique id |
18:46.24 | Samot | So what is the issue here again? |
18:46.36 | Samot | You just want to know if there is a better way to store the information? |
18:46.41 | qakhan | Man. there is not issue. |
18:46.43 | qakhan | yes |
18:46.54 | qakhan | there is no issue* |
18:47.00 | Samot | OK see then you should have explained it this way already. |
18:47.08 | qakhan | i did |
18:47.12 | Samot | No. |
18:47.16 | Samot | You did not make it very clear. |
18:47.26 | Samot | Especially when you started asking more questions. |
18:47.34 | Samot | Then presented things that had issues... |
18:47.39 | qakhan | ok, my bad, i am sorry |
18:48.04 | Samot | No. |
18:48.05 | qakhan | [TK]D-Fender what i am doing wrong here |
18:48.11 | Samot | How you store the data is dealer's choice. |
18:48.19 | [TK]D-Fender | [TK]D-Fender> We don't give a shit if there WAS a previous attempt to distribute him or not |
18:48.19 | [TK]D-Fender | <[TK]D-Fender> So we don't CARE about "AgentCalled" |
18:48.19 | Samot | So it's different _per developer_ |
18:48.32 | [TK]D-Fender | You wanted to grab a guy sitting in a queue |
18:48.41 | [TK]D-Fender | previous call dsitribution means NOTHING |
18:48.50 | [TK]D-Fender | And you cam up with that idea based on WHAT? |
18:48.54 | [TK]D-Fender | How does that MATTER? |
18:48.59 | Samot | qakhan: My point again, he thinks you'e asking about the overall concept again. |
18:49.06 | [TK]D-Fender | You want the caller who is just SITTING there and not ringing |
18:49.37 | Samot | 2:46:39 PM <Samot> You just want to know if there is a better way to store the information? |
18:49.39 | Samot | 2:46:47 PM <qakhan> yes |
18:49.39 | Samot | 2:46:57 PM <qakhan> there is no issue* |
18:49.58 | [TK]D-Fender | So get the list of people sitting in the queue. There could also be MULTIPLE. How do you choose which one to hijack? |
18:50.18 | Samot | [TK]D-Fender: Decaffeinate. |
18:50.21 | Samot | There is no issue\ |
18:50.28 | Samot | It was about data storage. |
18:50.34 | qakhan | Samot LOL |
18:50.58 | Samot | A poorly presented question about it but that's what it was about. |
18:51.30 | [TK]D-Fender | <qakhan> like [TK]D-Fender you said use Redirect to pickup the call in queue and parked calls |
18:51.36 | [TK]D-Fender | this was his old rquest from over a week now |
18:51.40 | Samot | Right |
18:51.42 | Samot | Which he did |
18:51.56 | Samot | He just wanted to know if there was a better way to store the information then using AstDB. |
18:52.06 | qakhan | [TK]D-Fender you are right i want to know the caller (Channel) |
18:52.06 | Samot | Which I said is a per developer choice. |
18:52.15 | Samot | You have it. |
18:52.16 | [TK]D-Fender | He succeeded in stealing RINGING calls, but not ones sitting around awaiting distribution |
18:52.21 | qakhan | [TK]D-Fender you helped me to |
18:52.43 | Samot | qahkan: QUIT SAYING THINGS IN PRESENT TENSE! |
18:52.44 | [TK]D-Fender | that was where we left off and he's imply hasn't gone anywhere in this time |
18:53.12 | [TK]D-Fender | qakhan, Is this still your goal right now? |
18:53.23 | Samot | 2:52:09 PM <qakhan> [TK]D-Fender you are right i want to know the caller (Channel) <<-- You WANTED TO KNOW. Now you DO. |
18:54.54 | qakhan | [TK]D-Fender you guided me to use Rediect |
18:55.02 | qakhan | which i did |
18:55.02 | [TK]D-Fender | qakhan, that isn't an answer |
18:55.30 | [TK]D-Fender | qakhan, are you still trying to do the SAME thing I was advising you on last week? |
18:55.56 | [TK]D-Fender | <[TK]D-Fender> He succeeded in stealing RINGING calls, but not ones sitting around awaiting distribution <--- THIS |
18:56.10 | [TK]D-Fender | is THAT still the thing you're trying to accomplish? |
18:56.52 | qakhan | Yes, that thing also done by same way |
18:57.00 | qakhan | thank you |
18:59.33 | qakhan | the qestion i had in my mind was, instead of seaching Channel in DB using uniqueid, can we do same thing using AMI Actions. i read AMI Actions but I did not find any information. so i asked here |
19:02.40 | [TK]D-Fender | qakhan> Yes, that thing also done by same way <- explain |
19:02.47 | [TK]D-Fender | your wording is still terrible |
19:02.56 | [TK]D-Fender | is that gone DONE now? |
19:03.09 | [TK]D-Fender | I asked a yes/no quesiton and you messed it up with more word-salad |
19:04.17 | qakhan | Yes Sir |
19:04.31 | qakhan | it is done |
19:06.22 | [TK]D-Fender | Ok. So forget all of the other bits about AMI and DB, and all that other junk. What is the new situation then? |
19:06.56 | [TK]D-Fender | You brought up last week's issue .... and it was SOLVED. there was no value in bringing that up again and just wasted our time. |
19:07.50 | qakhan | I just solve it today. i did not wast your time. |
19:08.08 | qakhan | are you tell me dont come here again ? |
19:08.33 | qakhan | telling* |
19:09.33 | [TK]D-Fender | ... |
19:09.34 | [TK]D-Fender | No. |
19:09.40 | [TK]D-Fender | You jsut BROUGHT UP THE SUBJECT |
19:09.42 | [TK]D-Fender | WHY!? |
19:09.57 | [TK]D-Fender | You just confused THIS topic by bringing up SOLVED CRAP |
19:09.59 | qakhan | you said i wasted your time |
19:10.04 | [TK]D-Fender | You did |
19:10.10 | qakhan | no it was not solved |
19:10.11 | [TK]D-Fender | you just brough up something we SOLVED ALREADY |
19:10.23 | [TK]D-Fender | <[TK]D-Fender> is that gone DONE now? |
19:10.28 | [TK]D-Fender | <qakhan> Yes Sir |
19:10.28 | [TK]D-Fender | <qakhan> it is done |
19:10.32 | [TK]D-Fender | YOU JUST SAID IT WAS |
19:10.44 | qakhan | rigth it solved today |
19:11.05 | [TK]D-Fender | Why did you even bring it up then? |
19:11.27 | qakhan | what is harm to discuss thing in detail or to do differnet way |
19:12.11 | [TK]D-Fender | becasue you can't write proper sentences as it is |
19:12.27 | [TK]D-Fender | we can't separate what you need NOW from other crap you're bringin up from the PAST |
19:12.45 | [TK]D-Fender | It all comes out as a mess because of the language barrier |
19:12.55 | [TK]D-Fender | And we can't tell what you're talking about |
19:13.20 | qakhan | i dont know what you are talking about |
19:14.14 | [TK]D-Fender | you have a problem NOW |
19:14.23 | [TK]D-Fender | You had one I helped you with which is SEPARATE. |
19:14.28 | Samot | 2:49:40 PM <Samot> 2:46:39 PM <Samot> You just want to know if there is a better way to store the information? |
19:14.29 | Samot | 2:49:42 PM <Samot> 2:46:47 PM <qakhan> yes |
19:14.29 | Samot | 2:49:42 PM <Samot> 2:46:57 PM <qakhan> there is no issue* |
19:14.41 | [TK]D-Fender | When you talk ALL of that becomes a mixed up mess |
19:15.30 | qakhan | <Samot> You just want to know if there is a better way to store the information? |
19:15.35 | qakhan | <qakhan> yes |
19:17.02 | *** join/#asterisk ircarcs (~quassel@169.9.159.77.rev.sfr.net) |
19:17.16 | [TK]D-Fender | What information? |
19:18.04 | Samot | facepalms |
19:18.18 | Samot | The information he gets from the AgentCalled AMI event. |
19:18.25 | Samot | That has all the channel details. |
19:18.36 | Samot | He just wanted to know if there was a better way to store it. |
19:26.45 | [TK]D-Fender | better than what? |
19:26.55 | [TK]D-Fender | Better than the queue log? |
19:29.08 | Kobaz | infoooos |
19:29.09 | Kobaz | inpuuuut |
19:31.47 | Samot | Better so AMI or something external can grab the information at any point of the call. |
19:31.55 | Samot | Not just from the queue log. |
19:43.49 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
19:44.39 | *** join/#asterisk Oatmeal (~Suzeanne@2600:8802:1500:66b:ec67:25d9:a203:94aa) |
19:59.00 | [TK]D-Fender | Guess it's also a question of which call. |
19:59.15 | [TK]D-Fender | Could be 10 calls going on at once. |
19:59.39 | [TK]D-Fender | And a question of when you need to access this (including after it terminates now as well maybe...) |
20:06.07 | infinity_ | whats the best T1 to SIP device ? a voip gateway. any recommendations? |
20:11.05 | *** join/#asterisk twanny796 (~user@antazzo.com) |
20:11.37 | sawgood | infinity_: which side is SIP (the PBX side) or the carrier side? |
20:12.17 | infinity_ | pbx side |
20:12.25 | infinity_ | carrier is t1. |
20:12.41 | sawgood | infinity_: nice ... look at this wonderful box Yeastar TE100 |
20:13.11 | infinity_ | yeastar? is that like yealink? |
20:13.13 | infinity_ | thanks |
20:14.14 | sawgood | Yeastar is not Yealink, but close ... same island over in China |
20:14.21 | infinity_ | ;) |
20:16.36 | sawgood | you'll dig the TE100 ... its very straight-forward to use: runs Asterisk: and allows SSH! |
20:20.55 | *** join/#asterisk bank (~bank@acrossthemoat.com) |
20:24.08 | lagzilla | Likely not as cheap but we've had good luck with Adtran Total Access 908 |
20:24.54 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
20:26.58 | sawgood | I like those Adtran's too (good ol) AOS! |
20:27.43 | sawgood | I've been wanting this one Adtran model which takes in an ADSL2+ modem for its connection to the world: and it has SIP out to the PBX |
20:27.44 | lagzilla | Their support is awesome too imo, we had them push a patch for a niche issue we were experiencing |
20:34.41 | infinity_ | wow. thanks for all the comments! |
20:55.11 | *** join/#asterisk themayor (~themayor@unaffiliated/themayor) |
22:27.52 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
22:28.11 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
22:43.12 | *** join/#asterisk koss (koss@static-68-235-60-156.cust.tzulo.com) |