00:07.27 | *** join/#asterisk vader- (sid163236@gateway/web/irccloud.com/x-gadsctlryfcptkan) |
00:08.44 | *** join/#asterisk setham (uid214435@unaffiliated/setham) |
00:08.44 | *** join/#asterisk setham (uid214435@gateway/web/irccloud.com/x-wyxbpxfgiwkblcmc) |
00:10.54 | *** join/#asterisk setham (uid214435@gateway/web/irccloud.com/x-saidqlaxhxoyofok) |
00:13.05 | *** part/#asterisk kharwell (kharwell@nat/digium/x-mhjlynvgjukjwkhy) |
00:18.09 | *** join/#asterisk Hatsjoe (~Hatsjoe@unaffiliated/hatsjoe) |
00:27.07 | *** join/#asterisk trelane (trelane@unaffiliated/trelane) |
01:03.35 | *** join/#asterisk X-Rob (sid14615@gateway/web/irccloud.com/x-ejmtevguqbrezego) |
01:58.18 | *** join/#asterisk Iamnacho (~Iamnacho@ip70-171-163-5.om.om.cox.net) |
02:02.56 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
02:18.32 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
02:26.45 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
02:28.01 | *** join/#asterisk Kitsune (~Yuki@static-98-114-130-10.phlapa.ftas.verizon.net) |
02:33.23 | *** join/#asterisk Kitsune (~Yuki@static-98-114-130-10.phlapa.ftas.verizon.net) |
02:40.42 | igcewieling | Makes me wonder what they are thinking. Executing [99999350048825408632@incoming:2] Hangup("SIP/209.220.119.17-00000000", "34") in new stack |
02:41.01 | igcewieling | "add more nines until we hack the pbx"? |
02:53.37 | *** join/#asterisk libardi (~libardi@189.61.226.79) |
02:54.21 | *** join/#asterisk overyander (~Jeff@209.141.208.197) |
03:08.28 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
03:15.10 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
03:17.16 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
03:25.18 | *** join/#asterisk boris_t (~boris_t@94.190.2.146) |
03:33.13 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
03:44.52 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
03:55.58 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
04:08.57 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
04:10.59 | *** join/#asterisk cmendes0101 (~cmendes01@47-144-223-7.lsan.ca.frontiernet.net) |
04:11.08 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
04:17.39 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
04:20.02 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
04:40.56 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
05:02.13 | *** join/#asterisk warewolf (warewolf@warewolf.org) |
05:03.10 | warewolf | I'm having a really, really weird issue w/ asterisk-13.9.1 and SRTP; asterisk says "chan_sip.c:10715 process_sdp: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio" ... but in 'sip debug peer thatpeer' ... I see the a:crypto SDP lines. |
05:04.33 | warewolf | https://gist.github.com/warewolf/86dc4ff7f6d84864bbad9e58680779f2 <-- debug data |
05:05.26 | warewolf | line 135 has the SDP SRTP failure, but line 100 has crypto stuffs. |
05:05.31 | warewolf | scratches head |
05:20.36 | warewolf | maaaaan |
05:20.38 | warewolf | https://gist.githubusercontent.com/warewolf/86dc4ff7f6d84864bbad9e58680779f2/raw/516e38c4173c77dfe4038f3fb09aca9f909d485f/core_debug_logs-different_call.txt |
05:20.53 | warewolf | Processing media-level (audio) SDP a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ODc0MjU5AABmZWU0ZWMzADJkNWRlMmRkNjA2NDhm... OK. |
05:21.11 | warewolf | then "Failed to receive SDP offer/answer with required SRTP crypto attributes for audio".. lies! lies! lies! it's right there! |
05:21.50 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
05:43.25 | warewolf | aha! my hardware sip phone ignored my compulsory SRTP setting via config file. Manually frobbing that knob via the admin web UI makes everything happy. |
05:44.36 | anpi | warewolf: what phone might that be? |
05:44.45 | warewolf | yealink sip-t22p |
05:46.11 | tuxd00d | Which setting? |
05:46.20 | warewolf | #Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Forced, 2-Negotiated; |
05:46.23 | warewolf | account.1.srtp_encryption = 2 |
05:46.29 | warewolf | it was 1 before, I'm trying 2 now. |
05:46.43 | warewolf | in case some programmer has an off-by-one problem. Ya know. It happens. |
05:47.54 | tuxd00d | âIf it is set to 1 (Optional), the IP phone will negotiate with the other IP phone what type of encryption to utilize for the session. |
05:47.54 | tuxd00d | If it is set to 2 (Compulsory), the IP phone is forced to use SRTP during a call. The default value is 0.â |
05:48.26 | warewolf | oh balls, the comment in the config file was wrong? |
05:48.50 | tuxd00d | Are you using the latest firmware? |
05:49.39 | warewolf | probally not, but it's not ancient, I did update firmware at one point |
05:49.56 | warewolf | fw 7.72.0.80, hw 5.0.0.61 |
05:50.52 | tuxd00d | Should be running 7.73.0.50 |
05:51.03 | tuxd00d | http://download.support.yealink.com/download?path=upload%2Fattachment%2F2015-3-12%2F6%2Fd1421521-6b1c-44de-8603-55a815a0a0ab%2F7.73.0.50.zip |
05:52.09 | tuxd00d | The 7 is the model number, the 73 is the version, the 0 is the variant version, and 50 the subversion, ⦠if I remember correctly. |
05:52.15 | warewolf | cool, I'll find the change notes and check it out. |
05:52.27 | tuxd00d | http://download.support.yealink.com/download?path=upload%2Fattachment%2F2015-3-12%2F6%2F712a77a4-275f-4eac-bf97-1d9d2c562e53%2FYealink_SIP_phones_Relese_Notes_of_Version73.pdf |
05:53.03 | warewolf | wow |
05:53.20 | warewolf | (not about the release notes, but that you just keep throwing stuff at me that is helpful) |
05:53.34 | tuxd00d | I know Yealinks pretty well ⦠curse them a bit too |
05:54.01 | tuxd00d | They do remotely provision well though |
05:54.10 | warewolf | tuxd00d: you ever get features.temode = 1 to do anything useful? |
05:55.40 | tuxd00d | Iâm not familiar with temode, what is that? |
05:55.49 | warewolf | it's supposed to give you a shell on the phone. |
05:56.26 | tuxd00d | Never bothered with that yet. I did hear that they are running linux. |
05:56.40 | warewolf | yeah |
05:56.49 | warewolf | I got these phones because they're linux, and can do OpenVPN. |
05:57.25 | warewolf | at one point I was getting angry troubleshooting OpenVPN and really *really* wanted to poke around on the phone via shell, couldn't finagle it to do it though. |
05:58.18 | tuxd00d | Seem like pcapân would help with that. |
05:58.29 | warewolf | did find out that they overlay mount stuff in the flash FS that makes an /etc/passwd and /etc/shadow that aren't present in the fw image, which may be specific to each phone... at that point I soldered .1" headers to 5 pins I thought was JTAG and then never got around to actually JTAG'ing it. |
05:58.39 | tuxd00d | You can generate PCAP from the phone |
05:58.59 | warewolf | tuxd00d: it was config settings on the phone that was pissing me off; the filesystem paths the x509 certs end up are strange |
05:59.15 | tuxd00d | You have a bit of free time, donât you? ⦠:) |
05:59.31 | warewolf | sometimes. |
05:59.48 | tuxd00d | Itâs how we all learn :) |
05:59.54 | warewolf | I did successfully pick apart the firmware of another embedded linux device and found a backdoor password. |
06:00.12 | warewolf | got my first CVE outta that. :) |
06:00.39 | tuxd00d | I havenât played with OpenVPN on them yet. Although I was hoping to check it out soon. |
06:01.21 | tuxd00d | Neat |
06:01.29 | warewolf | oh wait, now I remember why I turned OpenVPN off on the primary T22P I use |
06:02.00 | warewolf | the periodic key refresh ... it eats up CPU on the phone and it basically drops call audio |
06:02.02 | tuxd00d | There is the overhead consideration also when running a VPN |
06:02.19 | tuxd00d | Exactly |
06:02.34 | warewolf | man, this is gonna piss off my fiancee in hawaii when I give her a phone that does HD audio so we can chat, and every 5 minutes or something the call audio goes poof for a moment |
06:03.02 | tuxd00d | VPN is overkill for most situations |
06:03.11 | warewolf | regular telco calls from hawaii to virginia sounds like poop, and I have to keep asking her to repeaet herself. It doesn't help that she speaks softly to begin with |
06:03.12 | tuxd00d | Or it can be done on the routers |
06:04.23 | *** join/#asterisk vstemen (~vince@ip72-202-187-29.ok.ok.cox.net) |
06:04.35 | warewolf | tuxd00d: oh, see I set this phone up to be plug and play (hopefully). The VPN stuff is to make DAMN sure there aren't NAT issues, which I was running into when I was trying to do sip/tls+srtp before. One way audio sucks :( |
06:05.38 | tuxd00d | There is that benefit of Asterisk being able to increase the volume of the fiancee |
06:06.51 | tuxd00d | With Asterisk not behind a NAT, NAT issues are rare. |
06:07.24 | warewolf | this was even w/ the server not behind nat :/ I couldn't get video working :/ |
06:07.31 | tuxd00d | Turn off any SIP / NAT helpers in the client side router⦠and youâre good to go |
06:07.46 | tuxd00d | Video⦠you fancy |
06:08.02 | warewolf | (natted client)--> public internet facing asterisk <--(natted client) |
06:08.38 | warewolf | alright, time for me to hit the bed. Thanks for the help! |
06:08.40 | tuxd00d | Make sure your prevent RTP reinvite |
06:09.14 | tuxd00d | directmedia=no ⦠and such |
06:09.28 | tuxd00d | warewolf: Take care |
06:24.13 | *** join/#asterisk jkroon (~jkroon@165.16.204.42) |
06:51.43 | *** join/#asterisk setham (uid214435@gateway/web/irccloud.com/x-icskkkuqtmnpnrcq) |
06:57.00 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
07:35.33 | vstemen | tuxd00d, Hah! I have been fighting for the last couple days to get audio working with our voip.ms service with asterisk and our ATA's behind nat . I finally found the "directmedia=no" setting in my "Asterisk - The Definitive Guide" book, which fixed it just a few minutes ago. The I glance over at my IRC window and here you mention it. |
07:36.58 | vstemen | s/the I/then I/ |
07:40.06 | tuxd00d | vstemen: Awesome :) |
07:44.01 | vstemen | :-) |
07:44.08 | vstemen | goes to bed finally |
08:09.37 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::152e) |
08:10.55 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
08:11.05 | *** join/#asterisk Jack17 (~jackkk@212.34.12.121) |
08:12.24 | Jack17 | Hello guys , My asterisk keep crashing suddenly all calls drops |
08:12.36 | Jack17 | and in the cli it stop showing anything where can i check the crash log |
08:12.55 | Jack17 | 8 cores cpu i had 150 calls and up |
08:16.11 | snadge | Ouch. |
08:16.38 | snadge | Our trick is to use a massively outdated version of asterisk and not touch it because ot works. ;) |
08:17.24 | snadge | And do daily restarts at 3am |
08:17.56 | Jack17 | daily restart is enough |
08:18.08 | Jack17 | because it keeps crashing every couple of hours |
08:18.40 | snadge | Try a cert version maybe. It could also be hardware related. |
08:19.40 | snadge | Compile with symbols enabled and run it in a debugger, then do a backtrace when it crashes maybe. |
08:20.00 | snadge | Or at least debug the core dump if it has one. |
08:21.01 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
08:24.19 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
08:37.00 | *** join/#asterisk guest_go390 (~guest_go3@185.32.9.250) |
08:37.22 | guest_go390 | Samot, callsign go390 calling. NAT changes had no effect, still issue with MoH not stopping properly. |
08:38.56 | Jack17 | now it crashed |
08:39.12 | Jack17 | how can i know the error |
08:40.50 | Jack17 | hello |
08:53.56 | snadge | Look at the logs, check for a core file. |
08:54.43 | GeneralSpongebob | Jack17, which version of Asterisk are you using? |
08:55.54 | GeneralSpongebob | Alrighty then |
08:59.47 | snadge | Ping timeout is the best version of asterisk |
09:02.38 | *** join/#asterisk smkelly (~smkelly@mykonos.smkelly.org) |
09:06.21 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
09:20.50 | *** join/#asterisk jack17 (~jackkk@92.253.60.127) |
09:39.55 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
09:50.27 | guest_go390 | Can someone please tell me why this is happening? Scenario: http://pastebin.com/cVUYPYBN |
09:50.44 | guest_go390 | When the attended transfer is performed, the agent is still, according to queue show (in call). |
09:51.00 | guest_go390 | it seems like Asterisk will not realised that the attended transfer has been performed. |
09:53.25 | *** join/#asterisk bipolar (~bipolar@offsite.guru) |
09:56.44 | *** join/#asterisk Kaian (~kaian@6.62-99-78.static.clientes.euskaltel.es) |
10:02.23 | jack17 | !pb |
10:02.26 | jack17 | ~pb |
10:02.26 | infobot | rumour has 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. |
10:03.07 | jack17 | https://gist.github.com/anonymous/0fc6375cb853cf8e4b2b0ad0ec888fed |
10:03.10 | jack17 | asterisk crashing |
10:04.46 | jack17 | <PROTECTED> |
10:05.14 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
10:07.09 | jack17 | Guys please |
10:09.06 | jack17 | ''''/usr/sbin/safe_asterisk: line 152: 20423 Segmentation fault (core dumped) nice -n $PRIORITY "${ASTSBINDIR}/asterisk" -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY} |
10:09.50 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.43) |
10:10.01 | jack17 | Samot |
10:10.04 | jack17 | You there bro |
10:10.29 | tuxd00d | jack17: He does sleep, occasionally. |
10:11.39 | tuxd00d | jack17: What version of Asterisk? |
10:11.50 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.44) |
10:12.05 | tuxd00d | jack17: Did is just start recently, or has it always crashed? |
10:13.22 | jack17 | when it reach 180 calls |
10:13.38 | tuxd00d | guest_go390: Without a full PCAP of the call (and only the single call), we canât hhelp you. |
10:14.54 | tuxd00d | jack17: Are you hitting any max limits as set in asterisk.conf? |
10:15.31 | tuxd00d | Are you hitting an operating system limits, open file limits, etc? |
10:17.05 | tuxd00d | guest_go390: Reviewing the PCAP will tell you what is happening. You may be able to see it in Asteriskâs SIP debug. |
10:18.23 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
10:19.29 | tuxd00d | jack17: Which version of Asterisk? |
10:20.35 | jack17 | Asterisk 1.8.32.3, Copyright (C) 1999 - 2013 Digium, Inc. and others |
10:23.24 | tuxd00d | jack17: Thatâs almost 6 years old. This isnât running on the FreePBX platform or anything, is it? |
10:25.56 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:ba27:ebff:fee4:a52f) |
10:26.32 | *** join/#asterisk tuxian (~tuxian@194.12.3.78) |
10:30.03 | *** join/#asterisk Demon_VoIP (~demon@109.60.135.186) |
10:31.14 | Demon_VoIP | Hello. I can't find answer for simple question. Help me. Is there any dialplan function or variable to get CALL-ID for logging? https://wiki.asterisk.org/wiki/display/AST/Call+Identifier+Logging |
10:51.30 | tuxd00d | Demon_VoIP: Are you wanting to use the Call ID in your dial plan? |
10:59.32 | Demon_VoIP | tuxd00d, store it to CDR and grep call logs via script for demand |
11:00.51 | tuxd00d | Are you just looking for a unique identifier, or does it have to be Call ID? |
11:02.19 | Demon_VoIP | I don't know any other identifire that be in any (text) log row of call. UniqureID or channel-name (one, two, more?) are not there. |
11:04.58 | tuxd00d | Check out cdr_custom.conf |
11:06.28 | tuxd00d | and https://wiki.asterisk.org/wiki/display/AST/CDR+Variables |
11:08.39 | jack17 | tuxd00d ? |
11:08.39 | tuxd00d | Also check out Channel Event Logging. |
11:09.06 | tuxd00d | Demon_VoIP: Itâs hard to help you out when we donât know what your end goal is. |
11:10.08 | tuxd00d | jack17: Are you running your own compiled version of Asterisk, one installed from your linux distro repository, or a packaged distro like FreePBX, Elastix, etc? |
11:10.19 | *** join/#asterisk chendy (~alexc@183.12.66.244) |
11:12.26 | *** join/#asterisk c0rnoTa (~c0rnoTa@109.248.224.152) |
11:12.28 | *** part/#asterisk c0rnoTa (~c0rnoTa@109.248.224.152) |
11:13.04 | jack17 | tuxd00d mor if u know it |
11:14.44 | Demon_VoIP | tuxd00d, my goal: grep all text logs by single call (not channel, but call). what I should have to do that? I think call-id. What else? |
11:15.02 | tuxd00d | jack17: from Kolmisoft? |
11:18.04 | tuxd00d | Demon_VoIP: Perhaps you should explore the Channel Variable ${UNIQUEID} |
11:19.20 | Demon_VoIP | tuxd00d, no, i shouldn't. There in the text log do you see it? Only in row with NoOp. Single row. |
11:20.04 | *** join/#asterisk bof23 (~Thunderbi@185.13.183.107) |
11:21.10 | tuxd00d | Demon_VoIP: Are you trying to create individual log files for each call? |
11:21.58 | tuxd00d | Demon_VoIP: Iâm sorry, Iâm having difficulty understanding what you are wanting to accomplish. |
11:22.34 | Demon_VoIP | tuxd00d, only by demand. Individual log file for one call. |
11:24.47 | tuxd00d | Demon_VoIP: What version of Asterisk? |
11:24.55 | Demon_VoIP | 13.14 |
11:26.35 | tuxd00d | And your log files donât contain a C-XXXXXXXX on each line dealing with a call/ |
11:26.36 | tuxd00d | ? |
11:27.54 | Demon_VoIP | Log files contain CALL-ID. But CDR of dialplan func can't give me access to it's value. |
11:28.45 | Demon_VoIP | There are a lot of calls in CDR. I see one. What should I do to get single log file for single call? |
11:30.01 | Demon_VoIP | I should do TWO grep. Am i right? |
11:32.38 | *** join/#asterisk chendy (~alexc@183.12.66.244) |
11:33.41 | tuxd00d | Iâm not aware of a way to use the Call ID in the dial plan. But you can put in a âVerbose(Unique ID = ${UNIQUEID})â which will show up in the log on a line with the Call ID. |
11:34.46 | *** join/#asterisk Jack17 (~jackkk@212.34.12.121) |
11:35.02 | Jack17 | tuxd00d yes |
11:35.04 | Jack17 | frm kolmisoft |
11:36.29 | tuxd00d | jack17: You wonât find anyone here who will be willing to help diagnose anything other than an unmodified recent version of Asterisk. Youâll have to contact Klmisoft for support. |
11:36.50 | tuxd00d | jack17: Sure, weâd like to help, but we donât know their software. |
11:37.21 | *** join/#asterisk Chotaire (chotaire@oahu.chotaire.net) |
11:37.29 | tuxd00d | jack17: Just because their product is based on Asterisk, it doesnât mean it behaves like it. |
11:38.16 | WIMPy | wonders how he got a call through to a peer that was UNREACHABLE. |
11:38.40 | tuxd00d | Increased the UDP time to 14400. |
11:39.00 | tuxd00d | timeout on the SonicWall at the clientâs site. |
11:39.49 | tuxd00d | Or were you talking about your experience? |
11:40.50 | WIMPy | Me? Yes, it's something I just saw in the log happening yesterday. Which shouldn't be possible. |
11:41.26 | tuxd00d | Calls can come in from an UNREACHABLE device. |
11:41.48 | WIMPy | No, it was TO that device. |
11:41.54 | tuxd00d | But youâre saying the call went to the UNREACHABLE |
11:42.26 | *** join/#asterisk Syco (562b5b94@gateway/web/freenode/ip.86.43.91.148) |
11:42.34 | tuxd00d | Perhaps it was briefly REACHABLE ;-) |
11:43.00 | WIMPy | I said the peer was UNREACHABLE. That was since 13 minutes before the call. It became reachable again 39 Minutes after the call. |
11:43.36 | WIMPy | So it shouldn't even have tried the call. |
11:43.54 | tuxd00d | One would assume. |
11:44.23 | tuxd00d | What one wouldnât give to be a fly on the wall of that PCAP. |
11:45.53 | WIMPy | I already had the impression before that the status changes writte to the logs and those reported via AMI aren't always identical. But in this particular case it looks like neither one is correct. |
11:46.21 | Jack17 | tuxd00d i showed u the errror |
11:47.38 | WIMPy | Looks like chan_sip was rather F***ed up. :-( |
11:48.50 | WIMPy | I just restarted Asterisk and now I see peers registering with new IPs which most probably should have happened tonight. |
11:49.01 | WIMPy | :-( |
11:51.36 | tuxd00d | jack17: Yes, but I donât know their software. We donât mind helping out where we can, but we simply donât know their software, which likely includes a non standard compilation of Asterisk. Plus, it is a really old and no longer supported version of Asterisk that it was based on. #asterisk is not the place to ask for help for that product. |
11:52.31 | tuxd00d | WIMPy: How odd. Sometimes Asterisk can get a little foggy brained. |
11:52.55 | WIMPy | Yes :-( |
12:01.07 | *** join/#asterisk josecapurro (~jcapurro@181.40.119.210) |
12:03.38 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::152e) |
12:08.20 | WIMPy | Ok, a bit of relief. The call actually didn;t work. It was forwarded. |
12:08.44 | WIMPy | But still it didn't process registrations while it still processed calls. |
12:09.25 | tuxd00d | Iâve never seen that happen before. Thatâs interesting. |
12:12.19 | *** join/#asterisk MacroMan (~MacroMan@host213-123-31-77.in-addr.btopenworld.com) |
12:24.17 | AdNauseum | anyone running asterisk on centos 7 ? |
12:27.13 | guest_go390 | eart calling Samot |
12:27.18 | guest_go390 | earth ofc |
13:12.58 | guest_go390 | AdNauseum, sure |
13:13.06 | guest_go390 | Centos7 and Redhat 7 |
13:29.04 | AdNauseum | encounter any issues using centos 7? |
13:29.09 | AdNauseum | do you use freepbx ? |
13:30.29 | *** join/#asterisk mknooihuisen (~mknooihui@12.150.48.70) |
13:34.57 | *** join/#asterisk Samot (sid133316@gateway/web/irccloud.com/x-rzoshiqxbznsbuoq) |
13:39.41 | *** join/#asterisk d00gster_ (~d00gster@unaffiliated/d00gster) |
13:41.01 | guest_go390 | No issues really, what issues? |
13:43.26 | dan_j | I've got queue ringinuse set, but it appears that occasionally the in-use phone does not ring. Nothing on the CLI to indicate why that phone was not called. |
13:45.33 | dan_j | It worked fine in v11, but seems to have been introduced in 13. |
13:45.40 | dan_j | Has anyone else experienced this issue? |
13:46.43 | WIMPy | You're having lots of fun with 13? |
13:50.53 | Samot | guest_go390: Yes? |
13:52.30 | guest_go390 | NAT changes had no effect to yesterdays issue. |
13:52.49 | guest_go390 | The only thing that seems to solve it is for the agent to retrieve the holding incoming part before the actuall transfer. |
13:53.03 | Samot | What softphones? |
13:54.07 | guest_go390 | By XeniaLab, however. It looks like the softphone is indeed responsible for the MoH, and it may be doing stupid stuff. It has been reported. |
13:54.19 | dan_j | WIMPy: yeh. driving me crazy. |
13:54.55 | dan_j | WIMPy: and this is after testing it for 12 months. typically, all the issues appear only when it's moved to production |
13:55.02 | Samot | Try a different softphone, try a physical phone.. |
13:55.35 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
13:55.55 | guest_go390 | As you know it is very hard to replicate it. I can change softphone but may end up transfering and dialing for years. |
13:56.05 | WIMPy | Ahh, good old Murphy. |
13:56.44 | guest_go390 | I am just going to let the softphone developers sort this out. My energy for this issue has been depleted. |
13:57.49 | Samot | Well.. |
13:57.52 | Samot | You've said you have had this issue for 6 months. |
13:58.08 | guest_go390 | Did I? Even if I did that would be a lie, more like one year |
13:58.13 | Samot | So if you change the softphone and it actually transfers properly... |
13:58.18 | guest_go390 | 16 months Did I not? |
13:58.31 | Samot | Then you're already a step a head. |
13:58.36 | guest_go390 | Yeah we performed short burts with other softphones, it was never a substainable test. |
13:59.08 | Samot | Oh 16 months |
13:59.08 | Samot | So yes, try a phone. |
13:59.08 | Samot | A new one. |
14:00.47 | Samot | What were the results? |
14:04.31 | guest_go390 | Cannot say anything really from those tests for several reasons. 1) The agents are generally technical handicapped, trying to get them to learn a new softphone is expensive and time demanding. 2) The tests did not last long enough. Why? Because the agents are dependent on their current softphone due to pause statuses and such. |
14:04.50 | guest_go390 | We did however perform these tests by ourself, but after houndreds of transfers we were not satisfied |
14:06.00 | Samot | Why's that? |
14:19.58 | *** join/#asterisk X-Rob (sid14615@gateway/web/irccloud.com/x-tyxgrnthvfvrbgzp) |
14:24.42 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
14:27.26 | *** join/#asterisk newtonr (~newtonr@173-17-133-211.client.mchsi.com) |
14:27.26 | *** mode/#asterisk [+o newtonr] by ChanServ |
14:30.15 | warewolf | tuxd00d: thanks! I already had directmedia=no in my sip.conf. I guess I did half decent research when I decided to put asterisk on the public internet. |
14:37.21 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
14:37.21 | *** mode/#asterisk [+o cresl1n] by ChanServ |
14:38.17 | guest_go390 | Samot: because we cannot replicate it on demand, I dont figure we managed to replicate it once. Not to metion we have not been able to replice it with the fauly softphone as well. |
14:38.30 | guest_go390 | Because it is rare, and this customer have high loads |
14:41.13 | Samot | And while you were testing these things and not being able to replicate them, where the issues still happening on the other softphones? |
14:42.30 | Samot | 16 months just seems like a long time to use a softphone that always seems to produce the problem when you can't replicate it on other softphones. Not even on the low end. |
14:44.58 | guest_go390 | Yeah its been happening every day since day 1. Now it's probaly a bigger cover up. |
14:46.05 | Samot | I would have moved to other softphones to see if it kept happening. |
14:48.15 | *** join/#asterisk igcewieling (~ewieling@162-236-85-155.lightspeed.moblal.sbcglobal.net) |
14:48.20 | Samot | 1) The agents are generally technical handicapped, trying to get them to learn a new softphone is expensive and time demanding. |
14:49.09 | Samot | ^^^ Is is more expensive and time demanding than 16 months of lost calls, customer dissatisfaction and the time spent troubleshooting and trying to solve the issue? |
14:49.35 | Samot | s/is/it/ |
14:52.48 | guest_go390 | If we change softphone we will drop a lot of critical features |
14:53.05 | Samot | Are you saying another softphone won't have them? |
14:53.17 | guest_go390 | Yes |
14:53.19 | Samot | What critical features? |
14:53.36 | Samot | Did you deploy a customized softphone? |
14:53.40 | guest_go390 | Queue control, chat, pause codes, custom integratios |
14:53.45 | guest_go390 | integrations |
14:54.01 | Samot | OK, other softphones have chat/IM abilities. |
14:55.58 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:ba27:ebff:fee4:a52f) |
14:56.56 | Samot | What pause codes? |
14:56.56 | Samot | Just codes they punch into the softphone digit pad? |
14:57.25 | guest_go390 | No they select a pause from a dropdown in the softphone. Also they have a Smart ACW feature. |
14:57.57 | Samot | What was the move from Avaya to Asterisk for? |
14:58.20 | guest_go390 | Because no-one wants to work with Avaya, simply put |
14:58.35 | Samot | And how much time was spent interoping? |
14:58.44 | guest_go390 | Avaya was never really good at call center solutions |
14:59.39 | Samot | Well Asterisk is only as good as the person configuring it. |
14:59.59 | guest_go390 | But still almost unlimited capabilities |
15:00.10 | Samot | Based on the person configuring it. |
15:00.29 | *** join/#asterisk EnrgySmth_ (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
15:00.47 | Samot | I can cook a 6 course meal |
15:01.05 | Samot | Not going to say it's going to be the greatest in the world because my cooking skills are that spectacular. |
15:02.03 | guest_go390 | What is your point? |
15:02.12 | *** join/#asterisk Dovid (~dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
15:02.37 | Samot | The argument that Asterisk has unlimited capabilities. |
15:02.42 | Samot | First, it doesnt. |
15:02.49 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
15:03.06 | Samot | Second, no matter what it's abilities are you have to figure out how to make them work the way you want. |
15:04.05 | *** part/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
15:05.42 | Samot | Third, since this problem has been happening since day one of going "live" this should have been caught during the interop/testing phase. |
15:07.17 | *** join/#asterisk kharwell (kharwell@nat/digium/x-zqcgorwzjpyljnao) |
15:07.17 | *** mode/#asterisk [+o kharwell] by ChanServ |
15:07.57 | Samot | You've kind of put yourself in a corner on this. |
15:08.09 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
15:30.07 | guest_go390 | Sorry Samot, I had a fire in the building and had to evacuate |
15:30.37 | guest_go390 | I dont see how any of the above can relate to the issues. |
15:30.42 | guest_go390 | Or how it can help me |
15:31.01 | guest_go390 | The setup is done, I cannot go back in time and correct it. |
15:31.06 | *** join/#asterisk Samot (sid133316@gateway/web/irccloud.com/x-bwplwrunwdcmklan) |
15:35.54 | *** join/#asterisk d00gster_ (~d00gster@unaffiliated/d00gster) |
15:48.18 | vstemen | Hi guest_go390, Looks like Samot temporarily disconnected and didn't see your last message. |
15:48.40 | Samot | Apparently. |
15:51.55 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
16:01.56 | *** join/#asterisk d00gster_ (~d00gster@unaffiliated/d00gster) |
16:05.28 | *** join/#asterisk TriJetScud (~TriJetScu@van-mig-svr.ad.v10networks.ca) |
16:14.54 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-sriaahvzpdtnxerz) |
16:14.54 | *** mode/#asterisk [+o rmudgett] by ChanServ |
16:15.46 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
16:30.40 | *** join/#asterisk setham (~setham@unaffiliated/setham) |
16:32.25 | *** join/#asterisk Oatmeal (~Suzeanne@c-68-45-50-54.hsd1.in.comcast.net) |
16:42.38 | *** join/#asterisk d00gster (~d00gster@unaffiliated/d00gster) |
16:44.41 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
16:47.22 | *** join/#asterisk newtonr (~newtonr@173-17-133-211.client.mchsi.com) |
16:47.22 | *** mode/#asterisk [+o newtonr] by ChanServ |
16:48.02 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
16:53.42 | *** join/#asterisk jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
17:18.38 | MacroMan | If it's any use to anyone, I have re-engineered the tone generator used in Asterisk in the JS Web Audio API, so you can play any Asterisk formatted tone pattern in a browser: https://github.com/MacroMan/PhoneTones |
17:19.24 | MacroMan | Sorry, not meaning to spam. Genuinly believe it may be of interest to people here. |
17:21.25 | *** join/#asterisk gswain (uid91227@gateway/web/irccloud.com/x-nifksrxtnyzwhntk) |
17:22.20 | gswain | what goes in /var/spool/asterisk/monitor /month/date? These keep filling up just curious what is in there |
17:22.58 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
17:23.31 | gswain | everything i google seems to have to do wiuth call recording but im not aware that im doing any of htat |
17:42.13 | [TK]D-Fender | Check your logs |
17:42.16 | [TK]D-Fender | and yyour config |
17:42.38 | [TK]D-Fender | You should know if you enabled on-demand or have any deliberate dialplan executed recording |
17:44.19 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
17:48.32 | gswain | bah it looks like an outbound trunk was set to force recordings |
17:49.49 | gswain | can I blow away the day directories now that I have disabled the recordings if I dont want them |
17:55.16 | *** join/#asterisk MatsK (~Mats@213-65-164-83-no63.tbcn.telia.com) |
18:01.35 | [TK]D-Fender | yes |
19:01.07 | *** join/#asterisk MaliutaLap (~nobusines@unaffiliated/maliuta) |
19:06.37 | *** join/#asterisk X-Rob (sid14615@gateway/web/irccloud.com/x-lrkbevkoariwzeex) |
19:09.59 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
19:12.57 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
19:30.55 | *** join/#asterisk Bhakimi (~textual@208.78.137.2) |
19:31.09 | Bhakimi | anyone knows what can be the cause of this error message? : Received trunked frame before first full voice frame |
19:39.11 | *** join/#asterisk dougbtv (~doug@209.99.210.136) |
19:42.44 | igcewieling | Bhakimi: maybe one side is setup for IAX2 trunking mode and the other is not. So few people use IAX2 these days you might have trouble finding someone to help. |
19:49.13 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
19:56.15 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
20:28.06 | *** join/#asterisk johnny_|_ (~johnny@unaffiliated/johnny-/x-2623418) |
20:30.11 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
20:50.52 | *** join/#asterisk Bhakimi (~textual@208.78.137.2) |
20:50.54 | Bhakimi | igcewieling: both are IAX trunks and it only happens randomly |
20:50.57 | Bhakimi | igcewieling: both are IAX trunks and it only happens randomly |
20:56.13 | igcewieling | Bhakimi: do both servers have dahdi loaded? IAX trunking requires DAHDI timing. |
20:56.35 | Bhakimi | yes sir |
20:56.53 | Bhakimi | these are two asterisk 11.22 boxes identical in config and hardware |
20:57.20 | Bhakimi | we use it to send a call from one box to naother, we choose iax because its faster and native to asterisk |
20:58.02 | igcewieling | trunking uses more bandwidth when there is only one call |
21:11.25 | [TK]D-Fender | <igcewieling> Bhakimi: do both servers have dahdi loaded? IAX trunking requires DAHDI timing. <- not for a while now... |
21:11.39 | Bhakimi | yes they both run dahdi |
21:11.45 | Bhakimi | and dahdi_dummy which is not build in dahdi |
21:11.46 | [TK]D-Fender | they're removed it as a requirement |
21:11.58 | [TK]D-Fender | same iwht Page, etc |
21:12.02 | Bhakimi | well there are other timing sources |
21:12.10 | Bhakimi | but i preffer to stick with dahdi |
21:12.25 | Bhakimi | in 11 its still avaliable |
21:29.53 | *** join/#asterisk putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
21:29.53 | *** mode/#asterisk [+o putnopvut] by ChanServ |
21:34.43 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
21:41.15 | *** join/#asterisk setham_ (~setham@unaffiliated/setham) |
21:41.55 | *** join/#asterisk hyegeek (~hakimian@wsip-72-214-228-246.ph.ph.cox.net) |
21:44.05 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
21:55.30 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
21:58.31 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
22:11.38 | *** join/#asterisk rwb (~Thunderbi@65.183.151.239) |
22:26.35 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:3d4c:ed73:ede7:c0ef) |
22:27.27 | *** join/#asterisk setham (~setham@unaffiliated/setham) |
22:57.03 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
23:01.57 | *** join/#asterisk Milos_ (~Milos@pdpc/supporter/student/milos) |
23:10.07 | *** join/#asterisk [NC] (~nc@rv1.sabius.net) |
23:19.57 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
23:29.31 | *** join/#asterisk lankanmon (~LKNnet@2607:fea8:d1f:fc17:11e0:707c:2961:d41e) |
23:31.46 | *** join/#asterisk j0hnd0e (~j0hnd0e@24.48.86.58) |