00:01.00 | Reinhilde | Samot: the config change between not working and working was changing the nat= field to include 'comedia' |
00:05.45 | *** join/#asterisk josefig (~josefig@unaffiliated/josefig) |
00:17.28 | CJSL | hay everyone iv had a issue for a few days that i havnt been able to figure out a fix for... i have asterisk running on a VM on my server and i have the VM's ip in the networks DMZ list but i cant connect to it from outside of the network its on, so if i connect to it via my phone not on wifi i can connect the call but no audio is transfered and after about 10 seconds the call disconnects. |
00:18.35 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
00:18.35 | *** topic/#asterisk is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.27.0 (2019/5/30) 16.4.0 (2019/5/30), Security Only: 15.7.2 (2019/2/28); DAHDI: 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
00:19.07 | Reinhilde | CJSL: consider adding 'comedia' to your 'nat=' field. That's what worked for me |
00:23.45 | CJSL | sorry for the nooby question but where would i find the nat field, im assuming a .conf file. i'm using issabel's UI |
00:24.06 | Reinhilde | am I to assume you're on chan_sip or pjsip? |
00:25.10 | CJSL | good question... i have no idea lol iv only started using this in house this week |
00:25.28 | Reinhilde | then i can't help you |
00:25.58 | CJSL | no problem thank you for pointing me in the right direction though :) |
00:32.42 | *** join/#asterisk Iamnach0 (~Iamnacho@ip68-103-241-228.ks.ok.cox.net) |
00:39.10 | CJSL | i found the sip_nat.conf file and its empty so iv added "nat=comedia" restarted and having the same issue but once again thanks for giving me somewhere to look and try |
00:41.12 | [TK]D-Fender | That only implies a global setting, not an extension-specific one |
00:41.25 | [TK]D-Fender | and saying "the nat field" is invalid |
00:41.28 | [TK]D-Fender | there are SEVERAL |
00:41.43 | [TK]D-Fender | and what your actual situation is will change what you should be looking for |
00:42.08 | [TK]D-Fender | So the start of the process should ahve been actually looking at the call debug for proof of what's coming from where and what it is claiming |
00:43.14 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
00:44.31 | CJSL | ah, im just trying to get my home phone moved to sip so when im abroad i can still answer calls, where would i find the log file for the debugging you mentioned ? |
00:54.53 | *** join/#asterisk anderj101 (~anderj101@mail.thehouseofbacon.com) |
01:00.21 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
01:16.38 | [TK]D-Fender | Enable SIP debug |
01:16.45 | [TK]D-Fender | "sip set debug on" <- chan_sip |
01:16.51 | [TK]D-Fender | "pjsip set logger one" <- PJSIP |
01:19.47 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
01:38.28 | CJSL | SIP Debugging enabled (chan_sip) |
01:40.19 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
01:41.07 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
02:06.06 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
03:26.05 | *** join/#asterisk ghoti (~paul@glphon2233w-grc-09-184-145-52-216.dsl.bell.ca) |
04:25.42 | Reinhilde | [TK]D-Fender: It may have been incorrect, but I assumed the user knew what to make of the 'nat=' field (it is a field either in the global sip.conf or in user sections). |
04:54.15 | *** join/#asterisk ghoti (~paul@glphon2233w-grc-09-184-145-52-216.dsl.bell.ca) |
05:00.19 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
06:22.06 | *** join/#asterisk twanny796 (~user@antazzo.com) |
06:25.44 | *** join/#asterisk Someone_Else (~Someone_E@14-230-144-85.ftth.glasoperator.nl) |
06:25.56 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
06:26.06 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
06:27.55 | *** join/#asterisk znf (~ibm86@toaster.linge-ma.ro) |
06:28.10 | *** join/#asterisk skippyish (~skippyish@docker1.smerty.org) |
06:31.06 | *** join/#asterisk twanny796 (~user@antazzo.com) |
06:36.52 | *** join/#asterisk cranq (~crank@107.161.164.124) |
07:00.21 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
07:04.26 | *** join/#asterisk jkroon (~jkroon@105.12.2.130) |
07:05.56 | *** join/#asterisk twanny796 (~user@antazzo.com) |
07:24.05 | *** join/#asterisk nighty (~nighty@b157153.ppp.asahi-net.or.jp) |
07:43.40 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
08:21.38 | *** join/#asterisk hehol (~Adium@ip-176-199-151-97.hsi06.unitymediagroup.de) |
09:01.30 | *** join/#asterisk jkroon (~jkroon@105.12.2.130) |
09:33.03 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
09:46.58 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
09:48.13 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
10:54.36 | *** join/#asterisk jkroon (~jkroon@105.12.2.130) |
11:01.28 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
11:07.30 | *** join/#asterisk emsjessec (~emsjessec@96.56.225.51) |
11:40.18 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
13:00.19 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
13:02.15 | *** join/#asterisk dacod (~dacod@187.103.104.42) |
13:03.51 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
13:07.17 | *** join/#asterisk dacod (~dacod@187.103.104.42) |
13:09.19 | *** join/#asterisk dacod_ (~dacod@187.103.104.42) |
13:12.31 | *** join/#asterisk jkroon (~jkroon@105.12.2.130) |
13:13.55 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
13:32.29 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
13:36.33 | *** join/#asterisk ghoti (~paul@glphon2233w-grc-09-184-145-52-216.dsl.bell.ca) |
13:37.48 | *** join/#asterisk elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
13:59.39 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-oocadcpcgkntkebn) |
13:59.40 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:15.52 | *** join/#asterisk qakhan (~qakhan@50-204-254-11-static.hfc.comcastbusiness.net) |
14:21.52 | *** join/#asterisk wdoekes (~walter@wjd.osso.nl) |
14:21.52 | *** mode/#asterisk [+o wdoekes] by ChanServ |
14:27.48 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-fvlofmwzqbeiytni) |
14:27.48 | *** mode/#asterisk [+o bford] by ChanServ |
14:28.27 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
14:35.05 | qakhan | hi all, my customer is using rrmemory as strategy in Q1 and Q2. |
14:35.05 | qakhan | queue members are Local/3001@agent, Local/3002@agent, Local/3003@agent and Local/3004@agent. |
14:35.05 | qakhan | Local/3001@agent and Local/3002@agent penalty 0 in Q1 and Local/3003@agent and Local/3004@agent penalty 5 in Q1 |
14:35.05 | qakhan | Local/3001@agent and Local/3002@agent penalty 5 in Q2 and Local/3003@agent and Local/3004@agent penalty 0 in Q2 |
14:35.05 | qakhan | now the requirement is if penalty 0 agents are busy (on the call) donât send a new call to them and send a new call to penalty 5 agents. |
14:35.06 | qakhan | if penalty 5 agents are also busy (on the call) then send a new call to penalty 0 agents even though penalty 0 agents are already on the call (busy). |
14:41.11 | *** join/#asterisk MarkSX (~MarkSX@unaffiliated/marksx) |
14:44.34 | *** join/#asterisk C1ph3r (~C1ph3r@177.30.90.115) |
14:58.55 | zaf | ~book |
14:58.55 | infobot | Asterisk: The Definitive Guide, 4th Edition (ISBN 1-4493-3242-0) available at http://oreilly.com/catalog/0636920025894 - Asterisk: The Definitive Guide is released under a Creative Commons License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/) and a version is available for reading online at http://www.asteriskdocs.org/ or see ~buybook |
14:59.12 | zaf | ~buybook |
14:59.12 | infobot | You can buy "Asterisk: The Definitive Guide" at http://oreilly.com/catalog/0636920025894 so go buy it SERIOUSLY |
15:00.21 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
15:04.31 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
15:25.29 | Samot | zaf: Keep in mind there hasn't been a new book published since Asterisk 11. |
15:25.51 | *** join/#asterisk [J]oules (uid223833@gateway/web/irccloud.com/x-zmempekbwxscxjde) |
15:26.01 | Samot | zaf; So the book will cover a lot of basics but nothing that has been implemented or deprecated in the last 5+ years. |
15:26.43 | [J]oules | looking for replacement for a2billing wondering if there are any suggestions |
15:26.44 | Samot | And that listing at O'Reilly is gone. |
15:27.03 | Samot | [J]oules: There isn't one. |
15:27.34 | [J]oules | yeah there is, but i wondered if anyone here has found/used any that they consider good |
15:27.49 | [J]oules | i looked at magnus billing. |
15:28.00 | [J]oules | its asterisk based |
15:28.25 | [J]oules | but there is very little documentation on how to really use it like a2billing |
15:32.28 | Samot | Shrug. |
15:32.43 | Samot | Most places that do CDR accounting aren't doing it from Asterisk CDRs. |
15:32.49 | Samot | Because they are horrible for it. |
15:34.18 | [J]oules | well I don't know where magnus gets its cdr's from, but ssh to the server, rasterisk and its running 13.27.0 |
15:34.47 | [J]oules | haven't got it to the point of getting/making calls yet |
15:34.50 | Samot | If you're looking for something that supports billing on Asterisk CDRs, then they use Asterisk CDRs. |
15:34.53 | zaf | @Samot, new book is out now, just ordered 2 copies |
15:34.55 | [J]oules | so i dont know what the cdr's look like |
15:35.03 | Samot | zaf: What's the link? |
15:35.23 | Samot | [J]oules: It's Asterisk CDRs. It looks the same as what you have now. |
15:35.23 | zaf | http://shop.oreilly.com/product/0636920140610.do |
15:35.55 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
15:36.09 | Samot | Ahh, it just came out. |
15:36.12 | Samot | Nice. |
15:36.24 | Samot | The bot should be updated for that. |
15:36.32 | file | ooh it's out?!? |
15:36.34 | zaf | yeah |
15:36.40 | Samot | June 2019 |
15:36.44 | Samot | Just. |
15:36.55 | zaf | was wondering if the bot had been updated |
15:37.37 | file | looks like July 5 for Amazon |
15:39.06 | *** join/#asterisk pchero_work (~pchero@35.195.247.51) |
16:06.10 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
16:06.10 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
16:09.24 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
16:20.41 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
16:28.53 | *** join/#asterisk jkroon (~jkroon@165.16.203.105) |
16:43.24 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
16:50.32 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
16:51.31 | *** join/#asterisk EmleyMoor (~phil@topdeck.tinsleyviaduct.com) |
16:51.39 | *** join/#asterisk hfb (~hfb@47.139.22.65) |
16:52.58 | EmleyMoor | Is there a way to match a CALLERID(num) to a db key that is shorter, but not always the same length? I have done in three steps what I'd like to do in one at present... |
16:57.18 | Samot | REGEX |
16:58.14 | Samot | You can match on a pattern. |
17:00.18 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
17:13.59 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
17:16.22 | EmleyMoor | Samot: A pattern in a db key? (not a db value) |
17:16.50 | Samot | No, you compare the db value to the pattern. |
17:17.53 | EmleyMoor | That's no good... The db value is not what needs to be matched. The db key is |
17:18.04 | Samot | Sorry, I mispoke. |
17:18.08 | Samot | Sorry, I misspoke. |
17:18.24 | *** part/#asterisk josefig (~josefig@unaffiliated/josefig) |
17:19.23 | Samot | I'm not sure you can do it in one step. |
17:19.24 | sibiria | EmleyMoor: if you want it to be shorter you will also want it to still be unique |
17:19.30 | EmleyMoor | I have 0[12]XXX... type expressions, and need to match to acode/KEY, where KEY is 3 to 5 digits, beginning 0 |
17:19.31 | sibiria | meaning you will need to digest that number |
17:19.56 | Samot | That's a dialplat pattern |
17:20.05 | Samot | I was referring to REGEX patterns |
17:21.14 | Samot | ^(1|\+|)[2-9][0-9]{2}[2-9]{0-9]{2},{6}$ |
17:21.22 | Samot | ^(1|\+|)[2-9][0-9]{2}[2-9][0-9]{2},{6}$ |
17:21.52 | EmleyMoor | Always 02X, 01X1, 011X, 01N[02-9]X... Doesn't matter about the type of pattern as long as implementable in dialplan |
17:22.12 | Samot | The DB() call needs to be exact. |
17:22.30 | EmleyMoor | Samot: Then three steps it is, I guess |
17:22.43 | [TK]D-Fender | <EmleyMoor> I have 0[12]XXX... type expressions, and need to match to acode/KEY, where KEY is 3 to 5 digits, beginning 0 '- single expression can cover that |
17:22.48 | Samot | Might be able to do it in two |
17:22.52 | Samot | But I doubt one. |
17:23.32 | Samot | Might be able to do it in one with REGEX but it will always match against the shortest. |
17:23.38 | EmleyMoor | [TK]D-Fender: I'm seeking the information as to how |
17:23.53 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
17:23.56 | [TK]D-Fender | Read up on basic expressions |
17:24.03 | [TK]D-Fender | this is 101 grade stuff... |
17:24.05 | [TK]D-Fender | OR <- |
17:24.09 | [TK]D-Fender | AND <- |
17:24.19 | [TK]D-Fender | test 1 part. Test other part. Done. |
17:24.40 | Samot | What does OR/AND have to do with that? |
17:25.10 | EmleyMoor | [TK]D-Fender: That's still doing three, though. |
17:25.19 | [TK]D-Fender | If you want to test for 2 things then it can be done in one normal * expression |
17:25.50 | EmleyMoor | They're "3 in 1" rather than 3*"1 in 1" when done that way |
17:26.14 | [TK]D-Fender | Give a clearer example of how this would be called |
17:26.56 | EmleyMoor | I'll get you one line from my dialplan and explain what I also want it to do... |
17:28.18 | EmleyMoor | same => n,ExecIf($["${CALLERID(name)}"="" | "${CALLERID(name):0:1}"="0"]?Set(CAL |
17:28.21 | EmleyMoor | LERID(name)=${DB(acode/${CALLERID(num):0:5})})) |
17:28.41 | EmleyMoor | Erk, unexpected line break |
17:29.55 | EmleyMoor | That would work where CALLERID(num) begins, say, 01543, returning "Cannock"... but if it began "020", it would need to return the value of acode/020, which is London |
17:30.57 | [TK]D-Fender | Ok, that seems to trim to 5 long, but doesn't check the length |
17:31.10 | [TK]D-Fender | Which doesn't seme to match your previous requirement |
17:31.28 | [TK]D-Fender | seem* |
17:32.20 | EmleyMoor | [TK]D-Fender: Indeed. It needs to trim, currently, to 5, 4 and 3 long... as acode keys are those lengths (but exclusive - none begin with the whole of another) |
17:33.04 | sibiria | you can't do pattern matching (or regular expressions) via the DB call, so... outsource this task to a quick Lua script instead, is my advice |
17:33.34 | [TK]D-Fender | You aren't checking the actual length there though |
17:33.54 | [TK]D-Fender | And I'm not sure if that is due to a lack of clarifty on the need |
17:33.56 | sibiria | ie. just feed the caller id to the script and let it match against your defined area codes |
17:36.19 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
17:45.17 | EmleyMoor | [TK]D-Fender: No, I am not checking the length. I am matching on a variable length part |
17:45.42 | [TK]D-Fender | sort of... |
17:45.54 | [TK]D-Fender | you're trimming something that could be too long or too short |
17:46.02 | [TK]D-Fender | and not validating the extremes |
17:46.23 | EmleyMoor | There's no extremes involved |
17:46.43 | [TK]D-Fender | You said between 3 & 5 |
17:46.57 | sibiria | another problem with your approach is also that one day the UK may introduce an extension to its number plan leaving you with a 6 digit area code |
17:46.58 | [TK]D-Fender | I don't get what you mean either there, or here now |
17:47.05 | sibiria | you simply shouldn't approach this in any other way than pattern matching |
17:47.18 | sibiria | and since asterisk cannot do this sufficiently for your specific case, AGI it |
17:47.22 | EmleyMoor | sibiria: Area codes are shortening |
17:47.24 | [TK]D-Fender | Please actually clarify what we're really trying to do |
17:47.38 | sibiria | he's trying to match the area code of the caller id |
17:47.48 | sibiria | so that he can return the explicit locality |
17:47.53 | EmleyMoor | Match area code to name |
17:48.04 | [TK]D-Fender | sibiria, I mean the SPECIFICS |
17:48.14 | Samot | Area codes are shortening? |
17:48.17 | Samot | Huh? |
17:48.23 | [TK]D-Fender | "Hi I have conditions!", "no I don't!" |
17:48.26 | EmleyMoor | I'll be back soon |
17:49.12 | EmleyMoor | Samot: ... and local numbers lengthening |
17:49.34 | Samot | What part of the world are you in? |
17:49.44 | EmleyMoor | UK |
17:49.50 | Samot | Ah. |
17:50.36 | EmleyMoor | Area codes are 3-6 digits, but not enough significance in 6th |
17:51.52 | [TK]D-Fender | what does "not enough" mean? is it part of it or not? |
17:51.57 | sibiria | you can achieve this in a very clumsy way directly in the dial plan, but i would not recommend it |
17:52.24 | [TK]D-Fender | Is the total length a concern at all? |
17:52.28 | EmleyMoor | [TK]D-Fender: Yes, but a result that matches wh |
17:52.33 | [TK]D-Fender | Is this a prefix check only? |
17:53.04 | EmleyMoor | Total length is 10 or 11 and checked elsewhere. This is prefix checking only |
17:53.06 | [TK]D-Fender | You are describing this in a very broken and inefficient manner |
17:53.43 | EmleyMoor | It is very broken and inefficient - but then, it is British |
17:53.56 | sibiria | area codes have varying length in most countries |
17:53.57 | [TK]D-Fender | Prefix is MIXED with the suffix so you need to check each length in ORDER to validate |
17:54.25 | [TK]D-Fender | You can't jsut trim 5 caracters because that will have SUFFIX mixed in |
17:54.28 | [TK]D-Fender | Which is broken |
17:54.51 | [TK]D-Fender | So your idea of trimming off 5 blindly means you're never testing 3 digits codes |
17:55.02 | sibiria | no that works just fine, if only he'd approach the matching part of the problem the correctly |
17:55.22 | [TK]D-Fender | If starting with 444 is enough to validate then trimming 5 means you'll never test for it |
17:55.29 | EmleyMoor | ... which is WHY I need to do it for 5, 4 and 3 |
17:56.33 | [TK]D-Fender | So far this looks like a 3 line job (with any sanity) |
17:56.39 | sibiria | you're approaching the problem the completely wrong way...... and i'm not saying this just to get a rise out of you. i'm saying it as a programmer by trade, and from us doing this very same thing at work for thousands of numbers a minute |
17:57.44 | EmleyMoor | sibiria: But is there any better way? Part of the point of this is that "no result" from all three means "spoof prefix" |
17:58.24 | sibiria | yes; send the caller id to an AGI script (preferrably one that starts up fast, meaning not python or php, but lua or perl) and let it solve the problem with its superior tools for this |
17:58.51 | sibiria | this is a no-brainer with perlre, and just a little more complicated with lua |
17:59.08 | sibiria | this is a pattern-matching problem, so solve it with pattern matching |
17:59.42 | [TK]D-Fender | Or you test each length in order of precedence |
18:00.04 | sibiria | for perl it's a one-liner to pull the actual area code, and just one more line to pull a value (locality) from that key |
18:00.14 | sibiria | in lua not much more hassle |
18:00.15 | [TK]D-Fender | For dialplan it's 3 lines |
18:02.07 | EmleyMoor | Indeed... and precedence is equal due to uniqueness |
18:02.42 | EmleyMoor | Was just checking it needed to be three lines in dialplan |
18:04.20 | [TK]D-Fender | Because you likely want that value back (not just that it exists), and precendence matters, it makes sense to end up having to do this in 3 lines |
18:04.28 | [TK]D-Fender | Using * std expressions |
18:04.41 | [TK]D-Fender | not sure if RegEx can handle to precedece any faster |
18:04.47 | [TK]D-Fender | but I wouldn't personally bother |
18:06.25 | qakhan | when I use local channel with "/n" and agent local/3001@agent/n transfer the call to local/3004@agent/n in the queue. agent 3001 stay in Call and does not get a new call. |
18:06.58 | qakhan | how to release agent 3001 from call after transfer to 3004 |
18:29.46 | qakhan | any thought on my question? |
18:35.49 | Samot | That's not transferring a call. |
18:35.56 | Samot | That's using a local channel to make a call |
18:38.37 | qakhan | how local channel can actually transfer the call? |
18:41.59 | [TK]D-Fender | What does those local channels actually call? |
18:43.34 | qakhan | local/3001@agent/n and local/3004@agent/n are queue members |
18:43.46 | [TK]D-Fender | What does those local channels actually call? |
18:44.07 | qakhan | SIP/3001 and SIP/2004 |
18:44.12 | qakhan | SIP/3001 and SIP/3004* |
18:44.59 | [TK]D-Fender | Then specify a STATE DEVICE directly to that device for your members |
18:49.16 | qakhan | here is my dialplan. https://pastebin.com/dXwdL5By |
18:49.59 | qakhan | where STATE DEVICE need to be added? in queue context or agent context? |
18:52.39 | [TK]D-Fender | Where you define your agents |
18:56.28 | qakhan | ok |
19:00.39 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
19:05.24 | qakhan | [TK]D-Fender what STATE DEVICE will do in order to transfer the call between agents? |
19:05.45 | *** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
19:06.50 | [TK]D-Fender | It sets what the member evaluates as being the channel |
19:10.52 | qakhan | i am sorry, i did not get you. there is separate context for call trasfer. |
19:15.13 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
19:16.18 | *** join/#asterisk scgm11__ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
19:26.10 | *** join/#asterisk Ellenor (ellenor@unaffiliated/ellenor) |
19:32.08 | [TK]D-Fender | <[TK]D-Fender> Where you define your agents <- |
19:38.58 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
19:54.30 | qakhan | can you plase send me example of it |
19:54.42 | [TK]D-Fender | .... |
19:54.57 | [TK]D-Fender | read the sample configs and your app instructions. |
19:55.17 | [TK]D-Fender | You've been here for almost a solid decade now. |
19:55.32 | *** join/#asterisk _ganapathi_ (~Ganapathi@49.207.182.134) |
19:55.51 | _ganapathi_ | anybody pls help to find dahdi-linux.spc file |
19:56.17 | _ganapathi_ | any official file available to build rpm |
20:00.10 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
20:03.21 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
20:05.44 | *** part/#asterisk _ganapathi_ (~Ganapathi@49.207.182.134) |
20:12.02 | qakhan | [TK]D-Fender i am not working on asterisk full time. once or twice a month. i dont have well exposure to asterisk as you or anyone here |
20:12.20 | [TK]D-Fender | 10 YEARS |
20:12.20 | qakhan | therefore i have to ask question |
20:12.31 | [TK]D-Fender | Go read the instructions for hte apps you're calling and the configs your filling in |
20:13.13 | qakhan | understand 10 years. but not regular |
20:17.59 | Ellenor | [TK]D-Fender: what's this about ten years? |
20:19.50 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
20:20.33 | [TK]D-Fender | 10 years of proving unwilling or unable to read documentation for himself. |
20:20.43 | [TK]D-Fender | Even when being told exactly where the change needs to happen |
20:21.39 | Reinhilde | qakhan: did you make it through 4th grade? |
20:22.01 | qakhan | no |
20:22.12 | Reinhilde | so the guy hasn't even finished primary school |
20:22.26 | qakhan | according to you |
20:22.28 | Reinhilde | do you really think you should be working on telephone systems if you didn't even complete primary school |
20:22.46 | Reinhilde | if you can't read and understand documentation, you have no place wrenching on phones. |
20:23.01 | qakhan | you dont need to tell me |
20:23.12 | Reinhilde | well no, I don't, because [TK]D-Fender already did |
20:23.29 | Reinhilde | so qakhan, what exactly are you trying to do here? |
20:23.32 | [TK]D-Fender | No, I didn't |
20:23.35 | qakhan | Reinhilde take care |
20:23.47 | Reinhilde | am i supposed to read an '/ignore' into that? |
20:23.47 | qakhan | i know [TK]D-Fender |
20:24.02 | [TK]D-Fender | I make no claims as to why we're still having to try to push him to even do the basics |
20:24.13 | Reinhilde | [TK]D-Fender: correct. |
20:24.26 | [TK]D-Fender | I'm simply dismayed |
20:24.31 | Reinhilde | qakhan: yes, and he just lamented your decade of not RTFM. |
20:25.40 | Reinhilde | to really be good at asterisk, you have to be tits-deep in it for a good month or two, and then have a test setup where you test ideas out before deploying them live |
20:26.02 | Reinhilde | and you really should at least review things every week for a good few month |
20:26.04 | Reinhilde | s |
20:27.59 | *** join/#asterisk scgm11_ (~scgm11@r186-52-171-205.dialup.adsl.anteldata.net.uy) |
20:30.02 | [TK]D-Fender | Heading home.... |
20:47.30 | *** join/#asterisk twanny796 (~user@antazzo.com) |
21:00.21 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
21:26.05 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
21:44.37 | *** part/#asterisk twanny796 (~user@antazzo.com) |
22:00.20 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
22:06.46 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
22:09.18 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
22:12.23 | *** join/#asterisk scgm11_ (~scgm11@r186-52-246-242.dialup.adsl.anteldata.net.uy) |
22:22.14 | *** join/#asterisk ghoti (~paul@glphon2233w-grc-09-184-145-52-216.dsl.bell.ca) |
22:23.17 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
22:50.55 | *** join/#asterisk scgm11_ (~scgm11@r186-52-246-242.dialup.adsl.anteldata.net.uy) |
23:29.47 | *** join/#asterisk FuriousGeorge (ad3f24d4@pool-173-63-36-212.nwrknj.fios.verizon.net) |
23:29.49 | FuriousGeorge | hi all |
23:29.56 | FuriousGeorge | i set up an asterisk server in a google compute instance, and i notice that reloading sip causes all the peers to become unreachable. in my sip.conf i have qualify=200 and nat=comedia. the clients are behind nat. is there something on the client side i should be doing in this case? |
23:40.39 | *** join/#asterisk ircarcs (~quassel@77.159.9.169) |
23:44.36 | FuriousGeorge | uh-oh.... i was just testing it out, and after a few minutes in a call, all three sip peers became unreachable at the same time |
23:45.01 | FuriousGeorge | and, based on the above, they don't become reachable again until the phones are reregistered |
23:49.29 | FuriousGeorge | im not sure if this location is having intermittent issues with the wan or not. im having trouble staying remotely logged in |
23:49.48 | FuriousGeorge | if it is having even one of these hiccups per week, the system is not gonna be useable, so there has to be something i can do |
23:49.58 | FuriousGeorge | enabling ice and keep alive in devices nat settings does not help |
23:52.10 | Samot | And are all the NAT settings correct on both sides? |
23:53.04 | ircarcs | hi world, i will probably have to deal with asterisk, as whre i work switch to something based on, i d like to know against my research on internet / and documentation / good tips or advices . or website i do'n know > ( the situation is > i have not many user but 150 .. and i will in futur to deal with it) .. thanls :) |
23:54.12 | ircarcs | i have no question but humain seems to be better than my poor research on the intenet. .. sometime :) |
23:56.07 | ircarcs | i have from the paste use openfire (but only on the xmpp side) |
23:56.45 | ircarcs | i d'ont know if it the good place to ask. sorry if don't |
23:57.15 | Samot | Are you using straight Asterisk or something that is using Asterisk? |
23:58.35 | ircarcs | acctually i don't know .. my compagny is going to switch from "NOT IP" to "IP" thing |
23:59.25 | ircarcs | but the cmpagny who deal with is open source minded and i know it s asterisk |