00:03.20 | *** join/#asterisk tuxd00d (~tuxd00d@72.205.132.11) |
00:20.48 | *** join/#asterisk infobot (ibot@rikers.org) |
00:20.48 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.14.0 (2017/02/13), 11.25.1 (2016/12/08), Standard: 14.3.0 (2017/02/13); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
00:35.43 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
00:36.26 | *** join/#asterisk tuxd00d (~tuxd00d@wsip-70-164-41-93.dc.dc.cox.net) |
01:20.12 | *** join/#asterisk shootbird (~quassel@205.185.122.214) |
01:41.25 | *** join/#asterisk TandyUK (~admin@2a02:13a0:a006:1:1501:1e96:dc15:a3a1) |
02:24.54 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
02:48.32 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
03:20.18 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
04:01.16 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
04:12.13 | *** join/#asterisk radicaldev (~radicalde@c-98-200-129-131.hsd1.tx.comcast.net) |
04:54.57 | *** join/#asterisk qloogkm[m] (qloogkmmat@gateway/shell/matrix.org/x-ngmihpqwvnaalwce) |
05:03.02 | *** join/#asterisk miralin (~Thunderbi@194.8.128.118) |
05:28.49 | *** join/#asterisk miralin (~Thunderbi@194.8.128.118) |
05:36.22 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
06:00.43 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
06:07.07 | *** join/#asterisk Haris (~haris@unaffiliated/haris) |
06:07.09 | Haris | hello all |
06:08.42 | Haris | eyebeam softphone plus the 3cx one are both showing a 100ms latency on freepbx distro 13 install of asterisk |
06:10.54 | drmessano | Where is the PBX Located in relation to the softphone? |
06:11.06 | Haris | on wired LAN |
06:11.20 | Haris | at a distance of 50meter |
06:11.29 | Haris | gigabit connectivity |
06:11.52 | drmessano | 100ms is the ping times? |
06:12.02 | Haris | ping time is standard 1ms |
06:12.23 | drmessano | Ok, where do you see this 100ms? |
06:12.31 | Haris | 100 ms is the time I see in sip show peers output on aterisk cli |
06:12.33 | Haris | asterisk+ |
06:12.54 | Haris | for agents/extensions connected to this PBX |
06:13.04 | Haris | when using eyebeam or 3cx soft phone |
06:13.19 | Haris | when using microsip, the registration time is 1ms |
06:13.30 | Haris | registration = sip show peers output |
06:16.28 | drmessano | so youre saying ANY agent using Eyebeam or 3cx is 100ms |
06:16.38 | drmessano | But ANY agent using MicroSIP is 1ms? |
06:16.48 | Haris | yep |
06:17.04 | Haris | 100ms - 105ms on average |
06:17.10 | drmessano | Okay are you experiencing any actual problems? |
06:19.34 | drmessano | Wow, really? |
06:20.10 | Samot | It's the QUALIFY TIME |
06:20.23 | Samot | If you turned off qualify you wouldn't even see that 100ms |
06:20.29 | drmessano | Yeah I just saw that he's ignored me to talk in the other channel |
06:20.29 | Samot | It would just be unmonitored. |
06:20.38 | Samot | Well he asked there too |
06:20.47 | Samot | And got answers while he was asking in here.. |
06:20.57 | Haris | hmm |
06:21.24 | Samot | What is the ACTUAL audio issue? |
06:21.32 | Samot | What is the "poor quality" issue? |
06:21.46 | Haris | I'm working on getting other functions of the softphone working with the sip exch (i.e., asterisk), like agent not ready, dnd, etc etc |
06:22.00 | Haris | and call quality tests to see which tool(s) are conducive for work |
06:22.13 | drmessano | So what is the actual PROBLEM? |
06:22.19 | drmessano | Other than obsessing over qualify times |
06:22.37 | Haris | the other end was getting voice with interruption(s) in the middle |
06:22.50 | Haris | making them not able to hear the agent's word(s) completely |
06:22.52 | Haris | or clearly |
06:22.57 | drmessano | and this was a LAN user? |
06:23.06 | Haris | we bought better head gear for that |
06:23.10 | Haris | yep |
06:23.25 | *** join/#asterisk kados (~kados@c-73-243-248-133.hsd1.co.comcast.net) |
06:23.32 | drmessano | I would suggest checking the machine for standard workstation issues |
06:23.47 | drmessano | If the network is fine, the machine could be latent in other ways |
06:23.59 | Haris | its a laptop. basic voice recording showed no problem with the less expensive head gear |
06:24.12 | Haris | basic OS + MS Office + soft phone + files to keep record(s) in |
06:24.18 | Haris | + basic browsing |
06:24.23 | Samot | I never understand why call centers work off softphones. |
06:24.24 | drmessano | I dont care |
06:24.27 | Haris | 4G RAM |
06:24.28 | drmessano | I would suggest checking the machine for standard workstation issues |
06:24.42 | Samot | Haris, the PC can impact the calls. |
06:24.44 | drmessano | It has 4G RAM, so what |
06:24.51 | Samot | If it's busy doing other stuff. |
06:24.55 | Haris | prefer an ata device to a softphone ? |
06:24.56 | drmessano | It's not doing much, so what |
06:25.02 | drmessano | Go play IT guy on the workstation |
06:25.10 | drmessano | Check for the usual problems |
06:25.27 | Samot | Well when you are doing something that requires you calls to be perfect quality and not have issues... |
06:25.39 | drmessano | You've narrowed this down to ONE device. What is the common denominator? |
06:26.00 | Haris | drmessano: that last msg went over me |
06:26.03 | Samot | Using a softphone on a system that is doing a bunch of other stuff and could degrade the performance of the softphone program and thus the calls.... |
06:26.14 | drmessano | ....... |
06:26.17 | drmessano | Replace the laptop |
06:26.21 | drmessano | or fix it |
06:26.25 | Haris | ah that |
06:26.29 | drmessano | Its not an Asterisk issue |
06:26.30 | Samot | It's only this softphone. |
06:26.33 | drmessano | or a Softphone issue |
06:26.35 | Samot | On this laptop. |
06:26.41 | drmessano | Its the laptop |
06:26.44 | drmessano | FIX OR REPLACE IT |
06:26.44 | Haris | with the new headgear, calls quality became ok |
06:26.44 | Samot | ^^^^^ |
06:26.59 | Haris | it wasn't the laptop |
06:27.02 | Haris | machine was idle |
06:27.05 | drmessano | Stop talking about how great it is, and how little its doing and how it has 4G of RAM |
06:27.11 | Samot | Idle doesn't mean shit. |
06:27.11 | drmessano | 4G of RAM aint shit |
06:27.15 | Haris | I know |
06:27.20 | Samot | It is still DOING STUFF |
06:27.20 | drmessano | Stop talking about how great it is, and how little its doing and how it has 4G of RAM |
06:27.24 | drmessano | Go FIX IT |
06:27.26 | Haris | I'll check the machine |
06:27.28 | Samot | Resources are still allocated. |
06:27.47 | Haris | bbl |
06:27.47 | drmessano | Reimage it, replace it, something |
06:38.35 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
06:56.46 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
07:01.46 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
07:21.18 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
07:53.27 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
08:14.50 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
08:14.52 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::10de) |
08:19.31 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
08:25.13 | *** join/#asterisk samwierema (~samwierem@095-097-255-066.static.chello.nl) |
08:27.59 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::10de) |
09:04.57 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
09:17.59 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
09:19.22 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
09:24.33 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
09:33.27 | *** join/#asterisk Iamnacho (~Iamnacho@ip70-171-163-5.om.om.cox.net) |
09:46.20 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
10:02.45 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
10:08.18 | *** join/#asterisk sekil (~sekil@cable-89-216-193-62.dynamic.sbb.rs) |
10:15.04 | *** join/#asterisk Kaian (~kaian@62.99.78.6) |
10:17.20 | JensV | Could someone enlighten me how the minor release cycle is handled? Is there a fixed time on how long until the next major release? Specifically looking for 13.15 |
10:20.00 | file | there is an aim of every 4-6 weeks |
10:20.05 | file | but it's not a fixed schedule |
10:20.22 | file | 13.15 will probably land in a week or a bit more |
10:21.34 | JensV | Alright, thank you |
10:23.33 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
10:24.57 | *** join/#asterisk JensV (~JensV@85.195.255.242) |
10:25.35 | *** join/#asterisk tuxian (~tuxian@194.12.3.78) |
11:03.29 | *** join/#asterisk Sprocks (~Sprocks@bmtnon3746w-lp130-03-74-14-78-25.dsl.bell.ca) |
11:32.38 | *** join/#asterisk d00gster (~d00gster@unaffiliated/d00gster) |
11:52.31 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
12:08.56 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
12:17.07 | *** join/#asterisk dougbtv (~doug@cable69-54-6-100.stoweaccess.com) |
12:24.16 | *** join/#asterisk mog (~mog@fsf/member/mog) |
12:34.47 | *** join/#asterisk DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
12:34.47 | *** mode/#asterisk [+o DivideBy0x0] by ChanServ |
12:37.53 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
12:48.42 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
12:48.42 | *** mode/#asterisk [+o cresl1n] by ChanServ |
13:00.51 | *** join/#asterisk Y04NN (~y04nn@77.154.204.55) |
13:04.42 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-pzqxeqlfygwzmkhl) |
13:06.39 | *** join/#asterisk Y04NN (~y04nn@55.204.154.77.rev.sfr.net) |
13:08.40 | *** join/#asterisk bof23 (~Thunderbi@185.13.183.107) |
13:09.12 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
13:10.24 | *** join/#asterisk MacroMan (~MacroMan@host213-123-31-77.in-addr.btopenworld.com) |
13:10.52 | MacroMan | Is there a dialplan application to unregister another peer? Google turned up not a lot. |
13:11.34 | [TK]D-Fender | No. |
13:11.39 | [TK]D-Fender | And Googling is worthless. |
13:12.01 | [TK]D-Fender | the list is right there on the WIKI as well as "core show applications" |
13:12.26 | MacroMan | Yes, but I didn't find anything, which is why I went searching |
13:12.37 | [TK]D-Fender | There is a CLI command for chan_sip however |
13:12.42 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
13:12.51 | [TK]D-Fender | If you don't see it in the applications list... then ther isn't an application |
13:13.02 | [TK]D-Fender | So stop trying to find one. |
13:13.08 | [TK]D-Fender | And move on tto other interfaces |
13:13.13 | [TK]D-Fender | CLI <----- |
13:13.16 | MacroMan | Just thought there might have been a more indirect way of achieving it. |
13:13.25 | [TK]D-Fender | CLI <----- |
13:13.26 | [TK]D-Fender | ^^^ |
13:13.31 | MacroMan | The CLI isn't great for what I want |
13:13.46 | [TK]D-Fender | MacroMan> Is there a dialplan application to unregister another peer? <- Does the job |
13:13.52 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-cfcoycgmzacwnooj) |
13:13.53 | *** mode/#asterisk [+o newtonr] by ChanServ |
13:14.31 | [TK]D-Fender | IAX2 can do this as well |
13:14.41 | [TK]D-Fender | Are you referring to one of those devices? |
13:15.32 | MacroMan | No. I have several SIP clients. I wanted to setup a dialplan that would unregister everyone |
13:16.13 | MacroMan | I'm just having a read about agi to see if that can help me |
13:16.55 | [TK]D-Fender | CLI <---- |
13:16.58 | [TK]D-Fender | no need for AMI |
13:17.04 | [TK]D-Fender | and AGI isn't magic |
13:17.19 | MacroMan | My users don't have access to the CLI, nor do I want to give them access |
13:17.21 | [TK]D-Fender | AGI has no more commands than standard dialplan really. |
13:17.37 | [TK]D-Fender | YOU CAN CALL CLI COMMANDS FROM WITHIN THE DIALPLAN. |
13:17.39 | [TK]D-Fender | THINK a little |
13:18.16 | MacroMan | OK. I was searching around for that, but I didn't find anything on how to acheive that. Is there an application for that? |
13:18.26 | Samot | No. |
13:18.35 | [TK]D-Fender | "core show application system" <---------------- |
13:18.52 | Samot | Why do you want to reregister phones when a call happens? |
13:19.02 | Samot | er deregister phones.. |
13:19.25 | MacroMan | I want the last person out of the office to be able to boot all the phones off so they're not in a queue anymore |
13:19.40 | MacroMan | I have users that perpetually forget to logout |
13:20.10 | Samot | So why don't you issue something that would log out users only logged into the queue? |
13:20.24 | Samot | Why would you want to force every phone to reboot if only 3 need to log out? |
13:20.35 | MacroMan | Every peer is in the queue |
13:20.41 | MacroMan | I don't have peers that aren't |
13:21.01 | Samot | So then every user perpetually forgets to log out? |
13:21.02 | [TK]D-Fender | What is going to stop your phones from re-registering? |
13:21.11 | Samot | ^^^^ |
13:21.13 | MacroMan | There computers aren't switched on |
13:21.19 | MacroMan | Their* |
13:21.19 | Samot | .... |
13:21.29 | Samot | How does that make a difference? |
13:21.33 | [TK]D-Fender | Then they should time out a qualify all by themselves and be considered "offline" |
13:21.38 | [TK]D-Fender | So where's the need for this? |
13:21.41 | Samot | ^^^ |
13:21.46 | MacroMan | Asterisk doesn't think so |
13:21.56 | Samot | Are they using softphones? |
13:22.02 | [TK]D-Fender | It would if you were executing a qualify against them |
13:22.02 | MacroMan | They seem to stay logged in for at least 12 hours |
13:22.23 | Samot | Are they using softphones? |
13:22.26 | MacroMan | Samot, Yes, more specifically WebRTC softphones |
13:22.54 | Samot | OK, so if they are being qualified properly Like TK said they will die off if the PC is closed. |
13:22.59 | Samot | OR the browser is closed. |
13:23.39 | MacroMan | Doesn't seem they are. They are still in my queue |
13:23.59 | Samot | Do you have the peers qualifying? |
13:24.00 | [TK]D-Fender | "still in my queue" is NOT "unregister" |
13:24.05 | [TK]D-Fender | You are talking apples & oranges |
13:24.28 | [TK]D-Fender | Queue's have MEMBERS and that has NOTHING to do with "device registration" |
13:24.43 | Samot | Your cell phone can be a queue memeber |
13:24.48 | MacroMan | But they get removed from the queue when they unregister |
13:25.00 | [TK]D-Fender | no. |
13:25.02 | MacroMan | yes |
13:25.04 | MacroMan | They do |
13:25.07 | Samot | So every user doesn't log out? |
13:25.07 | [TK]D-Fender | Queue's do not remove members |
13:25.14 | [TK]D-Fender | they may count them as UNDIALABLE |
13:25.19 | [TK]D-Fender | but it does NOT remove them |
13:25.21 | Samot | But Asterisk will not dial them. |
13:25.30 | [TK]D-Fender | Your description is getting worse as you go |
13:25.50 | Samot | Are these static members? |
13:25.55 | Samot | Or dynamic? |
13:26.00 | [TK]D-Fender | Members are either fixed in the config file or added and removed only by their express applications / system calls |
13:26.06 | [TK]D-Fender | NOT by device state |
13:26.08 | MacroMan | OK, yes, they show as 'Unavailable' in 'show queue' when not registered |
13:26.18 | MacroMan | dynamic |
13:26.40 | [TK]D-Fender | Either way I just told you what you can do... even though I don't see proof that they are in the state you described |
13:26.48 | MacroMan | Well, I added them to the queue using 'queue add member ***' on the clu |
13:26.51 | MacroMan | cli* |
13:26.54 | [TK]D-Fender | show one |
13:26.55 | [TK]D-Fender | no |
13:26.57 | [TK]D-Fender | now* |
13:27.21 | MacroMan | Oh yes, it says dynamic in the status: SIP/26 (ringinuse disabled) (dynamic) (Unavailable) has taken no calls yet |
13:27.41 | [TK]D-Fender | stil in the queue |
13:27.44 | MacroMan | And this if they are registered: SIP/13 (ringinuse disabled) (dynamic) (Not in use) has taken no calls yet |
13:27.47 | [TK]D-Fender | just not DIALABLE |
13:28.12 | [TK]D-Fender | Again... show me you shutting a machine down and the peer staying "active" |
13:28.46 | [TK]D-Fender | If you are running qualify against it it will die off withing a slim margin from the qualifyfreq |
13:28.50 | MacroMan | How exactely can I show you? Nothing shows on the CLI |
13:29.06 | [TK]D-Fender | "sip show peer X" <- |
13:29.16 | [TK]D-Fender | anfter having a PC open ... and then shutting it down |
13:30.17 | MacroMan | OK hang on |
13:30.27 | [TK]D-Fender | Withing a minute or two it should go off. |
13:31.54 | MacroMan | The output's are identical before and after shutting down: https://paste.ngx.cc/8d51914557c9cff0 |
13:32.03 | MacroMan | After shutdown: https://paste.ngx.cc/4d5ee6d9b2e2501f |
13:32.46 | [TK]D-Fender | Status : Unmonitored |
13:32.47 | [TK]D-Fender | ^^^^ |
13:32.48 | [TK]D-Fender | FAIL |
13:32.57 | [TK]D-Fender | you aren't even checking on your device being around |
13:33.06 | [TK]D-Fender | qualify=YES <--------------- |
13:34.56 | MacroMan | You don't have to be so condescending when helping me. We not all masters of asterisk terminology and it's in and out's. |
13:35.00 | *** join/#asterisk skrusty (~skrusty@88.150.145.104) |
13:35.00 | *** mode/#asterisk [+o skrusty] by ChanServ |
13:35.46 | [TK]D-Fender | Goota know your keep alives |
13:36.11 | [TK]D-Fender | This is normally required to keep UDP clients active behind NAT, etc |
13:36.32 | [TK]D-Fender | The status under "sip show peers" is a tip off as tto their status. |
13:36.40 | [TK]D-Fender | And "unmonitored" can't be good |
13:36.51 | MacroMan | So I assume that I need to add 'qualify=yes' to my sip.conf? |
13:37.02 | MacroMan | In the peers |
13:37.08 | [TK]D-Fender | unmonitored would clearly say that you're not checking if they're gone |
13:37.11 | [TK]D-Fender | yes |
13:37.20 | *** join/#asterisk bof23 (~Thunderbi@185.13.183.107) |
13:37.20 | [TK]D-Fender | Try it again |
13:37.54 | MacroMan | Thank you. I wasn't aware of the 'sip show peer x' usage and so I'd never seen this output before. |
13:40.36 | [TK]D-Fender | the full listing also shows the status |
13:41.47 | MacroMan | That seems to have done the trick. Thank you |
13:45.04 | [TK]D-Fender | So you see it listing the timeout and then dropping to "UNREACHABLE"? |
13:52.47 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
13:54.37 | *** join/#asterisk putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
13:54.37 | *** mode/#asterisk [+o putnopvut] by ChanServ |
13:58.21 | *** join/#asterisk chendy (~alexc@183.14.134.229) |
14:05.15 | MacroMan | Yes |
14:05.44 | MacroMan | And now it's shows 'Status: OK (14ms)' for online peers. |
14:06.33 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
14:10.02 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
14:10.31 | [TK]D-Fender | There you go |
14:10.32 | Samot | Because the phone re-registered. |
14:19.05 | *** join/#asterisk kharwell (kharwell@nat/digium/x-bzoiwysgzlscwcsf) |
14:19.05 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:24.10 | *** join/#asterisk monsterco (~monsterco@toroon474aw-lp130-05-174-93-88-152.dsl.bell.ca) |
14:45.34 | *** join/#asterisk Y04NN_ (~y04nn@55.204.154.77.rev.sfr.net) |
14:55.40 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
14:57.16 | *** join/#asterisk Oatmeal (~Suzeanne@c-68-45-50-54.hsd1.nj.comcast.net) |
15:00.16 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
15:17.04 | *** join/#asterisk jabular (~jabular@unaffiliated/jabular) |
15:17.26 | *** part/#asterisk jabular (~jabular@unaffiliated/jabular) |
15:18.18 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-ziifbkgvnuyyenfw) |
15:18.18 | *** mode/#asterisk [+o rmudgett] by ChanServ |
15:18.23 | *** join/#asterisk dexta (~D3XTA@host86-181-18-235.range86-181.btcentralplus.com) |
15:19.16 | *** join/#asterisk monsterco (~monsterco@CPE000db93cb535-CM1cabc0735ed0.cpe.net.cable.rogers.com) |
15:24.53 | *** join/#asterisk puzzled (~puzzled@2001:982:1097:1::1:3) |
15:44.27 | *** join/#asterisk averythomas (~averythom@2604:6000:1523:401f:222:19ff:fe2b:48fa) |
15:48.37 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
15:48.37 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
15:56.19 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
15:59.31 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
16:12.13 | *** join/#asterisk miralin (~Thunderbi@194.8.128.118) |
16:19.09 | jfindley | any idea why during a conversation recorded with MONITOR both parties can hear each other, both output files grow normally, but the caller's channel is silent in the recording? |
16:19.46 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
16:28.39 | igcewieling | jfindley: what codecs are you using? |
16:29.01 | jfindley | g711 |
16:29.14 | igcewieling | while on a call "sip show channels" will confirm the codec |
16:29.34 | igcewieling | if that isn't the issue, you might want to ask on the mailing list. |
16:30.20 | igcewieling | make sure you have directmedia=no as well |
16:31.50 | jfindley | yeah, it's an intermittent issue. Happens to about 2% of the calls that go through, but I already verified the codecs are OK. What I see is, asterisk continually writes to both the -in and -out files, but sometimes the -in file is e.g. 10 megs of silence |
16:32.16 | jfindley | but the RTP stream looks normal and both parties can hear each other fine |
16:32.30 | igcewieling | I've never seen that issue. |
16:33.04 | igcewieling | All issues I've seen with recordings end up being a FreePBX issue, not an Asterisk one. |
16:36.13 | Samot | How is it a FreePBX issue? |
16:37.11 | jfindley | I'm not using FreePBX, just Asterisk 13 and fastAGI |
16:37.39 | Samot | I understand that. I'm just wondering why a GUI was blamed for recording issues in Asterisk. |
16:39.02 | Samot | What release of 13? |
16:39.26 | jfindley | Asterisk certified/13.1-cert4 |
16:39.51 | Samot | Well that is a bit out of date. |
16:40.17 | jfindley | Yeah a bit, I'm gonna try it on 14 here in a bit. |
16:40.31 | Samot | Would have to look to see if any bugs might have been reported for this issue in that release. |
16:40.59 | jfindley | I looked but didn't see anything =/ |
16:53.22 | igcewieling | Samot: FreePBX was not recording some calls. |
16:53.29 | igcewieling | Upgrade and the problem went away. |
16:53.38 | drmessano | He's not using FreePBX |
16:53.40 | igcewieling | Draw your own conclusion. |
16:53.47 | Samot | I know he's not. |
16:53.55 | igcewieling | drmessano: I'm replying to Samot, not jfindley |
16:54.18 | drmessano | Ok, but he's not using FreePBX |
16:54.35 | Samot | Asterisk still is what was recording the calls. |
16:54.40 | drmessano | Yep |
16:54.48 | Samot | Not FreePBX. |
16:54.48 | drmessano | FreePBX doesnt record calls anyway |
16:54.50 | drmessano | Asterisk does |
16:55.06 | igcewieling | Yes, I saw that. Otherwise I might have replied to jfindley instead. |
16:55.18 | drmessano | Maybe he should stop using Gentoo, even though he's not |
16:56.38 | Samot | jfindley: Have you tried MixMonitor? Just as a testing point? |
16:56.45 | igcewieling | Gentoo sucks! But he's not using Gentoo. Gentoo still sucks! |
16:57.03 | drmessano | jfindley: You dont need to jump to 14.. Just curious why youre using Cert? |
16:57.10 | drmessano | Its really not necessary |
16:57.11 | jfindley | I used to use mixmonitor but because people want a variety of different recording options monitor was my preferred choice |
16:57.19 | Samot | I get that |
16:57.29 | drmessano | Just upgrade to a later, standard 13 release |
16:57.36 | Samot | I'm just wondering if the MixMonitor audio recording will have dead air for the one side of the call. |
16:58.12 | Samot | Does the channel that ends up being dead air in the Monitor recording end up being dead air in the MixMonitor recording? |
16:59.03 | jfindley | Samot: Dunno, I can't really test that yet since my audio processing stuff depends on -in and -out files = |
16:59.13 | Samot | OK. |
16:59.32 | Samot | So the raw recording file before the audio processing touches it is dead air? |
16:59.40 | jfindley | yes |
17:01.11 | jfindley | I went so far as to log the volume levels of the audio at every step in the processing chain. As soon as asterisk closes the -in file the average volume is 0 sometimes |
17:02.45 | drmessano | I would definitely upgrade and retest |
17:03.04 | Samot | Yup. |
17:03.17 | Samot | I think 13.1 had some issues... |
17:03.37 | Samot | Or was that 13.2? |
17:04.17 | drmessano | I would also just use a standard release |
17:04.36 | drmessano | Unless you have support, you don't need it |
17:07.25 | Samot | I'm only holding back on going to 13.14 on one machine. |
17:07.36 | Samot | Because it's calling Mockingbird |
17:07.43 | Samot | And 13.13 seems right for it |
17:08.48 | Samot | I count on two people to get that |
17:10.57 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
17:17.10 | *** join/#asterisk Chotaire (chotaire@91.134.152.20) |
17:17.15 | *** join/#asterisk dakudos (~dakudos@73.243.248.133) |
17:22.51 | jfindley | was I one of those two? |
17:26.20 | drmessano | 1313 Mockingbird lane |
17:26.41 | jfindley | Also, upgrading to 14 was pretty painless. I'm loading up the server now, so far no issues |
17:27.02 | drmessano | Im sure it was |
17:27.57 | drmessano | If youre fine running 14 why were you using a Certified 13 ? |
17:28.18 | drmessano | You kinda just jumped from one end to the other |
17:30.45 | jfindley | Didn't have any compelling reason to upgrade til this bug popped up |
17:39.37 | igcewieling | jfindley: could the problem calls be calls which were transferred? |
17:42.39 | jfindley | Pretty unlikely, these * servers sit in between SIP/PSTN gateways so xfers shouldn't have any impact |
17:44.33 | *** join/#asterisk voodster (~je@188.234.207.225) |
17:47.28 | voodster | for you how more grammatically correct and unambiguous to determine an outbound call, as outgoing call or outcoming call? Need for docs, thanks |
17:48.03 | jfindley | outgoing/outbound |
17:49.19 | voodster | jfindley: thank you! |
18:00.58 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
18:09.02 | *** join/#asterisk lankanmon (~LKNnet@2607:fea8:d1f:fc17:11e0:707c:2961:d41e) |
18:20.24 | *** join/#asterisk Y04NN (~y04nn@55.204.154.77.rev.sfr.net) |
18:21.43 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-scdaxpxncarnhmxl) |
18:21.43 | *** mode/#asterisk [+o newtonr] by ChanServ |
18:22.58 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
18:26.01 | *** join/#asterisk LunaLovegood (~alice@75.98.139.193) |
18:36.33 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
18:37.50 | LunaLovegood | Is there a dialplan variable or a Dial() option I can use to set ";phone-context=+1" on outgoing SIP INVITEs ? |
18:38.33 | LunaLovegood | usereqphone=yes in sip.conf causes ";user=phone" to be added, but does nothing for phone-context. |
18:39.58 | LunaLovegood | Normal e164 numbers work, but I need ";phone-context=+1" for dialing 911 and other short numbers. |
19:04.04 | igcewieling | not that I know of. never heard of it being required. You are not in the USA or Canada, correct? |
19:06.10 | igcewieling | BTW, they are sometimes called N11 to avoid confusion with SMS shortcodes. |
19:17.33 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
19:25.25 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
20:01.36 | Samot | They want 911 calls in tel URI format? |
20:28.47 | *** join/#asterisk malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
20:28.47 | *** mode/#asterisk [+o malcolmd] by ChanServ |
20:32.43 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
20:40.36 | LunaLovegood | Yes I'm in Canada |
20:44.13 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
20:47.45 | Samot | That has nothing to do with it. |
20:48.54 | Samot | The tel URI is just that, a URI. |
20:49.07 | Samot | This is a format your provider is requesting your calls in. |
20:51.11 | Samot | It's also something that is tagged as part of an existing URI |
20:52.58 | Samot | Appended/prepending existing URIs in a SIP header is not something I think Asterisk can do easily or if at all. |
20:53.21 | Samot | Outside of what is currently done with sip.conf settings. |
20:59.52 | *** join/#asterisk Y04NN (~y04nn@77.154.204.55) |
21:00.19 | imcdona | Not having any luck getting Asterisk to bind on a specific IPv6 and specific IPv4 address. Is that even possible? muiltiple bindaddr doesn't appear to work |
21:00.58 | *** join/#asterisk Y04NN (~y04nn@55.204.154.77.rev.sfr.net) |
21:02.52 | igcewieling | IIRC you can bind to no IPs, one IP or to all IPs, but not to some. Needing to do so is often a sign if a bad design. 8-| |
21:07.04 | *** join/#asterisk monsterco (~monsterco@192.190.0.152) |
21:07.10 | imcdona | yeah well...when you're running OSPF and have an IP bound to a loopback address and also want to support IPv6 it becomes troublesome. Personally I'd rather be using LACP but I'm stuck with OSPF for redundancy |
21:10.24 | Samot | Chan_SIP can list on a specific or 0:0:0:0 wildcard IPv4 address or you can listen on a specific IPv6 IP |
21:10.38 | Samot | Or you can listen on a IPv4/IPv6 wildcard of :: |
21:11.07 | Samot | er 0.0.0.0 |
21:14.09 | Samot | ^^ as the IPv4 only wildcard.. |
21:14.20 | Samot | I noticed I typed 0:0:0:0 originally. |
21:18.13 | igcewieling | You are running OSPF on your Asterisk box? |
21:18.55 | igcewieling | imcdona: if you bind to all IPs, the source IP of the packet will be determined by the OS routing table. |
21:20.09 | imcdona | The Asterisk box is running quagga. The host has three IPv4 addresses, two for the OSPF links, and then one for the loopback address which is where Asterisk binds to. That has been working great. The issue is, chan_sip doesn't support binding to a specific IPv4 address and either all IPv6 addresses or a sinlge IPv6 address in addition to the V4 address |
21:20.43 | igcewieling | I consider running a routing daemon on an Asterisk box to be "a bad design" 8-| |
21:20.59 | imcdona | igcewieling: Exactly, which is why I bind to the loopback address. Other wise devices would be getting SIP replies from the interface IP's instead of the loopback address |
21:21.35 | igcewieling | imcdona: I know of no way to accomplish what you want. |
21:21.44 | imcdona | igcewieling: I couldn't aggree more. I inherited this setup unforunatly |
21:22.06 | igcewieling | move one of them to a different box. |
21:42.58 | *** join/#asterisk Nugget (~nugget@104.225.12.200) |
21:47.26 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
21:47.26 | *** mode/#asterisk [+o cresl1n] by ChanServ |
21:49.53 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
22:06.42 | *** join/#asterisk jeffspeff (~jeff@12.49.160.131) |
22:41.16 | *** join/#asterisk Ron9 (~rp@91.133.32.133) |
23:02.15 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
23:24.54 | *** part/#asterisk kharwell (kharwell@nat/digium/x-bzoiwysgzlscwcsf) |
23:47.58 | *** join/#asterisk Primer (~daniel@ceregatti.org) |
23:49.52 | Primer | Hello. I've brought up this issue before, but I wasn't able to resolve it the last time I was here. I upgrade asterisk on my Linux Mint 18 machine recently (it was a dist-upgrade. Not sure what version I came from, but I'm on 13.1.0 now). Since then making outbound calls results in: Retransmission timeout reached on transmission 5777b3d94c13ae8542faeca44674e6d5@my.external.ip.address:5060 |
23:50.14 | Primer | I'm using vitelity for DID |
23:51.27 | Primer | I have a feeling the issue is NAT. I can run Zoiper on my phone behind the same NAT, configured with the same vitelity account, and it works fine. |