00:00.40 | *** join/#asterisk jrabe (irc@janikrabe.com) |
00:05.51 | nafg | fauxalliance: [TK]D-Fender: how do I file a bug? Is there a public issue tracker? |
00:07.29 | nafg | nm |
00:22.05 | fauxalliance | DUPLICATE THE BUG, mais n'existe PAS |
00:35.45 | nafg | ? |
00:49.47 | *** join/#asterisk tuxd00d (~tuxd00d@wsip-24-248-81-186.ph.ph.cox.net) |
01:05.16 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
01:18.12 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
01:28.21 | *** join/#asterisk robinak (~quassel@unaffilated/robink) |
01:57.12 | *** join/#asterisk cryptic (~cryptic@142.196.170.87) |
01:58.43 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
02:18.02 | *** join/#asterisk robinak (~quassel@unaffilated/robink) |
02:26.01 | Korolev | is there any configuration setting or function or dial parameter in Asterisk that is equivalent to freeswitch's progress_timeout? |
02:26.29 | Korolev | all I can find on google is a request for such feature back in 2005 |
02:46.23 | *** join/#asterisk Juggie (~Juggie@unaffiliated/juggie) |
02:57.29 | *** join/#asterisk mmlj4 (~mmlj4@47-44-49-2.static.unas.mo.charter.com) |
03:05.29 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
03:17.29 | *** join/#asterisk _r0ck_p3arl_ (~admin@203.149.66.146) |
03:33.40 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
03:33.48 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
03:58.05 | *** join/#asterisk mmlj4 (~mmlj4@47-44-49-2.static.unas.mo.charter.com) |
04:23.42 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
05:20.47 | *** join/#asterisk mmlj4 (~mmlj4@47-44-49-2.static.unas.mo.charter.com) |
05:26.33 | *** join/#asterisk bmg505 (~leon@196-210-200-216.dynamic.isadsl.co.za) |
05:30.52 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
05:36.55 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
05:54.39 | *** join/#asterisk evil_gordita (~evilgordi@ip70-188-41-127.rn.hr.cox.net) |
05:54.50 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
05:57.51 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
06:07.57 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
06:08.56 | *** join/#asterisk ganbold (~ganbold@173.244.215.173) |
06:13.30 | *** join/#asterisk sekil (~sekil@cable-89-216-221-33.dynamic.sbb.rs) |
06:37.13 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
06:39.45 | *** join/#asterisk miralin (~Thunderbi@195.209.246.243) |
07:12.19 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
07:15.58 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
07:36.35 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
07:37.49 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
07:37.51 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
07:51.03 | *** join/#asterisk yoavz (~yoavz@white.blackit.io) |
08:15.13 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
08:33.14 | stefan27 | My understanding of default SIP authentication is that in such a transaction the client responds to challenge via a response field essentially (simplified) calculated as MD5(secret+<some public string>). The public string is public to anyone who can view the SIP messages, but it may vary from transaction to transaction (it may contain server and client nonce). Now the response is a 128 bit |
08:33.14 | stefan27 | value, and an attacker who can inspect the SIP message transaction can use brute force to find the (probably unique) secret string of length 8-14 chars that produces the given md5-response, but he could not do that if the secret itself had much greater entropy than 128 bits, say 30 alphanumerical chars? |
08:33.29 | stefan27 | My question then is why does the common recommendation for password seems to be 8-14 random chars rather than say 32? I'm aware md5 is old and one should ideally use an encrypted transport. I wonder whether long passwords is a feasible work-around when one does not have tls or restrict-by-src-ip mechanisms |
09:17.24 | *** join/#asterisk miralin (~Thunderbi@195.209.246.243) |
09:32.51 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
09:56.06 | TandyUK | anyone know a uk supplier (other than voipon) that stock mediatrix gateways? |
09:56.12 | TandyUK | not finding much via google :( |
10:02.36 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
10:08.04 | *** join/#asterisk troyt (~troyt@c-73-65-211-33.hsd1.ut.comcast.net) |
10:25.20 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
10:34.01 | *** join/#asterisk TandyUK (~admin@2a02:13a0:a006:1:b4f8:8786:220b:5d0f) |
10:54.08 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
10:56.10 | *** join/#asterisk TandyUK2 (~admin@2a02:13a0:a006:1:b4f8:8786:220b:5d0f) |
11:23.29 | *** join/#asterisk TandyUK (~admin@2a02:13a0:a006:1:b4f8:8786:220b:5d0f) |
11:41.52 | *** join/#asterisk TandyUK2 (~admin@2a02:13a0:a006:1:b4f8:8786:220b:5d0f) |
12:18.20 | Samot | stefan27: The auth digest hash is more than just an md5() string that secret+some string |
12:18.25 | Samot | stefan27: The auth digest hash is more than just an md5() string that's secret+some string |
12:23.53 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
12:33.47 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
12:36.56 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
12:53.04 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
13:11.53 | *** join/#asterisk TandyUK (~admin@2a02:13a0:a006:1:b4f8:8786:220b:5d0f) |
13:15.02 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
13:22.02 | *** join/#asterisk bittis (~bittis@139.255.94.210) |
13:23.20 | bittis | hey guys, random question, with asterisk 13 you can get a unique call id in the logs, as specified here: https://wiki.asterisk.org/wiki/display/AST/Unique+Call-ID+Logging , is anyone aware if this value can be retrieve from a variable and added to custom logs? |
13:24.01 | Samot | Every SIP message has a Call-ID |
13:24.15 | Samot | It's part of how dialog is tracked and how messages are tracked. |
13:24.42 | Samot | And yes, Call-ID is a channel variable for SIP channels. |
13:24.58 | file | the above is unrelated to SIP, and it can be retrieved from the dialplan using ${CHANNEL(callid)} |
13:25.14 | Samot | There you go, all channels have it. |
13:25.37 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
13:26.36 | bittis | as i understand it gets generated when a channel is first created and should be the same across the lifetime of the call, even with bridged calls etc, right? |
13:27.26 | file | yes |
13:28.28 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
13:42.21 | bittis | hmm, not ${CHANNEL(callid)} |
13:42.28 | bittis | case sensitive? |
13:44.57 | file | that is what it is according to the documentation and code |
13:48.26 | *** join/#asterisk mmlj4 (~mmlj4@47-44-49-2.static.unas.mo.charter.com) |
13:53.34 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
14:02.13 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
14:03.00 | bittis | how safe is it to update the func_channel.so module manually rather than updating asterisk completely? |
14:03.29 | Samot | OK before you start changing system core stuff. |
14:03.35 | Samot | Why don't you show your dialplan |
14:03.46 | Samot | And the output of your attempt to get this variable. |
14:03.57 | Samot | ~pb |
14:03.58 | infobot | extra, extra, read all about it, pastebin is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
14:04.46 | bittis | actually on Asterisk 13.12.1 |
14:04.58 | bittis | https://issues.asterisk.org/jira/browse/ASTERISK-26878 |
14:05.06 | bittis | according to this need to move a bit up |
14:05.46 | Samot | Yes, being on the versions that have this feature would be helpful. |
14:07.00 | bittis | guessing overwritting the existing .so file with the latest one is wishful thinking then :) |
14:07.12 | Samot | What? |
14:07.24 | Samot | You're going to re-compile when you update. |
14:07.33 | bittis | would updating overwrite any /etc/asterisk files? |
14:07.34 | Samot | So yes, it's going to overwrite the existing .so |
14:07.39 | Samot | No. |
14:07.58 | Samot | It may add new stuff if you don't have it but it's not going to trash your .confs |
14:08.00 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
14:08.00 | *** mode/#asterisk [+o bford] by ChanServ |
14:08.06 | Samot | That being said, you should always back up your shit. |
14:08.12 | bittis | always :) |
14:10.51 | *** join/#asterisk kharwell (kharwell@nat/digium/x-bwxililqodxkybtp) |
14:10.51 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:14.32 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
14:15.43 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-mbtiyhjupiwexhgl) |
14:15.44 | *** mode/#asterisk [+o rmudgett] by ChanServ |
14:15.53 | *** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132) |
14:21.32 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:30bd:d471:2b1e:a682) |
14:54.23 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
15:04.42 | qakhan | hi all. i am trying to register SIP trunk. but its not registering. here is my sip debug https://pastebin.com/3nuZxw52 |
15:07.55 | [TK]D-Fender | Contact: <sip:s@192.168.10.106:5060> <- You're very obviously giving them a garbage PRIVATE IP as the contact |
15:08.58 | Samot | And not sending back a proper auth challenge response. |
15:09.07 | [TK]D-Fender | Start by not screwing up the basics |
15:11.15 | qakhan | but 192.168.10.106 my system iP |
15:11.27 | Samot | But it's not your WAN IP |
15:11.45 | Samot | You are clearly behind NAT, so you should have Asterisk setup as such. |
15:12.43 | qakhan | you mean in sip.conf NAT SUPPORT ? |
15:12.45 | Samot | But on top of that, your REGISTER response to the 401 Unauthorized has *zero* auth details in it. So that is completely wrong. |
15:15.21 | [TK]D-Fender | qakhan, they need your PUBLIC IP to send you calls and you've screwed up the very basics. |
15:15.26 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
15:15.26 | *** mode/#asterisk [+o cresl1n] by ChanServ |
15:15.42 | Samot | Well until a proper REGISTER response is sent.. |
15:15.44 | [TK]D-Fender | qakhan, My phone has an "extension" of 100 that the guy sitting next to me can dial. |
15:15.46 | Samot | That isn't going to matter. |
15:15.49 | [TK]D-Fender | YOU try calling me now! |
15:15.58 | [TK]D-Fender | Go dial 100. Is MY phone going to ring? |
15:16.01 | [TK]D-Fender | Grab yours right now |
15:16.36 | qakhan | [TK]D-Fender yes i can dial if we have a sip trunk |
15:16.44 | qakhan | otherwise no |
15:16.48 | Samot | FFS. |
15:17.01 | Samot | qakhan: You have network setting issues |
15:17.08 | [TK]D-Fender | Well your provider sure as hell can't send packets to your PRIVATE IP and expect them to end up at your server |
15:17.12 | Samot | qakhan: Your trunk is not configured properly |
15:17.17 | Samot | Those are you two main issues. |
15:18.41 | Samot | As well, Vitelity IS replying to your REGISTER request. |
15:19.01 | Samot | But your trunk is not configured right. So it never RESPONDS right. |
15:19.20 | [TK]D-Fender | ? |
15:19.27 | Samot | Look at the debug. |
15:19.33 | [TK]D-Fender | I'm not getting what you're alluding to in that last one |
15:19.47 | [TK]D-Fender | with regards to "trunk" not being right |
15:19.49 | Samot | Vitelity is sending 401 Unauthorized's back to the PBX |
15:20.04 | Samot | The PBX is responding with a new REGISTER like it should. |
15:20.15 | Samot | However, there is ZERO auth digest creds with it. |
15:20.19 | Samot | So improper reply. |
15:20.22 | [TK]D-Fender | What precisely are you referring to by "trunk"? |
15:20.32 | Samot | His f'ig Vitelity trunk. |
15:20.39 | [TK]D-Fender | what CONSTRUCT? |
15:20.41 | Samot | That should have a register string. |
15:20.46 | Samot | IN THE PBX |
15:20.50 | Samot | FFS. |
15:21.00 | Samot | He's not responding to the AUTH PROPERLY |
15:21.14 | [TK]D-Fender | Register string stands ALONE. It does not tie to a PEER |
15:21.26 | Samot | OH GOOD GOD |
15:21.30 | Samot | Whatever. |
15:22.40 | [TK]D-Fender | the REGISTER string does not check or validate against a PEER. it does it's ENTIRE job alone. |
15:22.48 | [TK]D-Fender | Using terms like "trunk" don't factor in |
15:22.50 | [TK]D-Fender | it;'s ONE line |
15:22.52 | Samot | You're missing the point. |
15:23.05 | [TK]D-Fender | All the auth you're gonna get is on that one line with no relation to anything else |
15:23.14 | Samot | Missing the point. |
15:23.20 | [TK]D-Fender | DON'T FUCKING SAY TRUNK OR THESE FUCKERS WILL START LOOKING AT THEIR PEERS |
15:23.29 | [TK]D-Fender | Eye on the target |
15:23.34 | [TK]D-Fender | ^ |
15:23.41 | [TK]D-Fender | Contact is bad. |
15:23.44 | Samot | #Irony |
15:23.47 | [TK]D-Fender | Register string quite possibly bad. |
15:23.48 | Samot | So f'ing WHAT |
15:23.52 | [TK]D-Fender | that we can work with |
15:24.08 | Samot | If the contact was correct it still wouldn't fix the fact it's not registering.. |
15:24.13 | Samot | And why is it not registering? |
15:24.23 | Samot | Because the AUTH CHALLENGE IS NOT RIGHT |
15:24.33 | Samot | Eye on the target. |
15:24.52 | qakhan | this is my sip.conf NAT setting https://pastebin.com/THk0ZiT0 |
15:25.11 | qakhan | is it correct? |
15:25.36 | Samot | qakhan: Show your sip.conf |
15:26.35 | qakhan | should i get sip show settings? |
15:26.49 | Samot | You should copy and paste what you have in sip.conf |
15:26.54 | Samot | I want to see if you have this correct. |
15:28.22 | qakhan | i am using default sip.conf which is pretty big. but i will copy it |
15:29.08 | Samot | That's fine. |
15:32.42 | qakhan | here https://pastebin.com/DpmYgBFm |
15:33.37 | Samot | OK. |
15:34.02 | Samot | So first, you really should get rid off all that garbage. The idea was to give you a reference point.. |
15:34.22 | Samot | Not fill your conf files will not needed junk. |
15:34.50 | qakhan | ok |
15:36.33 | Samot | Like register strings don't go in [general] |
15:36.58 | Samot | That would imply *every* Chan_SIP device will use it. |
15:38.36 | qakhan | ok. so do you think my NAT settings are correct? |
15:40.18 | Samot | No. |
15:40.22 | Samot | You're behind NAT |
15:40.27 | Samot | You have no NAT setting. |
15:42.12 | qakhan | Yes i am behind the NAT (Cisco Router) |
15:44.47 | qakhan | but i set setting in NAT settings in sip.conf localnet=192.168.10.106/255.255.255.0 externaddr = 50.203.177.21 |
15:47.04 | Samot | Read more. |
15:47.06 | Samot | That is nat= |
15:47.11 | Samot | You need to set that at least. |
15:54.19 | qakhan | is there any setting on Router side? |
16:16.39 | *** join/#asterisk skywayskase (~skywayska@163.182.162.226) |
16:27.26 | *** join/#asterisk miralin (~Thunderbi@91.237.94.6) |
16:27.30 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
16:58.01 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
16:58.01 | *** mode/#asterisk [+o cresl1n] by ChanServ |
17:03.56 | *** join/#asterisk miralin (~Thunderbi@91.237.94.6) |
17:42.13 | *** join/#asterisk DtC (~DtC@47.201.36.60) |
17:45.24 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
17:45.24 | *** join/#asterisk ClearDark (~ClearDark@81.171.71.134) |
17:47.01 | ClearDark | hello, quick question, is there any way to send udp packets from an asterisk extenion to a remote server without clogging the dialplan? just send packet and continue regular execution. (any other forms of passing data between two machines on an incoming call besides AGI/AMI would be welcomed warmly :P) |
17:49.58 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
17:51.47 | Korolev | using curl to a rest service that returns immediately and handles the udp request outside of asterisk? |
17:53.23 | Korolev | you won't know if it was successful during the rest of the dialplan execution, but that's a way to do it |
17:54.10 | [TK]D-Fender | ClearDark, What do you mean by no "clogging the dialplan"? |
17:55.28 | Korolev | I think he was asking a couple of days ago because he was trying to run a shell command from the dialplan to send data to a udp port and it was blocking |
17:55.36 | Samot | ClearDark: Asterisk will not trigger an OPTIONS during dialplan execution. |
17:55.59 | Samot | You have to do that and Asterisk doesn't send SIP messages like that from the dialplan during an active call. |
17:56.10 | ClearDark | yea it blocked using System() and running a shell script |
17:56.12 | ClearDark | using nc |
17:56.20 | ClearDark | no i understand that Samot |
17:56.23 | Samot | That's not Asterisk sending it. |
17:56.26 | Samot | That's the system. |
17:56.29 | ClearDark | i just wanna send iut out |
17:56.39 | ClearDark | the data.. |
17:56.40 | Samot | What about the reply? |
17:56.49 | ClearDark | i dont need a reply. |
17:56.51 | Korolev | my view would be put in on a queue somewhere, and handle it outside |
17:57.11 | Korolev | unless you need to know the status during the rest of the dialplan |
17:57.11 | ClearDark | thats what im trying to do, sending a udp packet to a local server |
17:57.15 | Samot | What type of packet are you sending? |
17:57.21 | ClearDark | udp |
17:57.24 | ClearDark | about 30 bytes |
17:57.26 | Samot | For what? |
17:57.33 | ClearDark | callerid, call id |
17:57.35 | Samot | Is it a SIP message... |
17:57.40 | ClearDark | no |
17:57.50 | ClearDark | i need it for external logging, what does it matter? |
17:58.01 | Samot | Well why are you using UDP for that? |
17:58.05 | ClearDark | its fast. |
17:58.10 | Samot | If you're sending it to a server that is logging something.. |
17:58.13 | Korolev | also unreliable as all hell |
17:58.16 | Samot | ^^^ |
17:58.20 | ClearDark | i dont need reliability |
17:58.25 | Samot | Not to mention most things that log are TCP |
17:58.26 | Samot | ... |
17:58.27 | Samot | What? |
17:58.27 | ClearDark | i understand the implications of udp |
17:58.32 | Samot | OK. |
17:58.39 | ClearDark | it works well for my needs |
17:58.46 | ClearDark | like i said, other suggestions are more than welcome |
17:59.02 | ClearDark | how to send the data out to a remote machine as fast as possible |
17:59.03 | Samot | So you need to log data but it doesn't need to do it reliably? |
17:59.23 | ClearDark | yes |
17:59.33 | Korolev | wait, is this because you are expecting a giant volume of calls and want to post CDRs as fast as possible? |
17:59.33 | ClearDark | reliability is not a factor here |
17:59.33 | Samot | Well UDP isn't the first choice. |
17:59.45 | ClearDark | no, im logging CDR to mysql already |
17:59.51 | Samot | So why even bother? |
17:59.59 | ClearDark | i dont wanna query the entire mysql table |
18:00.01 | Samot | If it doesn't matter if the log data makes it or not.. |
18:00.03 | ClearDark | every few seconds |
18:00.06 | ClearDark | its huge |
18:00.12 | Korolev | or why do it during the dialplan if you already have the data somewhere else? |
18:00.17 | Samot | What is "huge"? |
18:00.26 | ClearDark | the table containing the cdr data |
18:00.30 | ClearDark | i can iterate on that |
18:00.33 | ClearDark | but its expensive. |
18:00.33 | Samot | You realize MySQL is meant to process large volumes of queries quickly. |
18:00.34 | Korolev | why is it a single table? |
18:00.43 | Korolev | that's the first NO right there |
18:00.53 | Korolev | cdr tables are never a single table |
18:00.55 | Samot | Huh? |
18:01.03 | Korolev | use a table per peroid |
18:01.11 | Samot | what?! |
18:01.12 | Korolev | it will make it way faster to query later |
18:01.24 | ClearDark | i didnt ask for advice |
18:01.25 | ClearDark | on that |
18:01.29 | ClearDark | i asked something very specific |
18:01.31 | Korolev | oh I'm sorry |
18:01.48 | Samot | I think you're on your own. |
18:02.02 | Samot | Everyone else has been pretty clear that what you are doing isn't the best option. |
18:02.29 | ClearDark | thanks for your time then :) |
18:02.52 | Samot | Well.. |
18:02.56 | Samot | Do it a way that everyone else does |
18:02.59 | Samot | You know, standard. |
18:03.15 | Samot | Using UDP for logging like this is not how it is done. |
18:03.16 | ClearDark | i have reasons for what im trying to do... |
18:03.21 | Samot | I'm sure you do. |
18:03.22 | ClearDark | its not for logging. |
18:03.27 | Samot | OK. |
18:03.29 | ClearDark | i dont save that data |
18:03.30 | ClearDark | its discarded |
18:03.35 | ClearDark | i process it right away and throw it away |
18:03.39 | Korolev | we are not questioning your reasons, just trying to offer advice |
18:03.51 | ClearDark | i know..im saying that querying mysql is a bad option for me at the moment. |
18:03.57 | Korolev | but you seem to have cornered yourself into a solution |
18:03.58 | ClearDark | looking for alternatives. |
18:04.10 | ClearDark | i could care less if its udp |
18:04.15 | ClearDark | or any thing means of transporting data |
18:04.25 | ClearDark | just looking for a way thats all.. |
18:04.43 | Samot | Well we have no idea what the other side is. |
18:04.46 | Samot | What it is doing |
18:04.58 | Samot | So how to offer you any advice on how to improve it, kind of hard. |
18:04.59 | Korolev | why can't it be AGI? |
18:05.05 | Samot | Why? |
18:05.09 | Samot | AGI isn't needed for this. |
18:05.22 | ClearDark | Samot- the receiving end has no 'business' in this problem... |
18:05.26 | Korolev | well, if he wants to avoid local databases |
18:05.32 | Samot | What? |
18:05.34 | ClearDark | it gets the data, 'consumes' it, and thats all |
18:05.43 | Korolev | he could use AGI and something like memcache or one of it's relatives |
18:05.56 | Korolev | and then query that and post multiple rows at a time to a rest service |
18:06.03 | Samot | So.. |
18:06.04 | Korolev | it makes it fast |
18:06.11 | ClearDark | what data is available to me through AGI? |
18:06.12 | Samot | Are you sending the data via a RESTful API? |
18:06.18 | sekil | syslog? |
18:06.20 | Samot | Are you sending it to MySQL server? |
18:06.37 | ClearDark | currently im sending it using a simple shell script |
18:06.41 | ClearDark | running netcat |
18:07.05 | Samot | How does the other side "consume" the data? |
18:07.10 | ClearDark | - /bin/echo -n $1 | nc -4u -q1 10.0.0.5 33333 |
18:07.13 | ClearDark | what does it matter??? |
18:07.19 | Samot | Of course. |
18:07.22 | Samot | How could that matter. |
18:07.49 | Samot | How could helping you get data from Server A to Server B require knowing how Server B accepts that data. |
18:07.51 | Samot | Silly me. |
18:08.03 | ClearDark | it can accept it any way it needs to |
18:08.08 | ClearDark | be it a udp server |
18:08.18 | ClearDark | or whatever, im open ot suggestions. |
18:08.19 | Samot | You just said you don't have to use UDP |
18:08.27 | ClearDark | u asked how it works now. |
18:08.50 | Samot | UDP is not how it consumes it |
18:08.52 | ClearDark | server a has a simple udp server in node, listening on port 33333. |
18:08.57 | Samot | OK |
18:09.05 | Korolev | UDP seems to me like you are optimizing the wrong part of it |
18:09.13 | ClearDark | voip server uses shell script with above command to send to server A a udp packet |
18:09.42 | Korolev | you are still invoking a shell process for every cdr |
18:09.54 | ClearDark | ill say again, i can skip udp all together, im open to any idea if it gets the job done |
18:09.58 | ClearDark | my limitations are mysql. |
18:10.13 | Korolev | okay, follow me for a second |
18:10.18 | ClearDark | alright. |
18:10.20 | Korolev | I know you didn't ask for advice about this |
18:10.23 | Korolev | but hear me out |
18:10.55 | Korolev | the reason you don't want to take the data out of mysql and use that for your logging or whatever it is you do with it |
18:11.06 | Korolev | is because you don't want to query the cdr table frequently |
18:11.09 | Korolev | yes? |
18:11.17 | ClearDark | yes. |
18:11.22 | Korolev | I assume because it's too big to query frequently, which makes total sense |
18:11.29 | ClearDark | no. |
18:11.45 | Korolev | then why not? |
18:11.48 | *** join/#asterisk corretico_ (~corretico@200.91.143.34) |
18:12.02 | ClearDark | its because polling mysql will eventually make the result in "batches" |
18:12.12 | ClearDark | i need an "event" driven system "like" |
18:12.25 | Korolev | ah! |
18:12.41 | Korolev | you need to get the cdr WHEN the call arrives |
18:12.51 | ClearDark | yes |
18:12.55 | Samot | Uhm. |
18:13.01 | ClearDark | i dont need the cdr. i just need the caller id |
18:13.12 | Samot | That's a channel variable. |
18:13.16 | Korolev | this sounds interesting |
18:13.17 | ClearDark | and a few more extra bytes of data for that specific extensions (static data) |
18:13.18 | sekil | isn't ami used for that interfacing better |
18:13.23 | Korolev | this sounds like a dirty route |
18:13.23 | Samot | It's a channel variable. |
18:13.31 | ClearDark | AMI causes insane performence issues for me |
18:13.58 | Samot | ClearDark: So you need the CallerID? |
18:14.01 | Korolev | you know the caller id where? |
18:14.03 | Samot | That's it? |
18:14.06 | ClearDark | yes |
18:14.07 | *** join/#asterisk miralin (~Thunderbi@91.237.94.6) |
18:14.09 | Samot | OK |
18:14.17 | ClearDark | i get it with ${CALLERID(num)} |
18:14.22 | Samot | OK. |
18:14.39 | Samot | So you can use System() to send an RESTful API call to the other server. |
18:14.43 | Korolev | so you need the remote server to know the callerid of the call that just came in? |
18:14.51 | ClearDark | Korolev - exactly |
18:14.54 | Samot | So you can use System() to send an RESTful API call to the other server. |
18:15.01 | ClearDark | Samot - i did that with a udp packet - it hung the whole dialplan up |
18:15.12 | Samot | RESTful doesn't use UDP |
18:15.16 | ClearDark | i know |
18:15.22 | Samot | Because it's HTTP/HTTPS which is TCP |
18:15.23 | Korolev | I second the rest idea |
18:15.25 | Samot | So make the call RIGHT |
18:15.36 | Korolev | you just need to return the rest request right away |
18:15.49 | Samot | He doesn't need to return anything at all |
18:15.52 | Korolev | and then do your processing outside |
18:15.53 | Samot | POST does't need a reply |
18:16.06 | ClearDark | i have this in some extensions |
18:16.07 | ClearDark | exten => +xxxx,1,System(curl -X GET 'https://xxx.com/rid=${UNIQUEID}') |
18:16.15 | Samot | Why are you using GET? |
18:16.19 | ClearDark | lol. |
18:16.26 | Korolev | no no, I meant return as in the method in the implementation needs to return right away |
18:16.26 | Samot | You're POSTing. |
18:16.36 | ClearDark | Korolev - i got what u ment |
18:17.05 | Korolev | grab your data, spawn a new thread, return |
18:17.06 | ClearDark | guess ill just change node from udp to express. |
18:17.19 | *** join/#asterisk babcka87 (~bacbka@5.145.242.42) |
18:17.33 | ClearDark | ill give that a shot |
18:17.42 | Korolev | and I would use curl instead of a system call |
18:17.45 | ClearDark | i really doubt POSTing or GETing makes a difference |
18:17.47 | Korolev | system calls make me jittery |
18:17.56 | ClearDark | how? |
18:18.00 | Korolev | I don't have a reason to back that up |
18:18.05 | Korolev | they just make me jittery |
18:18.09 | Samot | Well.. |
18:18.14 | ClearDark | how do u use curl |
18:18.16 | ClearDark | instead of a syscall |
18:18.17 | Samot | POST is generally one way |
18:18.35 | Samot | GET means you're excepting to get data back. |
18:19.03 | ClearDark | its http, both of them have to return 200. |
18:19.29 | ClearDark | so both of them are 'expecting' a result. the action verbs are just...verbs. |
18:19.52 | Korolev | yeah it won't matter, and it isn't a lot of data |
18:20.19 | ClearDark | so how to curl |
18:20.22 | ClearDark | instead of System? |
18:20.51 | Samot | https://wiki.asterisk.org/wiki/display/AST/Function_CURL |
18:21.06 | sekil | I wonder why is AMI non-performant |
18:21.07 | babcka87 | Hello |
18:21.12 | ClearDark | u da man. |
18:21.18 | babcka87 | Sorry, plz help me |
18:21.34 | ClearDark | sekil - i wondered that too, it just makes my server shit itself |
18:21.42 | sekil | although ARI should be better |
18:21.59 | Korolev | Set(SOMEVAR=${CURL(http://someserver:port/someresource/?blah=1&bleh=${THISVARIABLE}&bloh=${THATVARIABLE})}); |
18:22.02 | Korolev | there is an example |
18:22.04 | babcka87 | in first time i try to set up asterisk now and make a call |
18:22.22 | ClearDark | "Please don't spread lots of direct HTTP calls throughout your application. There are cross-cutting concerns with accessing the API that you'll want to deal with in a central location. Today, the only concern is authentication. But as the API evolves, other concerns (such as versioning) will also be important." |
18:22.47 | ClearDark | ARI... |
18:23.31 | *** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132) |
18:26.39 | babcka87 | https://pastebin.com/tVBN8XZd |
18:26.47 | babcka87 | this my pjsip log |
18:26.55 | babcka87 | i try to make a call |
18:27.33 | Korolev | you need to crate a TRUNK |
18:27.36 | Korolev | cue outrate :D |
18:27.41 | Korolev | outrage too* |
18:29.22 | [TK]D-Fender | You're trying to register and failing |
18:29.26 | [TK]D-Fender | you're trying to call and failing |
18:29.29 | [TK]D-Fender | both say NO AUTH |
18:29.38 | [TK]D-Fender | the credentials aren't matching on both sides |
18:30.23 | babcka87 | https://pastebin.com/5VPPu6sA |
18:30.30 | babcka87 | my pjsip conf file |
18:30.39 | babcka87 | where the mistake |
18:31.47 | [TK]D-Fender | that is only HALF of the picture |
18:34.30 | [TK]D-Fender | dasallow=all <- clearly bad |
18:35.17 | *** join/#asterisk jkroon (~jkroon@165.16.204.165) |
18:40.41 | babcka87 | but i set user=6001 password=6001 |
18:41.40 | [TK]D-Fender | FIX THAT LINE |
18:42.07 | babcka87 | could i have made a mistake? |
18:42.27 | babcka87 | in sipphone |
18:42.42 | [TK]D-Fender | <[TK]D-Fender> that is only HALF of the picture |
18:43.33 | babcka87 | what is: "dassalow = all''? What is this meen? |
18:44.07 | [TK]D-Fender | It means nothing |
18:44.12 | [TK]D-Fender | because that isn't a SETTING |
18:46.52 | babcka87 | disallow? |
18:47.43 | [TK]D-Fender | I think you should seriously re-read your configs and pay REALLY close attention to spelling. This isn't the first misktake like this |
18:50.54 | babcka87 | [TK]D-Fender: ok |
18:56.15 | babcka87 | [TK]D-Fender: YES! I've made it! |
18:56.23 | babcka87 | [TK]D-Fender: Thanks |
19:33.48 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
19:39.14 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
19:39.14 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
19:42.05 | *** join/#asterisk ipengineer (~anonymous@66-196-30-26.static.grandenetworks.net) |
20:00.04 | *** join/#asterisk NirS (~nirs@87.69.215.252) |
20:02.39 | *** join/#asterisk ipengineer (~anonymous@66-196-30-26.static.grandenetworks.net) |
20:08.34 | *** part/#asterisk babcka87 (~bacbka@5.145.242.42) |
20:14.19 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
20:26.39 | *** join/#asterisk miralin (~Thunderbi@91.237.94.6) |
20:27.18 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
20:58.51 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
21:00.09 | *** join/#asterisk skywayskase (~skywayska@163.182.162.226) |
21:06.34 | *** join/#asterisk ipengineer (~anonymous@66-196-30-26.static.grandenetworks.net) |
21:06.55 | *** join/#asterisk startledmarmot (~startledm@static-47-180-86-65.lsan.ca.frontiernet.net) |
21:09.34 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
21:13.04 | *** join/#asterisk tzafrir (~tzafrir@212.29.194.37) |
21:13.28 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
21:20.49 | *** join/#asterisk RovingWriter (~RovingWri@unaffiliated/rovingwriter) |
21:29.58 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
21:47.21 | *** join/#asterisk _r0ck_p3arl_ (~admin@203.149.66.146) |
21:48.01 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
21:52.00 | *** join/#asterisk Morfeus^ (~csurlee@HSI-KBW-095-208-250-103.hsi5.kabel-badenwuerttemberg.de) |
21:57.45 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
22:05.34 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
22:12.39 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
22:22.39 | *** join/#asterisk mmlj4 (~mmlj4@47-44-49-2.static.unas.mo.charter.com) |
22:36.02 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
22:48.47 | *** join/#asterisk Penguin (~xwQ5kwYl6@2001:470:1f07:26d:20c:29ff:fe62:be33) |
23:21.03 | *** join/#asterisk skywayskase (~skywayska@163.182.162.226) |
23:26.20 | *** part/#asterisk kharwell (kharwell@nat/digium/x-bwxililqodxkybtp) |
23:28.14 | *** join/#asterisk davidbowlby (~textual@99-67-53-141.lightspeed.clmboh.sbcglobal.net) |
23:51.42 | *** join/#asterisk skywayskase (~skywayska@163.182.162.226) |