IRC log for #asterisk on 20171019

00:00.40*** join/#asterisk jrabe (irc@janikrabe.com)
00:05.51nafgfauxalliance: [TK]D-Fender: how do I file a bug? Is there a public issue tracker?
00:07.29nafgnm
00:22.05fauxallianceDUPLICATE THE BUG, mais n'existe PAS
00:35.45nafg?
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.01Korolevis there any configuration setting or function or dial parameter in Asterisk that is equivalent to freeswitch's progress_timeout?
02:26.29Korolevall 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.14stefan27My 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.14stefan27value, 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.29stefan27My 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.06TandyUKanyone know a uk supplier (other than voipon) that stock mediatrix gateways?
09:56.12TandyUKnot 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.20Samotstefan27: The auth digest hash is more than just an md5() string that secret+some string
12:18.25Samotstefan27: 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.20bittishey 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.01SamotEvery SIP message has a Call-ID
13:24.15SamotIt's part of how dialog is tracked and how messages are tracked.
13:24.42SamotAnd yes, Call-ID is a channel variable for SIP channels.
13:24.58filethe above is unrelated to SIP, and it can be retrieved from the dialplan using ${CHANNEL(callid)}
13:25.14SamotThere you go, all channels have it.
13:25.37*** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net)
13:26.36bittisas 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.26fileyes
13:28.28*** join/#asterisk jamesaxl (~James_Axl@109.172.62.242)
13:42.21bittishmm, not ${CHANNEL(callid)}
13:42.28bittiscase sensitive?
13:44.57filethat 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.00bittishow safe is it to update the func_channel.so module manually rather than updating asterisk completely?
14:03.29SamotOK before you start changing system core stuff.
14:03.35SamotWhy don't you show your dialplan
14:03.46SamotAnd the output of your attempt to get this variable.
14:03.57Samot~pb
14:03.58infobotextra, 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.46bittisactually on Asterisk 13.12.1
14:04.58bittishttps://issues.asterisk.org/jira/browse/ASTERISK-26878
14:05.06bittisaccording to this need to move a bit up
14:05.46SamotYes, being on the versions that have this feature would be helpful.
14:07.00bittisguessing overwritting the existing .so file with the latest one is wishful thinking then :)
14:07.12SamotWhat?
14:07.24SamotYou're going to re-compile when you update.
14:07.33bittiswould updating overwrite any /etc/asterisk files?
14:07.34SamotSo yes, it's going to overwrite the existing .so
14:07.39SamotNo.
14:07.58SamotIt 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.06SamotThat being said, you should always back up your shit.
14:08.12bittisalways :)
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.42qakhanhi 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-FenderContact: <sip:s@192.168.10.106:5060>  <- You're very obviously giving them a garbage PRIVATE IP as the contact
15:08.58SamotAnd not sending back a proper auth challenge response.
15:09.07[TK]D-FenderStart by not screwing up the basics
15:11.15qakhanbut 192.168.10.106 my system iP
15:11.27SamotBut it's not your WAN IP
15:11.45SamotYou are clearly behind NAT, so you should have Asterisk setup as such.
15:12.43qakhanyou mean in sip.conf   NAT SUPPORT ?
15:12.45SamotBut 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-Fenderqakhan, 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.42SamotWell until a proper REGISTER response is sent..
15:15.44[TK]D-Fenderqakhan, My phone has an "extension" of 100 that the guy sitting next to me can dial.
15:15.46SamotThat isn't going to matter.
15:15.49[TK]D-FenderYOU try calling me now!
15:15.58[TK]D-FenderGo dial 100.  Is MY phone going to ring?
15:16.01[TK]D-FenderGrab yours right now
15:16.36qakhan[TK]D-Fender yes i can dial if we have a sip trunk
15:16.44qakhanotherwise no
15:16.48SamotFFS.
15:17.01Samotqakhan: You have network setting issues
15:17.08[TK]D-FenderWell your provider sure as hell can't send packets to your PRIVATE IP and expect them to end up at your server
15:17.12Samotqakhan: Your trunk is not configured properly
15:17.17SamotThose are you two main issues.
15:18.41SamotAs well, Vitelity IS replying to your REGISTER request.
15:19.01SamotBut your trunk is not configured right. So it never RESPONDS right.
15:19.20[TK]D-Fender?
15:19.27SamotLook at the debug.
15:19.33[TK]D-FenderI'm not getting what you're alluding to in that last one
15:19.47[TK]D-Fenderwith regards to "trunk" not being right
15:19.49SamotVitelity is sending 401 Unauthorized's back to the PBX
15:20.04SamotThe PBX is responding with a new REGISTER like it should.
15:20.15SamotHowever, there is ZERO auth digest creds with it.
15:20.19SamotSo improper reply.
15:20.22[TK]D-FenderWhat precisely are you referring to by "trunk"?
15:20.32SamotHis f'ig Vitelity trunk.
15:20.39[TK]D-Fenderwhat CONSTRUCT?
15:20.41SamotThat should have a register string.
15:20.46SamotIN THE PBX
15:20.50SamotFFS.
15:21.00SamotHe's not responding to the AUTH PROPERLY
15:21.14[TK]D-FenderRegister string stands ALONE.  It  does not tie to a PEER
15:21.26SamotOH GOOD GOD
15:21.30SamotWhatever.
15:22.40[TK]D-Fenderthe REGISTER string does not check or validate against a PEER.  it does it's ENTIRE job alone.
15:22.48[TK]D-FenderUsing terms like "trunk" don't factor in
15:22.50[TK]D-Fenderit;'s ONE line
15:22.52SamotYou're missing the point.
15:23.05[TK]D-FenderAll the auth you're gonna get is on that one line with no relation to anything else
15:23.14SamotMissing the point.
15:23.20[TK]D-FenderDON'T FUCKING SAY TRUNK OR THESE FUCKERS WILL START LOOKING AT THEIR PEERS
15:23.29[TK]D-FenderEye on the target
15:23.34[TK]D-Fender^
15:23.41[TK]D-FenderContact is bad.
15:23.44Samot#Irony
15:23.47[TK]D-FenderRegister string quite possibly bad.
15:23.48SamotSo f'ing WHAT
15:23.52[TK]D-Fenderthat we can work with
15:24.08SamotIf the contact was correct it still wouldn't fix the fact it's not registering..
15:24.13SamotAnd why is it not registering?
15:24.23SamotBecause the AUTH CHALLENGE IS NOT RIGHT
15:24.33SamotEye on the target.
15:24.52qakhanthis is my sip.conf NAT setting  https://pastebin.com/THk0ZiT0
15:25.11qakhanis it correct?
15:25.36Samotqakhan: Show your sip.conf
15:26.35qakhanshould i get sip show settings?
15:26.49SamotYou should copy and paste what you have in sip.conf
15:26.54SamotI want to see if you have this correct.
15:28.22qakhani am using default sip.conf which is pretty big. but i will copy it
15:29.08SamotThat's fine.
15:32.42qakhanhere https://pastebin.com/DpmYgBFm
15:33.37SamotOK.
15:34.02SamotSo first, you really should get rid off all that garbage. The idea was to give you a reference point..
15:34.22SamotNot fill your conf files will not needed junk.
15:34.50qakhanok
15:36.33SamotLike register strings don't go in [general]
15:36.58SamotThat would imply *every* Chan_SIP device will use it.
15:38.36qakhanok. so do you think my NAT settings are correct?
15:40.18SamotNo.
15:40.22SamotYou're behind NAT
15:40.27SamotYou have no NAT setting.
15:42.12qakhanYes i am behind the NAT (Cisco Router)
15:44.47qakhanbut 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.04SamotRead more.
15:47.06SamotThat is nat=
15:47.11SamotYou need to set that at least.
15:54.19qakhanis 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.01ClearDarkhello, 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.47Korolevusing curl to a rest service that returns immediately and handles the udp request outside of asterisk?
17:53.23Korolevyou 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-FenderClearDark, What do you mean by no "clogging the dialplan"?
17:55.28KorolevI 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.36SamotClearDark: Asterisk will not trigger an OPTIONS during dialplan execution.
17:55.59SamotYou have to do that and Asterisk doesn't send SIP messages like that from the dialplan during an active call.
17:56.10ClearDarkyea it blocked using System() and running a shell script
17:56.12ClearDarkusing nc
17:56.20ClearDarkno i understand that Samot
17:56.23SamotThat's not Asterisk sending it.
17:56.26SamotThat's the system.
17:56.29ClearDarki just wanna send iut out
17:56.39ClearDarkthe data..
17:56.40SamotWhat about the reply?
17:56.49ClearDarki dont need a reply.
17:56.51Korolevmy view would be put in on a queue somewhere, and handle it outside
17:57.11Korolevunless you need to know the status during the rest of the dialplan
17:57.11ClearDarkthats what im trying to do, sending a udp packet to a local server
17:57.15SamotWhat type of packet are you sending?
17:57.21ClearDarkudp
17:57.24ClearDarkabout 30 bytes
17:57.26SamotFor what?
17:57.33ClearDarkcallerid, call id
17:57.35SamotIs it a SIP message...
17:57.40ClearDarkno
17:57.50ClearDarki need it for external logging, what does it matter?
17:58.01SamotWell why are you using UDP for that?
17:58.05ClearDarkits fast.
17:58.10SamotIf you're sending it to a server that is logging something..
17:58.13Korolevalso unreliable as all hell
17:58.16Samot^^^
17:58.20ClearDarki dont need reliability
17:58.25SamotNot to mention most things that log are TCP
17:58.26Samot...
17:58.27SamotWhat?
17:58.27ClearDarki understand the implications of udp
17:58.32SamotOK.
17:58.39ClearDarkit works well for my needs
17:58.46ClearDarklike i said, other suggestions are more than welcome
17:59.02ClearDarkhow to send the data out to a remote machine as fast as possible
17:59.03SamotSo you need to log data but it doesn't need to do it reliably?
17:59.23ClearDarkyes
17:59.33Korolevwait, is this because you are expecting a giant volume of calls and want to post CDRs as fast as possible?
17:59.33ClearDarkreliability is not a factor here
17:59.33SamotWell UDP isn't the first choice.
17:59.45ClearDarkno, im logging CDR to mysql already
17:59.51SamotSo why even bother?
17:59.59ClearDarki dont wanna query the entire mysql table
18:00.01SamotIf it doesn't matter if the log data makes it or not..
18:00.03ClearDarkevery few seconds
18:00.06ClearDarkits huge
18:00.12Korolevor why do it during the dialplan if you already have the data somewhere else?
18:00.17SamotWhat is "huge"?
18:00.26ClearDarkthe table containing the cdr data
18:00.30ClearDarki can iterate on that
18:00.33ClearDarkbut its expensive.
18:00.33SamotYou realize MySQL is meant to process large volumes of queries quickly.
18:00.34Korolevwhy is it a single table?
18:00.43Korolevthat's the first NO right there
18:00.53Korolevcdr tables are never a single table
18:00.55SamotHuh?
18:01.03Korolevuse a table per peroid
18:01.11Samotwhat?!
18:01.12Korolevit will make it way faster to query later
18:01.24ClearDarki didnt ask for advice
18:01.25ClearDarkon that
18:01.29ClearDarki asked something very specific
18:01.31Korolevoh I'm sorry
18:01.48SamotI think you're on your own.
18:02.02SamotEveryone else has been pretty clear that what you are doing isn't the best option.
18:02.29ClearDarkthanks for your time then :)
18:02.52SamotWell..
18:02.56SamotDo it a way that everyone else does
18:02.59SamotYou know, standard.
18:03.15SamotUsing UDP for logging like this is not how it is done.
18:03.16ClearDarki have reasons for what im trying to do...
18:03.21SamotI'm sure you do.
18:03.22ClearDarkits not for logging.
18:03.27SamotOK.
18:03.29ClearDarki dont save that data
18:03.30ClearDarkits discarded
18:03.35ClearDarki process it right away and throw it away
18:03.39Korolevwe are not questioning your reasons, just trying to offer advice
18:03.51ClearDarki know..im saying that querying mysql is a bad option for me at the moment.
18:03.57Korolevbut you seem to have cornered yourself into a solution
18:03.58ClearDarklooking for alternatives.
18:04.10ClearDarki could care less if its udp
18:04.15ClearDarkor any thing means of transporting data
18:04.25ClearDarkjust looking for a way thats all..
18:04.43SamotWell we have no idea what the other side is.
18:04.46SamotWhat it is doing
18:04.58SamotSo how to offer you any advice on how to improve it, kind of hard.
18:04.59Korolevwhy can't it be AGI?
18:05.05SamotWhy?
18:05.09SamotAGI isn't needed for this.
18:05.22ClearDarkSamot-  the receiving end has no 'business' in this problem...
18:05.26Korolevwell, if he wants to avoid local databases
18:05.32SamotWhat?
18:05.34ClearDarkit gets the data, 'consumes' it, and thats all
18:05.43Korolevhe could use AGI and something like memcache or one of it's relatives
18:05.56Korolevand then query that and post multiple rows at a time to a rest service
18:06.03SamotSo..
18:06.04Korolevit makes it fast
18:06.11ClearDarkwhat data is available to me through AGI?
18:06.12SamotAre you sending the data via a RESTful API?
18:06.18sekilsyslog?
18:06.20SamotAre you sending it to MySQL server?
18:06.37ClearDarkcurrently im sending it using a simple shell script
18:06.41ClearDarkrunning netcat
18:07.05SamotHow does the other side "consume" the data?
18:07.10ClearDark- /bin/echo -n $1 | nc -4u -q1 10.0.0.5 33333
18:07.13ClearDarkwhat does it matter???
18:07.19SamotOf course.
18:07.22SamotHow could that matter.
18:07.49SamotHow could helping you get data from Server A to Server B require knowing how Server B accepts that data.
18:07.51SamotSilly me.
18:08.03ClearDarkit can accept it any way it needs to
18:08.08ClearDarkbe it a udp server
18:08.18ClearDarkor whatever, im open ot suggestions.
18:08.19SamotYou just said you don't have to use UDP
18:08.27ClearDarku asked how it works now.
18:08.50SamotUDP is not how it consumes it
18:08.52ClearDarkserver a has a simple udp server in node, listening on port 33333.
18:08.57SamotOK
18:09.05KorolevUDP seems to me like you are optimizing the wrong part of it
18:09.13ClearDarkvoip server uses shell script with above command to send to server A a udp packet
18:09.42Korolevyou are still invoking a shell process for every cdr
18:09.54ClearDarkill say again, i can skip udp all together, im open to any idea if it gets the job done
18:09.58ClearDarkmy limitations are mysql.
18:10.13Korolevokay, follow me for a second
18:10.18ClearDarkalright.
18:10.20KorolevI know you didn't ask for advice about this
18:10.23Korolevbut hear me out
18:10.55Korolevthe 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.06Korolevis because you don't want to query the cdr table frequently
18:11.09Korolevyes?
18:11.17ClearDarkyes.
18:11.22KorolevI assume because it's too big to query frequently, which makes total sense
18:11.29ClearDarkno.
18:11.45Korolevthen why not?
18:11.48*** join/#asterisk corretico_ (~corretico@200.91.143.34)
18:12.02ClearDarkits because polling mysql will eventually make the result in "batches"
18:12.12ClearDarki need an "event" driven system "like"
18:12.25Korolevah!
18:12.41Korolevyou need to get the cdr WHEN the call arrives
18:12.51ClearDarkyes
18:12.55SamotUhm.
18:13.01ClearDarki dont need the cdr. i just need the caller id
18:13.12SamotThat's a channel variable.
18:13.16Korolevthis sounds interesting
18:13.17ClearDarkand a few more extra bytes of data for that specific extensions (static data)
18:13.18sekilisn't ami used for that interfacing better
18:13.23Korolevthis sounds like a dirty route
18:13.23SamotIt's a channel variable.
18:13.31ClearDarkAMI causes insane performence issues for me
18:13.58SamotClearDark: So you need the CallerID?
18:14.01Korolevyou know the caller id where?
18:14.03SamotThat's it?
18:14.06ClearDarkyes
18:14.07*** join/#asterisk miralin (~Thunderbi@91.237.94.6)
18:14.09SamotOK
18:14.17ClearDarki get it with ${CALLERID(num)}
18:14.22SamotOK.
18:14.39SamotSo you can use System() to send an RESTful API call to the other server.
18:14.43Korolevso you need the remote server to know the callerid of the call that just came in?
18:14.51ClearDarkKorolev - exactly
18:14.54SamotSo you can use System() to send an RESTful API call to the other server.
18:15.01ClearDarkSamot - i did that with a udp packet - it hung the whole dialplan up
18:15.12SamotRESTful doesn't use UDP
18:15.16ClearDarki know
18:15.22SamotBecause it's HTTP/HTTPS which is TCP
18:15.23KorolevI second the rest idea
18:15.25SamotSo make the call RIGHT
18:15.36Korolevyou just need to return the rest request right away
18:15.49SamotHe doesn't need to return anything at all
18:15.52Korolevand then do your processing outside
18:15.53SamotPOST does't need a reply
18:16.06ClearDarki have this in some extensions
18:16.07ClearDarkexten => +xxxx,1,System(curl -X GET 'https://xxx.com/rid=${UNIQUEID}')
18:16.15SamotWhy are you using GET?
18:16.19ClearDarklol.
18:16.26Korolevno no, I meant return as in the method in the implementation needs to return right away
18:16.26SamotYou're POSTing.
18:16.36ClearDarkKorolev - i got what u ment
18:17.05Korolevgrab your data, spawn a new thread, return
18:17.06ClearDarkguess ill just change node from udp to express.
18:17.19*** join/#asterisk babcka87 (~bacbka@5.145.242.42)
18:17.33ClearDarkill give that a shot
18:17.42Korolevand I would use curl instead of a system call
18:17.45ClearDarki really doubt POSTing or GETing makes a difference
18:17.47Korolevsystem calls make me jittery
18:17.56ClearDarkhow?
18:18.00KorolevI don't have a reason to back that up
18:18.05Korolevthey just make me jittery
18:18.09SamotWell..
18:18.14ClearDarkhow do u use curl
18:18.16ClearDarkinstead of a syscall
18:18.17SamotPOST is generally one way
18:18.35SamotGET means you're excepting to get data back.
18:19.03ClearDarkits http, both of them have to return 200.
18:19.29ClearDarkso both of them are 'expecting' a result. the action verbs are just...verbs.
18:19.52Korolevyeah it won't matter, and it isn't a lot of data
18:20.19ClearDarkso how to curl
18:20.22ClearDarkinstead of System?
18:20.51Samothttps://wiki.asterisk.org/wiki/display/AST/Function_CURL
18:21.06sekilI wonder why is AMI non-performant
18:21.07babcka87Hello
18:21.12ClearDarku da man.
18:21.18babcka87Sorry, plz help me
18:21.34ClearDarksekil - i wondered that too, it just makes my server shit itself
18:21.42sekilalthough ARI should be better
18:21.59KorolevSet(SOMEVAR=${CURL(http://someserver:port/someresource/?blah=1&bleh=${THISVARIABLE}&bloh=${THATVARIABLE})});
18:22.02Korolevthere is an example
18:22.04babcka87in first time i try to set up asterisk now and make a call
18:22.22ClearDark"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.47ClearDarkARI...
18:23.31*** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132)
18:26.39babcka87https://pastebin.com/tVBN8XZd
18:26.47babcka87this my pjsip log
18:26.55babcka87i try to make a call
18:27.33Korolevyou need to crate a TRUNK
18:27.36Korolevcue outrate :D
18:27.41Korolevoutrage too*
18:29.22[TK]D-FenderYou're trying to register and failing
18:29.26[TK]D-Fenderyou're trying to call and failing
18:29.29[TK]D-Fenderboth say NO AUTH
18:29.38[TK]D-Fenderthe credentials aren't matching on both sides
18:30.23babcka87https://pastebin.com/5VPPu6sA
18:30.30babcka87my pjsip conf file
18:30.39babcka87where the mistake
18:31.47[TK]D-Fenderthat is only HALF of the picture
18:34.30[TK]D-Fenderdasallow=all <- clearly bad
18:35.17*** join/#asterisk jkroon (~jkroon@165.16.204.165)
18:40.41babcka87but i set user=6001 password=6001
18:41.40[TK]D-FenderFIX THAT LINE
18:42.07babcka87could i have made a mistake?
18:42.27babcka87in sipphone
18:42.42[TK]D-Fender<[TK]D-Fender> that is only HALF of the picture
18:43.33babcka87what is: "dassalow = all''? What is this meen?
18:44.07[TK]D-FenderIt means nothing
18:44.12[TK]D-Fenderbecause that isn't a SETTING
18:46.52babcka87disallow?
18:47.43[TK]D-FenderI 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.54babcka87[TK]D-Fender: ok
18:56.15babcka87[TK]D-Fender: YES! I've made it!
18:56.23babcka87[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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.