| 00:06.47 | drmessano | it sounds better when you use the common name, which is Htek |
| 01:33.01 | *** join/#asterisk LunarTide (~NiHola@unaffiliated/liuyan) |
| 01:52.11 | overyander | How can I get a return value or some type of response from a python script back to the dialplan? |
| 01:52.50 | overyander | Is there a variable or something set when you run System()? |
| 01:53.39 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
| 02:04.59 | *** join/#asterisk MICROburst1 (~Thunderbi@x4dbf84ab.dyn.telefonica.de) |
| 02:26.24 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 02:42.26 | aoeui | AGI with SET VARIABLE FOO ${BAR} |
| 03:17.02 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 04:20.50 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 04:36.07 | *** join/#asterisk saltsa (~joonas@dsl-hkibng42-58c3f6-87.dhcp.inet.fi) |
| 04:38.28 | *** part/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
| 06:07.34 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 06:07.34 | *** topic/#asterisk is AstriCon 2019 in Atlanta! http://www.astricon.net/ -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.30.0 (2019/12/23) 16.7.0 (2019/12/23) Standard: 17.1.0 (2019/12/23); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
| 06:27.32 | *** join/#asterisk jkroon (~jkroon@165.16.203.61) |
| 06:48.42 | *** join/#asterisk jkroon (~jkroon@165.16.203.61) |
| 07:18.34 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 07:33.41 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 07:57.49 | *** join/#asterisk tsal_ (~tsal@i59F5F810.versanet.de) |
| 08:00.00 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 08:17.16 | *** join/#asterisk Da-Geek (~Da-Geek@212.250.100.150) |
| 09:02.48 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:18.01 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
| 09:21.01 | *** join/#asterisk jkroon (~jkroon@41.114.78.173) |
| 09:27.23 | pabe | hey guys. We're currently using snom d7XX phones and are looking for new headsets, with the primary focus on noise cancelling on the microphone. We got busy offices here and we often find, that our callpartners can hear a lot of the (sometimes sensitive) stuff going on in the background. However I find it very hard to find compatible and promising headsets. Do you have any experience or recommendations? |
| 09:27.51 | *** join/#asterisk jkroon (~jkroon@41.114.78.173) |
| 09:44.16 | joepublic | I am not sure that noise canceling microphone is the algorithm so much as having a directional microphone of low sensitivity? |
| 09:46.47 | pabe | joepublic: Thanks for your input. Maybe you're right. |
| 09:47.56 | joepublic | Please keep in mind I am just a random person with no experience with snom phones and very little with headsets. |
| 09:48.36 | pabe | joepublic: Sure :) |
| 09:53.12 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 10:08.14 | *** join/#asterisk jkroon (~jkroon@165.16.203.62) |
| 10:28.31 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 11:00.25 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 12:09.22 | *** join/#asterisk juvenal (A128@free.znc.bg) |
| 12:10.26 | *** join/#asterisk sekil (~sekil@87.116.175.46) |
| 12:15.28 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 12:27.14 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 12:28.12 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 12:30.35 | *** join/#asterisk lvlinux (~ruel@unaffiliated/lvlinux) |
| 12:33.09 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 12:43.24 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 13:44.38 | *** join/#asterisk somepoortech (~somepoort@72.12.70.165) |
| 13:54.01 | *** join/#asterisk AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 13:56.27 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:10.14 | electronic_eel | how do I properly quote the "=" char in the data-part of a call to the Set application? |
| 14:10.18 | electronic_eel | I have |
| 14:10.22 | electronic_eel | same => n,Set(MESSAGE_DATA(X-myheader)=field=abc) |
| 14:10.39 | electronic_eel | but this always gives the error "Set requires an '=' to be a valid assignment." |
| 14:11.15 | seanbright | try quoting it |
| 14:11.23 | electronic_eel | I want to put the data field=abc into the X-myheader |
| 14:11.25 | seanbright | same => n,Set(MESSAGE_DATA(X-myheader)="field=abc") |
| 14:11.50 | electronic_eel | that was the first I tried, didn't work, same error message |
| 14:13.49 | electronic_eel | ah, sorry, false alert |
| 14:14.28 | electronic_eel | I had not just field=abc, but field=something;other in it |
| 14:14.47 | electronic_eel | the ; was the problem, I was now able to quote it with \ |
| 14:20.00 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 14:20.00 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 14:40.49 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 14:50.01 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 14:53.59 | *** join/#asterisk somepoortech (~somepoort@72.12.70.165) |
| 15:08.49 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-niicknzhlookxptf) |
| 15:08.49 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:11.31 | igcewieling | Should an INVITE have a Date: Header? |
| 15:12.22 | Samot | It can. |
| 15:13.13 | Samot | It's not a required header. So the answer of should it have a Date header is up to that implementation. |
| 15:16.14 | igcewieling | Does Asterisk send a Date header by default? I thought it did. |
| 15:16.56 | igcewieling | Incoming CallerID date/time at a site has the wrong timestamp in the phone call logs. Outgoing call logs have the correct timestamp. |
| 15:18.38 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-daxsriqblubcecpw) |
| 15:18.38 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:19.40 | Samot | Yes, I've seen the Date header in INVITEs. |
| 15:37.44 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 15:39.18 | *** join/#asterisk nibbier (~quassel@mx01.geekbox.info) |
| 15:56.07 | igcewieling | Perhaps a better question might be "How do I disable sending the Date: header in an INVITE with Asterisk?" |
| 16:10.03 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 16:10.34 | Samot | I don't think you can. |
| 16:10.59 | Samot | You can add headers but you can't really strip those other headers. That's done within Asterisk itself. |
| 16:14.22 | seanbright | chan_sip adds it explicitly |
| 16:14.43 | seanbright | chan_pjsip does not appear to, at least not in asterisk code. might happen automatically with pjsip though. |
| 16:15.01 | file | I think we only add it in the registrar for when we respond to an incoming REGISTER |
| 16:15.20 | seanbright | the code backs up that thought |
| 16:17.22 | seanbright | igcewieling: if you're talking chan_sip, you would need to modify c code, but it wouldn't be that tough |
| 16:19.19 | Samot | file: Actually looking at some debugs. I see it on chan_sip for 200 OK's for REGISTER and OPTIONS. |
| 16:19.29 | file | I meant PJSIP |
| 16:19.32 | file | I don't speak chan_sip |
| 16:19.36 | Samot | LOL |
| 16:20.40 | Samot | So it's like Latin to you? A dead language? |
| 16:21.53 | file | dead enough |
| 16:22.09 | Samot | Mostly dead. |
| 16:22.20 | seanbright | TO BLAVvvvvvvvvvve |
| 16:22.39 | igcewieling | Does not being able to disable the Date header imply the Date header is always sent with and INVITE? |
| 16:22.45 | Samot | Let's get Miracle Max on the line. |
| 16:22.54 | seanbright | igcewieling: with chan_sip, yes |
| 16:22.56 | igcewieling | Yes, this is chan_sip. |
| 16:22.58 | Samot | If it's Mostly Dead he can fix it. |
| 16:23.16 | igcewieling | So I have to figure out WHY it isn't sending the Date header. |
| 16:23.52 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 16:23.55 | seanbright | i don't see how that would be possible |
| 16:24.23 | seanbright | there is a "transmit_invite" function which adds it explicitly for each request |
| 16:24.39 | seanbright | but chan_sip is dumb, so maybe there is another place in the code that creates a sends an invite |
| 16:24.55 | igcewieling | It is also possbile the end user is an idiot. |
| 16:26.48 | igcewieling | I use pjsip on my main Asterisk call routing boxes, but the FreePBX boxes at customer locations all run chan_sip (most of them are on Asterisk 11) |
| 16:27.55 | igcewieling | *sigh* End user is an idiot. They were looking at the wrong calls and therefore provided wrong information to me. |
| 16:31.14 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 17:04.10 | *** join/#asterisk dacod (~dacod@177.53.240.114) |
| 17:06.30 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 17:07.12 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 17:12.18 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-kiqfgztctujdakve) |
| 17:12.18 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 17:17.59 | *** join/#asterisk miralin (~Thunderbi@94.233.240.33) |
| 17:21.40 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 17:30.07 | *** join/#asterisk dacod (~dacod@177.53.240.114) |
| 17:50.54 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:09.35 | cybrNaut | SIP config options don't seem to give a way to proxy over SOCKS4, SOCKS4a, or SOCKS5. Am I overlooking something? |
| 18:14.33 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 18:32.18 | *** join/#asterisk miralin (~Thunderbi@94.233.240.33) |
| 18:34.42 | *** join/#asterisk miralin1 (~Thunderbi@94.233.240.33) |
| 18:47.05 | *** join/#asterisk miralin1 (~Thunderbi@94.233.240.33) |
| 18:56.17 | igcewieling | cybrNaut: don't use socks proxies with SIP |
| 19:07.33 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 19:11.11 | *** join/#asterisk pabe (~pabe@81.24.66.208) |
| 19:11.34 | *** join/#asterisk i9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 19:13.42 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
| 19:13.49 | igcewieling | An alternative to the real XML polycom config format. https://pastebin.com/zQY56CBa |
| 19:14.04 | *** join/#asterisk miralin1 (~Thunderbi@94.233.240.33) |
| 19:14.09 | igcewieling | in case anyone finds it useful. |
| 19:20.23 | cybrNaut | Skype can be proxied over Tor w/Orbot, and asterisk can't even do SOCKS? |
| 19:21.00 | file | there's nothing built in for it no, and I have no idea how well SIP would work over it |
| 19:21.00 | cybrNaut | linux tools like asterisk should be the masters of their domain.. it's always unfortunate when a "power tool" can't do something simple tools can |
| 19:22.03 | cybrNaut | file: Tor latency is good enough for SIP. But note as well that SOCKS does not imply Tor. SOCKS can be a variety of different tunnels |
| 19:22.10 | file | I know that |
| 19:22.15 | file | that doesn't change my statement |
| 19:22.43 | cybrNaut | "I have no idea how well SIP would work over it" <= i was answering that. SIP works fine over Tor |
| 19:23.32 | igcewieling | And I bet file has no idea how they do that. |
| 19:24.00 | file | I haven't looked at Tor, I was more referring to SOCKS5 |
| 19:25.02 | igcewieling | If you want "security" use TLS/SRTP. If you want proxy, use Kamailio. If you want both, then use both. |
| 19:25.54 | electronic_eel | I'd say SIP could work well over SOCKS5. But someone would have to implement it and I don't see a lot of use cases for it right now |
| 19:26.52 | aoeui | SIP uses RTP for audio - UDP - Tor doesn't talk UDP |
| 19:27.08 | cybrNaut | i'm not seeing anything that masks one's IP address from a SIP server |
| 19:27.21 | cybrNaut | Kamailio does not seem to solve that problem |
| 19:27.53 | igcewieling | Ah. you want untraceable calls. |
| 19:27.57 | cybrNaut | aoeui: SIP also works over TCP |
| 19:28.16 | igcewieling | excuse me while I clean up the coffee I Just spilled. |
| 19:28.37 | cybrNaut | indeed, I want my SIP provider to be unable to track my realtime location around the world |
| 19:29.00 | igcewieling | cybrNaut: SIP, which is SIGANLING, yes. RTP, which is AUIDO requires UDP. |
| 19:29.57 | cybrNaut | i also want my ISP to be unable to track where my phone service comes from (ISPs in some countries are allowed to do data collection and selling the data) |
| 19:29.59 | igcewieling | cybrNaut: then set up a kamailio AND RTP proxy and remove the info. |
| 19:30.00 | electronic_eel | cybrNaut: but then you need some server, be it the socks-proxy or kamailio, to show it's ip to the sip provider |
| 19:33.15 | Samot | 2:30:00 PM <igcewieling> cybrNaut: then set up a kamailio AND RTP proxy and remove the info. <-- That won't matter. The idea to have the ISP not know where the service is coming/going for SIP means that it's sitting on the ISP circuit. |
| 19:33.39 | Samot | The call still has to route from Kamailio to the provider over that. |
| 19:33.51 | igcewieling | So, like a VM on amazon aws? |
| 19:34.54 | Samot | If the goal is to not have the ISP see the SIP traffic source/destination overall.... |
| 19:35.00 | Samot | Then that still doesn't work without a VPN. |
| 19:36.36 | Samot | cybrNaut: Is it that you don't want the ISP to see _any_ SIP traffic or that you don't want to see who is _providing_ the SIP services? |
| 19:36.41 | Samot | As in, another provider. |
| 19:37.02 | *** join/#asterisk miralin (~Thunderbi@94.233.240.33) |
| 19:38.00 | *** join/#asterisk engine20191 (~engine201@190.145.222.242) |
| 19:38.08 | cybrNaut | Samot: i don't care if the ISP knows that SIP traffic is present (at least, until netneutrality issues emerge), but I would not like the ISP to be able to listen on the conversation and I wouldn't want the ISP to know who the SIP provider is |
| 19:38.59 | cybrNaut | TLS easily solves the eavesdropping problem, but Tor is normally the way to solve the other issues |
| 19:39.12 | Samot | Let's be clear about something.. |
| 19:39.30 | Samot | If someone wants your phone call..they'll go to the source. |
| 19:39.34 | Samot | Legally that is. |
| 19:39.48 | Samot | Now if you think your ISP is listening to your calls that aren't on their network..then get a new ISP |
| 19:39.56 | Samot | They are probably breaking numerous laws. |
| 19:40.22 | cybrNaut | in the US, for example, the mass surveillance programs have expanded to cover VOIP |
| 19:40.41 | Samot | Look in the US if I have Comcast for ISP but Vonage for VoIP... |
| 19:40.42 | cybrNaut | that is likely done at the ISP |
| 19:40.47 | Samot | Guess where they are going for the calls? |
| 19:40.51 | Samot | Vonage. |
| 19:41.09 | Samot | No, it is not. |
| 19:41.14 | Samot | I can say this from experience. |
| 19:41.16 | cybrNaut | Samot: Vonage would not be the best target, b/c it misses all Vonage's competitors. |
| 19:41.31 | Samot | What you are talking about is illegal. |
| 19:41.35 | Samot | And unethical. |
| 19:41.38 | cybrNaut | the ISP makes more sense b/c they can just tap a few backbones |
| 19:41.43 | Samot | No. |
| 19:41.53 | cybrNaut | Samot: are you saying the NSA obeys the law? |
| 19:42.06 | Samot | OK. |
| 19:42.14 | Samot | Enjoy your SIP over SOCKS. |
| 19:42.28 | Samot | Not sure how your'e going to do it but I'm sure you'll figure it out. |
| 19:42.34 | cybrNaut | that's the first i've heard such a thing. I thought it was pretty well known that mass surveillance is done illegally |
| 19:43.02 | Samot | << Career ISP/LEC person. |
| 19:43.11 | Samot | So basically you're implying I build my networks to spy on you. |
| 19:43.38 | cybrNaut | i'm saying nothing about what /you/ do. NSA has many employees |
| 19:43.47 | Samot | OK. |
| 19:43.48 | cybrNaut | and they've been caught |
| 19:45.18 | Samot | But again... |
| 19:45.40 | Samot | What you are saying is the NSA is going to put people in ISPs to record random calls to different SIP providers... |
| 19:45.52 | Samot | When they could just put the employees in the SIP providers to make it easier. |
| 19:46.21 | cybrNaut | the sip providers exist worldwide |
| 19:46.32 | Samot | So does the NSA. |
| 19:46.35 | cybrNaut | a US resident has a US ISP |
| 19:46.54 | Samot | Yes but a non US residence can have a US VoIP provider. |
| 19:47.12 | Samot | 𤯠|
| 19:47.57 | cybrNaut | so much harder to infiltrate all SIP providers worldwide, when they already have their hooks into the ISPs |
| 19:48.12 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 19:48.59 | electronic_eel | cybrNaut: but what does a hook at the ISP help when the call is encrypted with TLS and SRTP? |
| 19:49.08 | Samot | ^^^ |
| 19:49.27 | Samot | Because you know who has to decrypt it for the PSTN and handoff to the termination side? |
| 19:49.38 | Samot | The VoIP provider. |
| 19:50.56 | cybrNaut | I'm not sure TLS is as common as you imply. Some SIP providers who don't even have TLS capability. |
| 19:51.48 | electronic_eel | yes, sure. but there are many sip providers available. if you care about it, chose one that offers TLS |
| 19:52.21 | Samot | Right because the PSTN isn't TLS. |
| 19:52.41 | Samot | They still need to be able to handle that call and pass it to the destination or various hops to that destination. |
| 19:52.53 | Samot | Those destination may or may not be IP |
| 19:53.01 | Samot | Or IP that supports TLS. |
| 19:53.50 | Samot | If a provider offers a TLS connection, that connection is between you and them. There is absolutely no guarantee it is TLS end to end. |
| 19:56.31 | drmessano | Hang on |
| 19:56.49 | drmessano | No guarantee? It's almost guaranteed that it's not |
| 19:57.31 | cybrNaut | i suppose if you call your SIP provider for support, that could be e2e TLS :) |
| 19:57.43 | drmessano | Few providers actually support this |
| 19:58.24 | drmessano | TLS or even SRTP is really to protect your leg of the call, not prevent upstream spying |
| 19:58.54 | drmessano | It's for insecure networks, like public wifi |
| 19:59.21 | drmessano | To prevent some idiot with Wireshark from capturing your call |
| 19:59.54 | drmessano | Beyond that, TLS and/or SRTP offer no protection on the PSTN. |
| 20:05.31 | aoeui | Yes. Even if you're that weirdo who eventually buys a sketchy VPS with bitcoin to VPN through over Tor to somehow talk SRTP to your ITSP - your calls go out in the clear |
| 20:07.24 | cybrNaut | i certainly don't expect a PSTN call to be secure. But in principle I should be able to expect the conversation to be secure from my ISP, and the ISP of the SIP provider, and there's no reason my ISP should know who my SIP provider is, and no reason for my SIP provider to know who my ISP is, or where my location is |
| 20:09.57 | Samot | Expect for that whole part of sending you calls. |
| 20:10.04 | Samot | So they do need to know where you are at. |
| 20:11.48 | Samot | You SIP provider needs your location for 911. It's the law in the US. |
| 20:11.57 | Samot | Your ISP needs your location for your service. |
| 20:12.04 | Samot | So they both need to know your location. |
| 20:12.37 | cybrNaut | if my device were registered with their server over Tor, the SIP service (which isn't necessarily in the US) wouldn't know where I am but still I'd be connected. |
| 20:12.54 | Samot | OK. |
| 20:13.21 | cybrNaut | but I know there's contention as to whether it's possible to do SIP over Tor |
| 20:13.50 | aoeui | No, there's no contention. SIP uses RTP for media. That's UDP. |
| 20:13.59 | cybrNaut | I've read articles claiming it works, but perhaps they're wrong. I didn't realize the payload could not go over TCP |
| 20:14.00 | aoeui | No UDP over Tor |
| 20:15.28 | cybrNaut | https://superuser.com/questions/251819/is-there-any-use-of-sip-on-top-of-tor |
| 20:15.38 | *** join/#asterisk miralin1 (~Thunderbi@94.233.240.33) |
| 20:15.51 | drmessano | Also, do you really think there's some anonymity in your providers peering where whoever they use for IP transit can't determine who you are? |
| 20:17.39 | drmessano | I hate to break this to you, but your providers proxies aren't some island with RJ21X's plugged into the PSTN. They're probanly using the same provider for the customer leg of the call and their connection upstream to the PSTN |
| 20:18.10 | drmessano | So they have your "security through obscurity" leg of the call and the upstream leg on their network. |
| 20:18.33 | igcewieling | If you don't want anyone to find you, do whatever it is that scam callers use. Nobody can seem to track them down. |
| 20:18.53 | igcewieling | yes, I am (mostly) joking. |
| 20:19.54 | Samot | Well we'll see what happens next year with STIR/SHAKEN |
| 20:20.17 | Samot | VoIP.ms already broke iNUM users from using their iNUM numbers as CallerID. |
| 20:20.31 | Samot | Because they are making changes for STIR/SHAKEN. |
| 20:20.40 | drmessano | Wait |
| 20:21.25 | Samot | stops, collaborates and listens |
| 20:21.37 | drmessano | "VoIP.MS pissed off the 3 people that threw a fit after they stopped allowing iNum for the CID." |
| 20:21.45 | Samot | I still think its funny. |
| 20:21.58 | drmessano | Because "iNum is a real number!!!!!!" |
| 20:22.08 | Samot | I didn't say it broke a lot of people stuff, it just broke it. |
| 20:22.35 | drmessano | It never ceases to amaze me the fucking hill that people will choose to die on |
| 20:22.44 | Samot | Oh I know. |
| 20:22.45 | drmessano | iNum is a standard!!! |
| 20:22.58 | drmessano | How dare you!!! |
| 20:23.32 | Samot | Yeah, it's totally breaking peoples iNUM+DUNDi+IAX setups. |
| 20:28.26 | *** join/#asterisk miralin (~Thunderbi@94.233.240.33) |
| 20:33.53 | *** join/#asterisk miralin (~Thunderbi@94.233.240.33) |
| 20:39.53 | *** join/#asterisk miralin1 (~Thunderbi@94.233.240.33) |
| 21:06.39 | *** join/#asterisk overyander (~overyande@216.163.24.236) |
| 21:07.40 | overyander | can you directly use ODBC functions like this? exten=s,1,ODBC_WRITE-Foobar(${SOMEVAR}) ? |
| 21:08.40 | overyander | I'm getting an error 'No application 'ODBC_WRITE-Foobar for extension (...) |
| 21:17.35 | igcewieling | you need to configured func_odbc.conf |
| 21:20.08 | overyander | It is configured. |
| 21:20.18 | overyander | All other ODBC functions are running fine. |
| 21:20.33 | overyander | This is my only write function and also the only function that i'm not using within a gotoif |
| 21:21.03 | igcewieling | Use Set. |
| 21:21.28 | overyander | what should i set? |
| 21:23.08 | overyander | exten=s,1,Set(DESK=ODBC_WRITE-Foobar(${SOMEVAR})) ? |
| 21:24.20 | igcewieling | http://www.asteriskdocs.org/en/2nd_Edition/asterisk-book-html-chunk/getting_funky.html |
| 21:24.21 | overyander | Oh, derp |
| 21:24.39 | overyander | I just noticed in the example that it uses VAL1 and not ARG1 for the value it places in the DB. |
| 21:39.35 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 21:44.50 | *** join/#asterisk chandoo (~chandoo@pool-108-50-150-199.nwrknj.fios.verizon.net) |
| 22:10.32 | *** join/#asterisk salviadud (~ralfalfa@na-201-156-168-225.static.avantel.net.mx) |
| 22:13.51 | *** join/#asterisk Alblasco1702 (~Alblasco1@84.86.180.107) |
| 22:24.50 | cybrNaut | seems redundant to have a "register => username:password@your.provider.tld" in sip.conf, then to also have "[myprovider] .. type=peer ..." |
| 22:24.57 | cybrNaut | username and password are repeated |
| 22:26.11 | cybrNaut | is there a way to avoid the redundancy? The book "Asterisk: The Definitive Guide" is saying to do "register => " and also have a peer defined for the provider |
| 22:26.56 | Samot | That's because Chan_SIP is old and doesn't follow standards for that. |
| 22:27.17 | Samot | type=peer <-- No registration inbound or outbound |
| 22:27.42 | Samot | type=friend or type=user <-- inbound registration expected or outbound registration expected. |
| 22:29.55 | cybrNaut | There wouldn't be any inbound registration in my case because my IP is technically dynamic and unknown to the SIP provider |
| 22:30.40 | cybrNaut | so it seems the instructions in "Asterisk: The Definitive Guide" won't work for my case |
| 22:32.44 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 22:33.27 | Samot | secret is for authenticating inbound requests. |
| 22:33.50 | Samot | So it's not needed for an outbound registration based peer. |
| 22:34.17 | Samot | You really should be using the current edition of that guide and following the instructions for PJSIP. |
| 22:34.24 | Samot | Chan_SIP is dead pretty much. |
| 22:35.08 | Samot | It can be removed from Asterisk as early as Oct 2023 or thereafter. |
| 22:35.57 | seanbright | i think we all know it won't be |
| 22:36.11 | seanbright | it will outlive us all |
| 22:36.48 | cybrNaut | i have the 4th edition of the book, and it makes no mention of PJSIP. I'll have to look for a newer on |
| 22:36.51 | cybrNaut | e |
| 22:38.58 | Samot | 4th Edition goes to Asterisk 11 |
| 22:39.32 | Samot | A lot of stuff changed in 12. |
| 22:39.42 | Samot | 5th Edition goes up to 16 I beleive. |
| 22:39.46 | Samot | believe* |
| 22:46.49 | *** join/#asterisk Chotizei (chotaire@unaffiliated/chotaire) |
| 23:02.45 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-110-234-244.ks.ks.cox.net) |
| 23:25.04 | *** join/#asterisk JohnWigley (uid264251@gateway/web/irccloud.com/x-zbqasigieubxoamm) |
| 23:42.53 | Reinhilde | chan_sip and chan_iax2 will outlive me |