00:21.56 | *** join/#asterisk infobot (ibot@rikers.org) |
00:21.56 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.21.0 (2018/05/01), Standard: 15.4.0 (2018/05/01); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
00:34.55 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
00:54.40 | *** join/#asterisk Chotizei (chotaire@unaffiliated/chotaire) |
00:58.12 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
01:33.41 | *** join/#asterisk Oatmeal (~Suzeanne@rrcs-74-62-242-19.west.biz.rr.com) |
02:13.50 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
03:07.09 | *** join/#asterisk jeffspeff (~me@209.141.208.197) |
03:30.21 | *** join/#asterisk gringo (~gringo@unaffiliated/gringo) |
04:07.36 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-dgsrqkveflpzwecb) |
04:29.34 | *** join/#asterisk koss (~koss@koss.downlink.org) |
04:50.44 | *** join/#asterisk CatCow97 (~mine9@c-24-22-38-85.hsd1.or.comcast.net) |
04:55.45 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
04:58.08 | *** join/#asterisk ttyX (~ttyX@121.242.156.1) |
04:58.16 | *** part/#asterisk ttyX (~ttyX@121.242.156.1) |
05:13.05 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
05:54.59 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
05:54.59 | *** mode/#asterisk [+o cresl1n] by ChanServ |
06:03.49 | *** join/#asterisk jeffspeff (~me@209.141.208.197) |
06:06.02 | *** join/#asterisk miralin (~Thunderbi@91.237.94.10) |
06:27.45 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
06:27.45 | *** mode/#asterisk [+o cresl1n] by ChanServ |
06:38.30 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
07:02.26 | *** join/#asterisk sebastienthiry (~Thunderbi@109.134.212.7) |
07:05.20 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
07:06.43 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
07:06.43 | *** mode/#asterisk [+o cresl1n] by ChanServ |
07:22.19 | *** join/#asterisk waldo323_ (~waldo323@12.239.4.3) |
07:47.10 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
08:00.51 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
08:00.51 | *** mode/#asterisk [+o cresl1n] by ChanServ |
08:25.32 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
08:25.32 | *** mode/#asterisk [+o cresl1n] by ChanServ |
08:39.44 | *** join/#asterisk jamesaxl (~James_Axl@41.249.34.137) |
08:45.10 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
08:51.52 | *** join/#asterisk Hamagid (~Mutter@net-188-152-239-192.cust.vodafonedsl.it) |
09:21.10 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
09:21.10 | *** mode/#asterisk [+o cresl1n] by ChanServ |
09:31.49 | *** join/#asterisk war9407 (war@pool-70-106-236-148.clppva.fios.verizon.net) |
09:51.02 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
10:14.45 | *** join/#asterisk Ast001 (~uros@p5DCD6D28.dip0.t-ipconnect.de) |
10:15.51 | Ast001 | Hi is there a way to force asterisk to write maxforward in sip invite message ? I uncommented maxforward=70 in sip.conf but it seems there is no maxforward line in sip invite and some softphones does not like it and hangup call after 30 seconds (linphone) ? |
10:17.10 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-103-241-71.ks.ok.cox.net) |
10:21.57 | Ast001 | https://issues.asterisk.org/jira/browse/ASTERISK-24807 offers solution for pjsip, but what with ordinary sip.conf ? |
10:36.19 | Samot | Ast001: There's no further development on Chan_SIP |
10:36.37 | Samot | Outside of community submitted patches/updates |
10:44.40 | Ast001 | Can I force it somehow like this SipAddHeader(Max-Forwards: 70) ? |
10:47.13 | Samot | Why? It gets added |
10:50.15 | Samot | Max-Forwards is a required header. |
10:50.21 | Samot | It defaults/starts at 70 |
11:00.24 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
11:10.25 | *** join/#asterisk CatCow97 (~mine9@c-24-22-38-85.hsd1.or.comcast.net) |
11:10.39 | Ast001 | It does not show in sip set debug on, and linphone says bad request because of that and hangup call after 30 seconds or so. |
11:11.00 | Ast001 | with SipAddHeader it shows and is visible in sip debug |
11:13.24 | Samot | Well then something isn't right. I see it added in all the headers I'm sending out |
11:14.16 | Samot | In the OPTIONS, NOTIFYs, all of it. |
11:15.21 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-mvhonzabpbynkwwk) |
11:40.42 | Ast001 | Which version of Asterisk do you use ? |
11:50.06 | Ast001 | I see now in Invites Max-Forwards, but yesterday on linphone to linphone call over Asterisk I didn't see. I will recheck. |
11:54.43 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
11:54.43 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:04.53 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
12:09.34 | tomaluca95 | Hi, i would like to get asterisk data about sip peers in a python script to do some monitoring, there is a way to have something like json/yaml/xml peers information? I'm using debian 9 |
12:10.01 | Samot | ARI. |
12:10.48 | file | ARI isn't really meant for that, such information isn't available there |
12:11.08 | file | you can get it in a general sense using the endpoint route |
12:11.11 | file | but nothing in great detail |
12:13.17 | *** join/#asterisk nighty- (~nighty@s229123.ppp.asahi-net.or.jp) |
12:13.39 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:13.39 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:15.36 | Samot | True. |
12:15.49 | Samot | Then I guess it's AMI and parsing the data. |
12:17.49 | tomaluca95 | Thanks, I'll do some search about it |
12:19.15 | *** join/#asterisk Sepultura (~Sepultura@unaffiliated/sepultura) |
12:23.52 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:23.52 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:24.42 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:24.42 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:25.25 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:25.25 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:26.14 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:26.14 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:27.00 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:27.00 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:28.31 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
12:37.52 | *** join/#asterisk AndyCap (~aoy@pdpc/supporter/sustaining/AndyCap) |
12:46.02 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
12:47.16 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:47.16 | *** mode/#asterisk [+o cresl1n] by ChanServ |
12:48.41 | tomaluca95 | AMI is the solution, thanks |
12:51.08 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
12:55.10 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
12:56.53 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
13:01.53 | *** join/#asterisk pawiecki (~pawiecki@89.238.53.32) |
13:44.08 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
13:59.01 | *** join/#asterisk kharwell (kharwell@nat/digium/x-ejzagrpusbzllfno) |
13:59.01 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:45.50 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-bxyucwdknpsddwlr) |
14:45.50 | *** mode/#asterisk [+o bford] by ChanServ |
15:05.16 | *** join/#asterisk TheGoodGuy (~TGGG@mail.thegoodguysgroup.ca) |
15:13.57 | *** join/#asterisk Eloy (~Eloy@89.101.24.185) |
15:18.08 | *** join/#asterisk Givemelove (d80e0f82@gateway/web/freenode/ip.216.14.15.130) |
15:18.25 | Givemelove | Hey @all, I have some issues with dahdi on a new box. |
15:19.06 | Givemelove | I've had a Digium T1 card TE110p for years. Our system (built on Asterisk 1.6) crashed yesterday and we had to rebuild from scratch |
15:19.35 | Givemelove | In an effort to save time, I used Ubuntu's packages, which got me up and running pretty quickly, the configuration files being pretty similar still |
15:20.35 | Givemelove | the issue I have with dahdi is that dahdi_tool doesn't list the card anymore. If I do dahdi_hardware, I do see the card being listed (pci:0000:09:04.0 wcte11xp+ e159:0001 Digium Wildcard TE110P T1/E1 Board) and lsmod shows that the wcte11xp module is loaded yet not in use (wcte11xp 32768 0) |
15:20.52 | Givemelove | Anyone has a pointer for me to get it up and running again? |
15:21.59 | igcewieling | Givemelove: sounds like your kernel was upgraded without rebuilding DAHDI. |
15:22.43 | Givemelove | @icewiegling shucks. I had issues compiling dahdi from source so I went with the apt-get method |
15:23.10 | Givemelove | would that still be the case if the module loads with modprobe? |
15:25.58 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
15:26.50 | cresl1n | you might look at the dmesg log after you load the wcte11xp module |
15:26.56 | cresl1n | to see if it found the card |
15:27.13 | Samot | It's an EOL card. |
15:27.29 | Samot | Is it even able to run with current DAHDI tools? |
15:27.36 | cresl1n | not sure |
15:27.49 | cresl1n | but if you have the wcte11xp driver, it should find it |
15:27.55 | cresl1n | that's what I would think at least |
15:29.31 | Samot | Well at this point, it's a 10+ year old card. |
15:29.44 | Givemelove | I agree it's a very old card. I believe we got it in 2007 |
15:29.47 | Samot | I'd say you got your money out of it and would get a current and supported card. |
15:29.51 | Givemelove | the module loads apparently [ 18.026809] wcte11xp 0000:09:04.0: PCI IRQ 106 -> rerouted to legacy IRQ 18 [ 18.027736] FALC version: 00000005 [ 18.027776] TE110P: Setting up global serial parameters for T1 FALC V2.2 [ 18.027825] TE110P: Successfully initialized serial bus for card [ 18.027899] Found a Wildcard: Digium Wildcard TE110P T1/E1 |
15:32.58 | cresl1n | looks good |
15:33.05 | cresl1n | did you setup your /etc/dahdi/system.conf for it? |
15:33.11 | cresl1n | or use dahdi_genconf? |
15:33.48 | Givemelove | I did, says "Empty configuration -- no spans" |
15:34.29 | Givemelove | I had my old system.conf, but I'm given to understand genconf overrides it, right? |
15:34.39 | cresl1n | yeah, probably |
15:34.53 | cresl1n | then run dahdi_cfg |
15:35.25 | Givemelove | tried it: Timeout waiting for all spans to be assigned. DAHDI_SPANCONFIG failed on span 1: No such device or address (6) |
15:35.53 | Givemelove | when I do dahdi_genconf; dahdi_cfg, I only get this: Timeout waiting for all spans to be assigned. |
15:36.38 | cresl1n | what does your /etc/dahdi/system.conf look like? |
15:36.45 | Givemelove | could it be that the telco deactivated the T1? I'd think that this is independent of it |
15:36.53 | cresl1n | also, if you cat /proc/dahdi/1, what's the out put |
15:37.00 | *** join/#asterisk tpdmoore (4b96ddc7@gateway/web/freenode/ip.75.150.221.199) |
15:37.01 | Givemelove | when I run dahdi_genconf, I only have loadzone= us defaultzone= us |
15:37.02 | cresl1n | No, I think this is separate |
15:37.08 | cresl1n | Ahhhhh |
15:37.12 | cresl1n | do you have your old system.conf? |
15:37.39 | Givemelove | If I load the conf I had in the past, I add span=1,1,0,esf,b8zs dchan=24 bchan=1-23 |
15:37.54 | Givemelove | with newlines, of course |
15:38.26 | Givemelove | @creslin I don't have /proc/dahdi/1 |
15:38.52 | Givemelove | I'm putting the old system.conf and rebooting the box |
15:39.10 | cresl1n | that's not good |
15:39.22 | cresl1n | (the lack of /proc/dahdi/1) |
15:39.28 | Givemelove | I agree |
15:39.50 | Givemelove | I'm assuming it should detect the interface regardless of the T1 line status |
15:40.04 | cresl1n | yep |
15:40.28 | Givemelove | originally it tried loading another module instead of wcte11xp |
15:40.51 | Givemelove | it was throwing me a warning when I was running dahdi_hardware |
15:41.02 | Givemelove | I blacklisted that module and the pseudo dahdi interface |
15:41.09 | Givemelove | shall I keep the pseudo interface? |
15:42.09 | cresl1n | How did you blacklist the pseudo interface? |
15:42.14 | cresl1n | I'd keep it for now |
15:42.55 | Givemelove | <PROTECTED> |
15:43.05 | Givemelove | the module was named `netjet` |
15:43.10 | cresl1n | Ohhhhhhh |
15:43.22 | cresl1n | ok |
15:43.24 | tpdmoore | hi, i am using the ARI to set device states. When I restart asterisk, the device states have persisted. Where are those stored, and/or how can i reset them? |
15:44.10 | tpdmoore | i know that i will have to manage them within the ARI app, but during testing i'd like them to just clear out when i restart asterisk |
15:44.16 | cresl1n | I'd keep that module blacklisted |
15:44.20 | igcewieling | tpdmoore: that sort of thing is often saved in the AstDB. The backend for AstDB on modern Asterisk versions in SQLite 3 |
15:44.47 | cresl1n | +1 |
15:44.48 | igcewieling | try "database show" in the Asterisk CLI |
15:45.07 | tpdmoore | igcewieling: that's the ticket, tyvm |
15:45.31 | igcewieling | yw |
15:46.41 | Givemelove | for some reason, I can't compile dahdi from source |
15:47.08 | Givemelove | I must've been out of sysadmin for too long. I'm getting basic compilation errors that I can't figure out |
15:47.10 | tpdmoore | `database deltree StasisDeviceState` does exactly what i need, in case anyone else finds this useful |
15:47.30 | Givemelove | I may try installing debian and try to compile everything from source |
15:47.48 | tpdmoore | Givemelove: have you installed whatever your platform's equivalent of 'build-essential' is? |
15:48.36 | Givemelove | @tpdmoore yeah, it is installed. |
15:48.58 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:2424:45bd:9c99:58c8) |
15:50.07 | Givemelove | I think I have another card |
15:50.21 | Givemelove | not the same model, but the same age. I'll try that before going berserk |
15:53.44 | *** join/#asterisk Oatmeal (Suzeanne@gateway/vpn/privateinternetaccess/suzeanne) |
15:54.07 | Samot | Just my two cents, why spend all this time trying to get EOL/unsupported cards that are 10+ years old? |
15:58.43 | *** join/#asterisk jkroon (~jkroon@165.16.204.171) |
15:59.18 | Givemelove | @Samot I agree with you. It's a mgmt decision not to keep the system current |
15:59.27 | Givemelove | I'm running on 8yr old hardware |
15:59.38 | Samot | That's a poor decision. |
15:59.51 | Givemelove | and sure enough, the entire RAID failed yesterday and since we're running on a legacy version of asterisk, it's not making things easy |
15:59.53 | Givemelove | agree 100% |
15:59.58 | Givemelove | can't do much about it |
16:02.18 | cresl1n | you might try to replicate the version of Asterisk and DAHDI that you originally were running |
16:02.49 | Givemelove | i though about it, it's too much of a challenge |
16:02.53 | igcewieling | If you have to start from scratch anyway, why not use FreePBX? |
16:03.21 | Givemelove | the version of asterisk was 1.6, which is way unsupported |
16:03.56 | igcewieling | I meant a modern version. Maybe even the FreePBx distro |
16:04.02 | Givemelove | @Icewieling I still have my asterisk configuration, which contains Dialplan etc. in there |
16:05.25 | igcewieling | it will be a lot of work regardless of what you do. |
16:07.26 | craigify | Givemelove, what linux distro are you using? I have some very specific instructions to get Asterisk 1.6 to compile on Ubuntu 16, which will also probably work on the Debian distro it was built on |
16:07.31 | craigify | the big issue is the gcc version |
16:08.26 | craigify | it won't compile with gcc that comes with it |
16:11.05 | Givemelove | I'm on 18.04 LTS |
16:11.11 | Samot | Well hopefully management will have an attitude adjustment after this. |
16:11.22 | Givemelove | but I'm tempted to start from scratch; either Debian or ubuntu |
16:11.31 | Givemelove | @Samot One can only dream |
16:11.48 | Samot | Well, the bill on this will be a nightmare. |
16:12.02 | cresl1n | igcewieling: first step is to get it working as it did before, second step is to upgrade, IMHO |
16:12.41 | Samot | That's the problem though, isn't it? |
16:12.56 | craigify | Givemelove, you are trying to compile asterisk 1.6 on 18 LTS, correct? |
16:12.59 | Samot | "Working as before" means an old OS, old versions of stuff that is 10 years old. |
16:12.59 | Givemelove | @Creslin Agreed, I can work on the dialplan on a dev system |
16:13.06 | Givemelove | yes |
16:14.06 | Givemelove | 1.6 on 18.04 LTS |
16:14.06 | craigify | I am going to private message you something |
16:14.21 | *** join/#asterisk masoudd (~masoudd@5.52.167.7) |
16:21.11 | Samot | I'd just drop ship a new card, build a new/current box, migrate. |
16:21.58 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:dc60:8e29:5e84:69b7) |
16:26.51 | cresl1n | Samot: that's probably the easiest way |
16:28.08 | masoudd | Hello, I'm new to asterisk. I am writing a program that needs to place several calls through a trunk like this: 'originate sip/mytrunk/<phone number> application playback <sound-file>'. There is only one outgoing valid pstn line, and I have several calls to make. When I make several of these 'originate...' requests at the same time, only the first one rings and the rest seem like being discarded. How can I make it so that after the first call is |
16:28.08 | masoudd | terminated the next one is dialed? |
16:28.11 | Samot | The easiest, most cost/time effective and future proof way. |
16:28.57 | Samot | masoudd: You have to wait for the first call to return a DIALSTATUS showing it's completed. |
16:29.04 | [TK]D-Fender | masoudd, It's your job to queue these up yourself |
16:29.26 | Samot | If you send 5 Originate commands, it's going to originate 5 calls. |
16:29.32 | [TK]D-Fender | masoudd, so either monitor the progress of the ones you originate, or have that channel kick off the next as it is about to exit |
16:30.05 | masoudd | Isn't there a queue like feature that I can use? |
16:30.10 | Samot | No. |
16:30.21 | Samot | Originate is Originate. |
16:30.27 | Samot | You send the command, it executes. |
16:31.07 | masoudd | I see. Thank you all |
16:31.25 | Samot | You can basically send one call at a time. |
16:32.40 | masoudd | Related question: How can I monitor the state of a call? Where does it return the DIALSTATUS? |
16:32.55 | Samot | In the dialplan. |
16:33.00 | Samot | When the call is completed. |
16:33.08 | Samot | It will give you the status of that call. |
16:33.21 | Samot | ~wiki |
16:33.34 | Samot | http://wiki.asterisk.org |
16:33.47 | masoudd | Thank you again. I'll read the docs |
16:33.53 | Samot | ^^ You really should learn the basics of how Asterisk works so you can understand how to write this program. |
16:34.49 | masoudd | Yes. I need to learn. That's what I'm trying to do. |
16:40.01 | *** join/#asterisk kfife (~Miranda@home.chicagoventure.com) |
16:41.05 | kfife | Is there a way to invoke a dynamic feature into an existing call using AMI? |
16:42.55 | Samot | Might be able to set it on the channel. |
16:44.06 | [TK]D-Fender | kfife, as in? |
16:45.05 | kfife | Currently, calling party can invoke a feature by sending in-band *3. This injects a tone, and sets a local channel variable |
16:45.06 | *** join/#asterisk Oatmeal (Suzeanne@gateway/vpn/privateinternetaccess/suzeanne) |
16:45.42 | kfife | I'd like to call this same but trigger it via AMI |
16:46.04 | kfife | I'd like to invoke this same dynamic feature but trigger it via AMI |
16:47.07 | kfife | Maybe this is the wrong approach. |
16:49.04 | kfife | For example if I PlayDTMF into the calling-party's channel that might invoke the same feature |
16:49.14 | kfife | However I'd like to avoid the inband DTMF |
16:59.59 | Samot | Wait, so all *3 does it set a channel variable? |
17:00.38 | kfife | No, but it also does that. |
17:01.15 | Samot | So you want AMI to trigger that *3 for you? |
17:01.39 | kfife | possibly, but I don't need (or want) the in-band DTMF |
17:02.02 | kfife | becasue it causes a audible artifact in the call |
17:02.22 | Samot | OK so you don't want the the user to dial *3? |
17:03.00 | kfife | User can dial *3, but they are also looking at a Web UI that can send commands via AMI |
17:03.34 | Samot | Do you need to have the actual tone? |
17:03.39 | kfife | such as one that invokes the same dialplan code associated with the dynamic feature defined in features.conf, and in the channel |
17:03.41 | kfife | no |
17:03.46 | Samot | Or do you need to just trigger stuff to happen? |
17:03.48 | kfife | The tone is just a way to invoke the feature. |
17:04.08 | Samot | So then you have AMI trigger that context. |
17:04.26 | Samot | Or do whatever it is you need to do. |
17:04.27 | kfife | like action:originate? |
17:04.33 | Samot | Sure. |
17:04.39 | Samot | Or set channel variables. |
17:04.40 | kfife | Wouldn't that be a different scope? |
17:04.49 | Samot | Well AMI doesn't need to send *3 |
17:04.53 | Samot | It can just send commands |
17:05.05 | Samot | To do what you want. Set a channel variable? Send that command. |
17:05.22 | Samot | Call on a Dialplan app, can do that |
17:05.32 | Samot | There are numerous actions that can be done. |
17:05.53 | kfife | I can certainly re-create all of the code in the dialplan via AMI, but then I have to maintain the one feature in two places. |
17:06.03 | Samot | OK |
17:06.07 | Samot | So then you send DTMF |
17:06.18 | kfife | So therefore, it would be cleaner to invoke a dynamic feature via AMI if that's possible |
17:06.40 | Samot | By "invoking" you mean "sending" |
17:06.51 | Samot | Not set a dynamic feature on the channel |
17:06.56 | Samot | But use one that already exists. |
17:07.13 | kfife | That's correct. |
17:07.16 | kfife | One that already exists. |
17:07.24 | Samot | That's not how I understood it. |
17:07.28 | kfife | Ah... |
17:07.38 | Samot | So my suggestion of AMI was to set the dynamic feature on the channel. |
17:07.49 | Samot | So it could then be used, ie the *3. |
17:08.09 | *** join/#asterisk ih8wndz (jwpierce3@srv001.trnkmstr.com) |
17:08.19 | Samot | AMI is an outside thing. |
17:08.23 | Samot | From the outside to Asterisk |
17:08.31 | Samot | Dialplan is an inside thing. In the call. |
17:08.49 | Samot | So yes, you would have to maintain two ways of doing this. Because you will have two ways of doing this. |
17:10.04 | kfife | Seems like a missing feature to me. |
17:10.12 | Samot | No. |
17:10.29 | Samot | Look, my users can trigger call forwarding via a feature code. |
17:10.39 | Samot | When they do that, they have to enter digits for that destination. |
17:10.44 | Samot | Dialplan has to deal with that |
17:10.52 | Samot | Or they can use a web GUI that triggers AMI |
17:11.16 | Samot | Which is just submitting the data to AstDB to be looked at in the dialplan. |
17:11.41 | Samot | They both store the information in AstDB, however, how that information is collection and triggered to be stored is two different things. |
17:11.52 | Samot | One is done "in-call" and one is done from the outside. |
17:12.07 | Samot | AMI is meant to take outside actions in inject them into Asterisk. |
17:13.07 | kfife | But not trigger a predefined 'inside' feature? And that's not desirable why? |
17:13.23 | Samot | AMI doesn't execute dialplan like that |
17:13.43 | kfife | And that's not desirable why? |
17:13.59 | Samot | What do you mean? |
17:14.17 | kfife | i.e. manager show command DynamicFeature |
17:14.35 | *** join/#asterisk Oatmeal (Suzeanne@gateway/vpn/privateinternetaccess/suzeanne) |
17:14.42 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
17:14.47 | kfife | this would allow an outside event to trigger a predefined dynamic feature into a specific channel |
17:15.07 | kfife | if within scope to that channel |
17:15.16 | [TK]D-Fender | that there does not |
17:15.22 | kfife | i.e. _myfeature or __myfeature |
17:15.56 | kfife | Sorry. Typo. |
17:16.36 | kfife | _DYNAMIC_FEATURES=myfeature or __DYNAMIC_FEATURES=myfeature |
17:16.40 | Samot | Yes. |
17:17.02 | Samot | A Dynamic Feature lets you _map_ a * code to a function or application in Asterisk. |
17:17.12 | Samot | AMI lets you call on those functions or applications directly |
17:17.19 | Samot | No need to map digits to it. |
17:18.51 | kfife | By that logic, there's no need for more than one turing-complete language. |
17:19.12 | Samot | OK |
17:19.21 | kfife | I guess I should have asked you if you think we need more than one turing complete language ;-) |
17:19.27 | Samot | So far what I've gotten from this is "I don't want to maintain dialplan and AMI code for this" |
17:21.21 | kfife | You are correct. That is exactly what I'm saying. |
17:22.43 | kfife | Ever heard of D.R.Y.? Especially important in something like asterisk where regression testing is a challenge. |
17:24.37 | Samot | Don't Repeat Yourself. |
17:24.39 | Samot | Yes. I have. |
17:24.54 | Samot | So then just have AMI send PlayDTMF to trigger your *3 |
17:25.39 | *** part/#asterisk Ast001 (~uros@p5DCD6D28.dip0.t-ipconnect.de) |
17:27.24 | Samot | At the end of the day, you're still maintaining AMI code in your web GUI code. |
17:27.36 | Samot | No matter if it's just sending *3 or actually triggering apps. |
17:27.52 | Samot | It's not like a class that you can just call on between dialplan and AMI |
17:30.32 | craigify | kfife, you could use AsyncAGI over AMI and implement this in some external software, then trigger it using both dynamic feature codes and via AMI directly? You'd solve your issue by having the code in one place. You'd have to do a lot of legwork though, but you could probably use a async-agi library for your programming language of choice. |
17:30.51 | craigify | It would also help to understand the evolution of Asterisk from a PBX into more like a communications/telephony framework |
17:31.05 | Samot | The code would not be in one place. |
17:31.09 | Samot | That is incorrect. |
17:31.13 | Samot | There is the dialplan. |
17:31.14 | craigify | yes it would |
17:31.23 | Samot | Then there is the code to trigger AMI outside of Asterisk. |
17:31.36 | craigify | yes, you'd have code in many places to handle triggering |
17:31.38 | Samot | Be it using any of the AMI actions like AGI or PlaDTMF |
17:31.40 | craigify | but your business logic could be in one place |
17:31.50 | craigify | are we splitting hairs here? |
17:32.10 | Samot | 1:19:27 PM <Samot> So far what I've gotten from this is "I don't want to maintain dialplan and AMI code for this" |
17:32.10 | Samot | 1:21:22 PM <kfife> You are correct. That is exactly what I'm saying. |
17:32.24 | craigify | well, then it's impossible |
17:32.28 | Samot | My point. |
17:32.39 | craigify | I thinnk he means the business logic |
17:32.47 | Samot | Regardless of what the AMI command is doing... |
17:32.51 | craigify | whatever the thing that the dynamic feature triggers |
17:32.52 | Samot | There's code for it outside of Asterisk |
17:33.07 | Samot | You have to connect, send the commands, logout |
17:33.13 | craigify | yeah, youd have to do all that |
17:33.15 | craigify | right |
17:33.19 | Samot | And of course, deal with those responses. |
17:33.22 | craigify | but then your business logic is in one place |
17:33.38 | craigify | I'm trying to show how that it is possible, but probably not the best choice for one single task |
17:34.05 | craigify | unless there is some larger overall picture here and other features could be developed and implemented |
17:35.34 | kfife | Especially since it seems like ti would be easy to do. |
17:36.19 | craigify | this is getting into more of a fundamental software architecture discussion |
17:36.50 | craigify | IMO, I wouldn't call it 'easy' to implement the way I am saying, but rather an alternative to consider by weighing in other factors in the project as a whole |
17:38.06 | craigify | and it specifically addresses your comment about a missing feature |
17:38.18 | craigify | or well, I was trying to at least |
17:39.42 | kfife | +1 craigify |
17:39.47 | craigify | furthermore, as was said, you'd still have to handle the dynamic feature when it's keyed in, and you'd have to handle the external system to know how and when to trigger some AMI command, and then you'd have your business logic implemented in yet another part that uses both AMI and AsyncAGI to perform the action, and that other part could be called pragmaticaally from a number of different ways |
17:39.50 | Samot | I'm not sure it is. |
17:39.57 | craigify | now, this is starting to get complicated |
17:40.14 | craigify | so, a takeaway message would be, is this complexity worth it? Is it just a simple fix? |
17:40.17 | Samot | AMI is for outside interaction with Asterisk. |
17:40.32 | Samot | AGI / Diaplan is for in-call interaction with Asterisk. |
17:40.37 | craigify | AsyncAGI |
17:40.40 | craigify | over AMI |
17:40.45 | Samot | Sure. |
17:40.46 | craigify | be sure to make the distinction |
17:40.54 | Samot | It's an outside action to trigger an inside action. |
17:40.57 | craigify | using those two things you could build something in NodeJS, or whatever |
17:41.01 | Samot | Still outside of Asterisk. |
17:41.03 | craigify | implement your logic in there |
17:41.05 | craigify | yes it would be |
17:41.15 | craigify | I'm not arguing your point there |
17:41.18 | Samot | I can make it so my users can do things via the dialplan. |
17:41.27 | Samot | And a GUI using AMI |
17:41.30 | Samot | Or one or the other. |
17:41.32 | craigify | ok, also a suggestion |
17:41.49 | craigify | you'll run into issues with the Dial application when in a bridged call though |
17:41.54 | craigify | blocking the dialplan |
17:42.12 | craigify | hence the need for dynamic features in the first place |
17:43.05 | Samot | A dynamic feature is to map digits to application/functions. |
17:43.13 | Samot | So when I dial *3 it does something. |
17:43.44 | Samot | I can make it so *3 does something different for every call |
17:43.47 | Samot | Or user.. |
17:44.07 | Samot | Just all depends on what is what. |
17:44.16 | Samot | And how you configure things. |
18:00.00 | igcewieling | *sigh* To day we are installing at a site which uses different ISPs depending on where you are physically located in the building. |
18:00.50 | Samot | Fun |
18:01.04 | igcewieling | Apparently it was too much trouble to run a line to a different floor. |
18:16.20 | *** join/#asterisk sebastienthiry (~Thunderbi@109.134.212.7) |
18:17.47 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
18:23.19 | *** join/#asterisk tonsofpcs (~mythbuntu@rivendell/member/tonsofpcs) |
18:40.30 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
18:54.44 | kfife | craigify: I wonder if there are special shoes for digging in one's heels. :-) |
19:19.34 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
19:27.10 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-103-241-71.ks.ok.cox.net) |
19:29.06 | *** join/#asterisk AntonioTejeda86 (~antonio@187-162-76-72.static.axtel.net) |
19:30.12 | AntonioTejeda86 | What is the purposse of this chat? |
19:30.28 | AntonioTejeda86 | can we share doubts about asterisk? |
19:30.50 | [TK]D-Fender | We do't generally have doubts about it |
19:30.56 | [TK]D-Fender | We kinda just use it... |
19:31.12 | [TK]D-Fender | This is a place to talk ABOUT it though.... |
19:32.50 | craigify | lol |
19:34.00 | AntonioTejeda86 | Ok, so I've been using Asterisk 6 years ago I'm Dcap, so nice to meet you all, whatever the purposse this chat has lol |
19:34.30 | craigify | It's usually people coming in here and asking all sorts of questions |
19:35.18 | [TK]D-Fender | <[TK]D-Fender> This is a place to talk ABOUT it though.... |
19:35.32 | craigify | I, for one, really like Asterisk, and I'm glad it exists. I've based a cloud based telephony project on Asterisk and rely on it every day in a production environment, as do lots of others in here from what I can tell. |
19:35.51 | craigify | do I think it's perfect? No software is. |
19:54.22 | *** join/#asterisk WizJin (~Ozzy@150.129.105.149) |
19:54.36 | WizJin | Hello |
19:58.57 | *** join/#asterisk jkroon (~jkroon@165.16.204.171) |
19:59.18 | *** join/#asterisk rrittgarn (~rrittgarn@75-150-221-205-Illinois.hfc.comcastbusiness.net) |
20:00.48 | *** join/#asterisk dacleaner (~dacleaner@12.229.24.212) |
20:22.09 | *** join/#asterisk Oatmeal (~Suzeanne@66-214-156-171.static.mtpk.ca.charter.com) |
20:49.07 | *** join/#asterisk war9407 (war@pool-70-106-236-148.clppva.fios.verizon.net) |
20:53.04 | *** join/#asterisk CatCow97 (~mine9@c-24-22-38-85.hsd1.or.comcast.net) |
20:55.35 | *** join/#asterisk Typhon (~Typhon@ipservice-092-211-209-209.092.211.pools.vodafone-ip.de) |
21:08.41 | *** join/#asterisk Oatmeal (Suzeanne@gateway/vpn/privateinternetaccess/suzeanne) |
21:27.39 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
22:06.14 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
22:20.22 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:b88f:115c:5675:b5f7) |
22:31.10 | *** join/#asterisk bmg505 (~leon@196-210-23-42.dynamic.isadsl.co.za) |
23:02.55 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.26) |
23:12.19 | drmessano | I doubt Asterisk even exists |
23:12.55 | drmessano | I once opened Mark Spencer's vault, looking for Asterisk |
23:12.58 | drmessano | and it was EMPTY |
23:51.23 | *** part/#asterisk kharwell (kharwell@nat/digium/x-ejzagrpusbzllfno) |
23:55.45 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |