00:02.35 | *** join/#asterisk Amnesia (~Amnesia@unaffiliated/amnesia) |
00:09.55 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
00:14.30 | *** join/#asterisk talntid (~talntid@unaffiliated/talntid) |
00:19.31 | *** join/#asterisk dar123 (~dar@107-203-254-117.lightspeed.sntcca.sbcglobal.net) |
00:32.39 | *** join/#asterisk u0m3 (~u0m3@188.25.124.179) |
00:54.09 | *** join/#asterisk DaRock (~Thunderbi@150.101.178.33) |
01:19.57 | *** join/#asterisk infobot (ibot@rikers.org) |
01:19.57 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.19.1 (2018/02/13), Standard: 15.2.1 (2018/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 |
01:32.41 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b01c:a980:91c2:a7f9:7bff:638e) |
01:34.16 | *** join/#asterisk AndChat-620489 (~AndChat62@2600:100e:b01c:a980:860:1ef8:dcdf:17ea) |
02:10.22 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
02:15.51 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
02:52.17 | madduck | does anyone have any recommendations for how to set up the new CT target-based netfilter helpers to handle not only RTP 10000â20000, but also the rest of RTCP and RTSP? |
02:52.35 | madduck | or are we basically just talking about 1024â65535? |
02:56.58 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b01c:a980:a1a5:16a9:5c47:64e0) |
02:58.30 | *** join/#asterisk AndChat-620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
03:11.00 | *** join/#asterisk Oooohboy (~Oooohboy@2605:6000:1711:c1ff:407d:634d:a14b:242e) |
03:16.02 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:16.15 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
03:16.54 | *** join/#asterisk UncleKiwi (~UncleKiwi@unaffiliated/unclekiwi) |
03:19.09 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:31.09 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:31.20 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:db8:27d:cf29:631d) |
03:33.18 | *** join/#asterisk Oooohboy (~Oooohboy@2605:6000:1711:c1ff:5de1:182:e755:ba7a) |
03:33.58 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:35.43 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
03:35.58 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:38.08 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:38.57 | *** join/#asterisk Oooohboy (~Oooohboy@2605:6000:1711:c1ff:5de1:182:e755:ba7a) |
03:40.05 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
03:44.27 | *** join/#asterisk Oooohboy (~Oooohboy@2605:6000:1711:c1ff:5de1:182:e755:ba7a) |
04:11.33 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:7859:6158:ff3f:636e) |
04:16.58 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
04:29.49 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:ad38:bed7:7a1f:7c59) |
04:35.56 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
04:43.12 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:11de:9d9e:9593:7479) |
04:44.19 | *** join/#asterisk K0HAX (~michael@28.139.154.104.bc.googleusercontent.com) |
04:45.29 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
04:59.58 | *** join/#asterisk NonSecwitter (~NonSecwit@unaffiliated/nonsecwitter) |
05:23.51 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
05:25.55 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:cd3b:5d1b:6592:d735) |
05:28.27 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
06:25.34 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b01c:a980:7cbf:eb28:47ec:a37d) |
06:26.29 | *** join/#asterisk AndChat-620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
06:38.56 | *** join/#asterisk ashutoshkrchaube (673399be@gateway/web/freenode/ip.103.51.153.190) |
06:39.57 | ashutoshkrchaube | Hi what is the maximum size in mb of voicemail that asterisk can play? |
06:41.44 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b01c:a980:bc98:f85c:4cd0:834e) |
06:42.14 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
06:42.35 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
07:19.37 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
07:26.06 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
07:27.06 | *** join/#asterisk nix8n82 (~AndChat62@67.130.74.235) |
07:35.59 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
07:54.49 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
08:12.11 | *** join/#asterisk Oooohboy (~Oooohboy@72-48-251-4.dyn.grandenetworks.net) |
08:21.21 | *** join/#asterisk Oooohboy (~Oooohboy@72-48-251-4.dyn.grandenetworks.net) |
08:23.16 | *** join/#asterisk Oooohboy (~Oooohboy@72-48-251-4.dyn.grandenetworks.net) |
08:32.25 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
08:34.35 | *** join/#asterisk visip (~visix@gateway/tor-sasl/visip) |
08:51.04 | *** join/#asterisk liviuc (~liviuc@109.99.227.30) |
08:57.02 | *** join/#asterisk DanB (~DanB@clt-195.192.204.39.ip-anschluss.net) |
09:06.26 | *** part/#asterisk Amnesia (~Amnesia@unaffiliated/amnesia) |
09:09.45 | DonkeyDong | Hi, i have a silly question. Is pjsip the new norm or are people in reality still using chan_sip? |
09:34.39 | DanQuinney | DonkeyDong: no such thing as a silly question, you'll find ITSP's using both chan_sip and pjsip, we use pjsip and it has bitten us a couple of times - but in the grand scheme of things we prefer it. You'll find others really dislike pjsip mainly as it's not as tested in the wild as chan_sip is. |
09:44.34 | DonkeyDong | Right, thanks :-) |
10:00.14 | Samot | The only ITSPs that have chan_sip and chan_pjsip have Asterisk. Those are not things in most other sip software. |
10:03.05 | *** join/#asterisk [sr] (~kvirc@pal-213-228-163-73.netvisao.pt) |
10:03.07 | [sr] | howdy |
10:05.57 | [sr] | when i have external call's comming in, whethear they came from an ip trunk, or an ISDN trunk |
10:06.17 | [sr] | the field "dcontext" in cdr, is always "ext-group" ? |
10:09.51 | [sr] | from what i've analized yes, just want to confirm at 101% ;) |
10:13.00 | Samot | So this is FreePBX? |
10:19.22 | [sr] | no, cdr! |
10:19.24 | [sr] | asterisk!! |
10:20.02 | [sr] | ok the context's names may be hammered by freepbx |
10:29.43 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
10:30.26 | Samot | Well do these calls go to ring groups? |
10:30.46 | Samot | Because ext-group is where all the Ring Group dialplan is held in FreePBX. |
10:58.22 | *** join/#asterisk bounceman (~bounceman@185.32.9.250) |
10:58.31 | [sr] | oh ok, going to similate a call to an extension to see whats recordes there |
10:59.55 | bounceman | Hello, I have a very interesting issue. Have a look at this CLI trace http://codepad.org/8lYfFYzG What happens is that after an attended transfer is completed (10:12:05) Music on Hold starts on the transferee target. The channels was swapped at line 23 and Moh starts at line 25 |
11:00.19 | bounceman | I've seen people with similar issues on the asterisk jira, but no one really seems to have solved it. |
11:00.49 | [sr] | Samot: "from-did-direct", |
11:01.04 | Samot | This is 100% FreePBX dialplan. |
11:01.06 | bounceman | Also at line 27 & 28 MoH is stopped and started for the incoming part (A) |
11:01.21 | Samot | [sr]: What's the issue? |
11:03.02 | Samot | [2018-02-15 10:11:24] VERBOSE[7902][C-00013ed2] res_musiconhold.c: Started music on hold, class 'default', on channel 'SIP/foobar_sip_trunk-00022a25' |
11:03.25 | Samot | [2018-02-15 10:11:39] VERBOSE[8624][C-00013ed9] pbx_realtime.c: Executing [1023@from-sip:2] Dial("SIP/fredrik.bergqvist-00022a37", "SIP/margareta.brun,,tTxX") |
11:03.46 | bounceman | Samot: yes, the A part was holded, that is why the MoH started at 10:11:24. Then B dialed C(Margareta) |
11:04.22 | bounceman | But why would MoH starts after the attended transfer was performed? |
11:04.52 | Samot | A called in. |
11:04.54 | Samot | B Answered. |
11:04.57 | Samot | B puts A on hold. |
11:05.00 | Samot | B calls C |
11:05.03 | Samot | B puts C on hold |
11:05.09 | Samot | B transfer A to C |
11:05.17 | Samot | B hangs up A, stops that music on hold |
11:05.26 | bounceman | No, C is never put on hold. The attended transfer was performed while B and C was talking |
11:05.27 | [sr] | Samot: none, i'll similate call's to see whats recorded there ;) i have my own frontend for cdr |
11:05.29 | Samot | B hangs up with, stops that music on hold. |
11:05.58 | Samot | [sr]: Every context you have mentioned for far is a FreePBX generated context. |
11:06.06 | Samot | For years the same contexts. |
11:06.14 | bounceman | [2018-02-15 10:11:42] VERBOSE[8624][C-00013ed9] app_dial.c: SIP/margareta.brun-00022a38 answered SIP/fredrik.bergqvist-00022a37 |
11:06.20 | bounceman | This is the part were C answers B |
11:06.27 | Samot | So you either wrote you dialplan and just happened to use all the same context names, or this is a hack of FreePBX code. |
11:06.30 | bounceman | There is no hold between that time and where the transfer take part |
11:06.56 | Samot | 2018-02-15 10:12:05] VERBOSE[8627][C-00013ed9] res_musiconhold.c: Started music on hold, class 'default', on channel 'SIP/margareta.brun-00022a38' |
11:07.08 | Samot | MoH was triggered on C's channel. |
11:07.12 | Samot | Someone put C on hold. |
11:07.30 | Samot | How was the transfer made? |
11:07.48 | Samot | What method did B use to transfer the call? |
11:08.00 | bounceman | Samot: Someone put C on hold |
11:08.06 | bounceman | yes, someone or something |
11:08.07 | Samot | What method did B use to transfer the call? |
11:08.26 | Samot | Did they put A on hold and called C |
11:08.33 | bounceman | By method you mean attended transfer or featurecode? |
11:08.50 | Samot | Attended Transfer is a thing that can be done via feature code or not |
11:08.53 | Samot | Don't confuse it. |
11:09.06 | Samot | This is an Attended Transfer despite how it was initiated. |
11:09.18 | Samot | So did they press the "Transfer" key on the phone, did they use Feature Codes? |
11:09.22 | bounceman | I will post the scenario here below |
11:09.26 | Samot | Did they put A on hold then call C |
11:09.44 | Samot | _How_ it was transferred will shed some light |
11:10.27 | bounceman | A calls B |
11:10.28 | bounceman | B answers A |
11:10.28 | bounceman | B holds A |
11:10.29 | bounceman | B calls C |
11:10.31 | bounceman | C answers B |
11:10.33 | bounceman | B use attended transfer to connect A with C |
11:10.35 | bounceman | Music on Hold starts |
11:11.20 | bounceman | I spoke to other peers and they say it looks like an asterisk bug, I am just double checking if anyone here has any idea |
11:11.28 | bounceman | We're running 13.16.0 by the way |
11:17.49 | Samot | Wait. |
11:17.57 | Samot | What do you mean "uses attended transfer" |
11:18.02 | Samot | How do they actually transfer.... |
11:18.27 | Samot | Attended Transfer is the process of holding one call and staying on the line until the other party is connected. |
11:18.36 | Samot | YOU make sure the second party is available and control the call |
11:18.52 | Samot | Vs a BLIND transfer which just sends the call without you being involved |
11:19.04 | Samot | Again, HOW is it being done? |
11:19.09 | Samot | Are they using a Feature Code? |
11:19.20 | Samot | Are they using the Transfer key on the phone? |
11:19.31 | bounceman | Yeah, so when C answers B and B can verify that C is available, there is a button in the softphone that handles that. I have not built the softphone myself so I cannot tell you how the code works in the backend, but I've requested that info and hope to receive it soon. |
11:20.02 | Samot | OK |
11:20.06 | Samot | So in general... |
11:20.26 | Samot | The "Transfer" buttons on phones will send a REFER to the system. |
11:20.38 | bounceman | Yes, that is what it does. |
11:20.42 | Samot | The moment they hit the button, it puts the caller on hold. |
11:20.43 | bounceman | And we get the Accepted and all that |
11:20.53 | Samot | And opens a new channel to dial. |
11:21.04 | Samot | You dial that new destination, they either answer or don't. |
11:21.25 | Samot | Until the "Transfer" button is hit again, the original call is on hold. |
11:21.51 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
11:22.30 | bounceman | Ok, even if this were the case. Why would asterisk start MoH after C has been put into the bridge? |
11:27.24 | bounceman | You have to agree that does not make any sense, even if the scenario was as you described |
11:33.13 | Samot | And what do the parties hear? |
11:33.19 | Samot | What is the experience for them? |
11:33.33 | Samot | Does C hear MoH after B hangs up? |
11:33.37 | bounceman | C hears MoH |
11:33.57 | bounceman | A hears MoH the entire time, until one of them eventually hangs up |
11:34.15 | Samot | Then something isn't right. |
11:34.19 | Samot | In how this is being done. |
11:34.25 | Samot | How often does this happen? |
11:34.27 | file | you need to provide the SIP traffic. |
11:34.37 | Samot | Yeah a full sip debug would help |
11:34.41 | Samot | That was going to be next |
11:34.48 | Samot | How often does this happen? |
11:34.49 | bounceman | It depends, our customer that does 100 transfer each time can experience 5-30% failure per day. |
11:34.52 | bounceman | It is extremely random |
11:35.06 | Samot | So it's the same person doing it? |
11:35.41 | Samot | Or is this an office and multiple users are having the issue? |
11:35.49 | bounceman | No, there are 20 agents, who all experience this. Both on internal and external transfers |
11:36.12 | Samot | All using the same softphone? |
11:37.15 | bounceman | Yes |
11:37.28 | bounceman | We have experience this is other environents as well with the same setup |
11:37.54 | Samot | Other PBX systems? |
11:38.01 | bounceman | No, asterisk 11 and 13 |
11:38.09 | Samot | What softphone? |
11:38.25 | bounceman | From Xenialab |
11:39.20 | Samot | Has this been experienced on anyone using something that is not this softphone? |
11:39.31 | bounceman | Ok, so lets imagine that the softphone is to blame. That means that the Softphone will tell Asterisk to start moh? How is this done? Via AMI Events or can it be done in another way? |
11:39.41 | file | SIP signaling. |
11:39.51 | Samot | We need to see an actual SIP Debug |
11:39.56 | bounceman | file: how does a hold look like in SIP? |
11:39.56 | Samot | Full SIP messages. |
11:40.24 | file | it's a reinvite with either sendonly or recvonly (I always get them reversed) or a connection address of 0.0.0.0 |
11:41.32 | bounceman | I have a pcap between the asterisk and the agent performing the transfer |
11:42.03 | bounceman | https://uploadfiles.io/gr0g8 |
11:42.47 | bounceman | So based on what file said the Hold was initiated at 65 seconds, and the attended transfer at 106 seconds. |
11:45.39 | Samot | PCAPs are before Asterisk touches/processes the call. |
11:48.04 | bounceman | Yeah hang on |
11:50.31 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
11:51.11 | bounceman | https://uploadfiles.io/u5c2w so the asterisk is 35.157.118.140 in this pcap |
11:51.44 | bounceman | Pretty basic pcap really, since it is an internal transfer. |
11:51.46 | bounceman | Not much fun going on |
11:51.58 | Samot | No. |
11:52.04 | Samot | I mean, a Asterisk SIP Debug |
11:52.22 | Samot | Where it shows how Asterisk sees, processes when in Asterisk |
11:52.25 | bounceman | Thought you said before asterisk touches the call |
11:52.56 | Samot | I was pointing out that a PCAP is before Asterisk processes the call |
11:53.12 | Samot | That's at the system level.. |
11:53.28 | Samot | An Asterisk SIP Debug will show how Asterisk is processing the SIP message. |
11:53.31 | bounceman | Ok, I do not have that sip debug I am afraid. |
11:54.11 | file | it also shows it in relation to what Asterisk is doing, when things occur |
11:59.50 | Samot | And this PCAP is one sided. |
12:10.17 | bounceman | Any ideas how I can step up my game in regards to the debug data provided. I want to know WHY asterisk starts MoH and who told it to do so. |
12:10.27 | file | I looked, there's already an issue open |
12:11.43 | bounceman | Yeah I submitted one, it was closed and moved to duplicate https://issues.asterisk.org/jira/browse/ASTERISK-27071 |
12:14.52 | Samot | Have you tried the latest version? |
12:15.20 | Samot | Outside of the fact there were security flaws found in 13.17 < |
12:18.01 | bounceman | I looked through the changelog, couldn't see anything that relate to this |
12:18.32 | Samot | Sure. |
12:18.46 | Samot | But that doesn't mean it wasn't fix just when something else was fixed. |
12:18.52 | file | the person posted a change which resolved it for them, but never responded to review feedback |
12:19.04 | file | it didn't use locking so it could crash randomly |
12:19.15 | Samot | I've got an office of lawyers that transfer calls all day |
12:19.20 | Samot | A lot of calls. |
12:19.23 | bounceman | file: you're talking about Jason's post? |
12:19.34 | file | yes. |
12:19.39 | file | it was put up for code review as well. |
12:20.11 | bounceman | There has not been any update since 27th of July except for the issue merge just now, which scares me. We might even put up a bounty on this bug. |
12:21.12 | Samot | Try updating. |
12:21.36 | Samot | Again, anything less than 13.17.2 or 13.18 (can't remember which) is exposed to security flaws. |
12:21.59 | Samot | It was enough for 11 to be updated 3 weeks before SFO ended. |
12:22.33 | bounceman | Samot: do you have more info to share? |
12:22.48 | Samot | I would have to go back and look at the announcement releases.. |
12:22.57 | Samot | But this was back in Sep/Oct 2017 |
12:23.06 | Samot | Since 11 died on Oct 25th 2017 |
12:23.24 | stefan27 | bounceman, can't you upgrade to latest and then manually merge in Jason's suggestion (at your own risk)? |
12:23.36 | Samot | Or even see if the merge is needed |
12:23.59 | bounceman | What would be a potential issue of that fix? |
12:24.06 | bounceman | file mentioned crashing |
12:24.21 | Samot | First. |
12:24.23 | Samot | Update |
12:24.35 | Samot | THEN see if you need to worry about a patch that doesn't using locking. |
12:25.05 | Samot | 30% of failures is a high amount. |
12:25.10 | bounceman | Yeah, I just have to check the compability |
12:25.20 | Samot | If this was still a bug in later versions, I would have had complaints. |
12:25.24 | Samot | Compability? |
12:25.29 | Samot | It's 13. |
12:25.42 | bounceman | We had 80% of failures with internal transfers last friday |
12:25.49 | Samot | OK |
12:25.51 | bounceman | somedays 0% |
12:26.06 | Samot | This is either a bug in Asterisk |
12:26.12 | Samot | An issue with the softphone |
12:26.14 | Samot | Or both |
12:26.32 | file | my initial analysis could have also been incorrect and it could still be something separate, just be aware that chan_sip is community supported - so Digium doesn't touch the issues and it's up to others |
12:26.35 | Samot | You can try a different softphone or a real IP phone to see if this issue exists... |
12:26.44 | Samot | You can update Asterisk to see if this issue persists. |
12:27.12 | Samot | But with the amount of transfers I have on this one system.... |
12:27.19 | Samot | I would have seen this issue. |
12:28.01 | bounceman | Yeah, I will try an update. That is my first step |
12:30.01 | bounceman | Anyone has experience with a bug boundy? Does it spark interest? |
12:30.09 | bounceman | bounty |
12:30.32 | Samot | Don't know. |
12:30.42 | Samot | Because that requires someone to get in and mess with the core code. |
12:30.57 | Samot | Again, you're on a 10 month release. |
12:30.59 | file | some have, some haven't, depends on what is needed and what is involved - chan_sip itself is messy and any change usually causes ripples, so that drives people away |
12:31.18 | Samot | Since that release we have gone from 13.16 to 13.19.1 |
12:31.27 | Samot | That's a lot of updates. |
12:31.47 | Samot | You're also using a sip driver that isn't actively supported by Digium. |
12:32.41 | Samot | Chan_SIP some saw nice updates in 14 but Digium didn't do them. |
12:34.10 | Samot | I'm going to guess over the next few years things are going to get wobbly for Asterisk users |
12:35.07 | Samot | Most ITSP/ISPs either 1) Benchmarked a pre-11 version of Asterisk and their configs are chan_sip only or 2) They never benchmarked, found generic how-to's for Asterisk and just shoved their details into them. |
12:35.08 | bounceman | So PJSIP? |
12:35.52 | Samot | And by and far, ITSP/ISPs don't know or care about Chan_SIP or Chan_PJSIP since they are both simply SIP. |
12:36.24 | Samot | Since 12 I've lost count of people claiming their ITSP "Doesn't support PJSIP" |
12:37.18 | Samot | PJSIP is the core driver. |
12:37.22 | Samot | SIP driver. |
12:37.30 | Samot | That is where development is focused and driven. |
12:37.46 | Samot | Any updates for Chan_SIP are community driven and supplied. |
12:40.13 | bounceman | Got you, would using WebRTC "remove" chan_sip from the equation? |
12:40.20 | bounceman | a webrtc softphone for an example |
12:42.21 | file | unless you wrote your own signaling protocol and implemented it in Asterisk then you'd end up using either chan_sip or chan_pjsip for signaling |
12:43.30 | Samot | Chan_SIP just went community support in recent history. |
12:43.43 | Samot | It was still supported when WebRTC was introduced into Asterisk. |
12:44.00 | bounceman | I dont mind using chan_pjsip |
12:44.05 | bounceman | It is chan_sip I want to flee |
12:44.28 | Samot | I would recommend a sandbox system then. |
12:44.39 | Samot | The core concepts are still the same. |
12:44.50 | Samot | Setting names have been changed to support both types. |
12:44.59 | Samot | So SIP/100 is PJSIP/100 |
12:45.23 | file | https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip |
12:45.24 | bounceman | But would it be a bad idea to try the transfer issue on pjsip instead? |
12:45.30 | Samot | Dial() for PJSIP is different than Dail() for chan_SIP as PJSIP supports more than one contact. |
12:45.37 | Samot | No. |
12:45.44 | Samot | What I'm saying is, just don't blanket move. |
12:45.54 | Samot | You'll need to stand up a box side by side. |
12:46.01 | Samot | The dialplan commands are different |
12:46.10 | bounceman | I am aware, I've done pjsip configuration in the past. Just thought if it was worth a shot |
12:46.12 | Samot | The logic/concept is still the same... |
12:46.14 | Samot | OK |
12:46.16 | Samot | It is. |
12:46.32 | Samot | You can eithe update and try chan_sip on 13.91.1 |
12:46.37 | Samot | See if the issue goes away |
12:46.44 | Samot | Since it probably might not be in a changelog |
12:47.01 | Samot | Or you can spin up a new box and test PJSIP |
12:47.13 | bounceman | Well, I will try the asterisk update first |
12:47.50 | bounceman | The softphone should be OK either way? Would a standard SIP Stack work with PJSIP? |
12:50.00 | file | SIP is SIP. |
12:51.16 | Samot | I just explained that |
12:51.52 | file | heck, the PJSIP stack is used in tons of clients already |
12:54.01 | file | Samot: I have the date on when we said chan_sip would not be core supported |
12:54.07 | file | August 8th, 2014 |
12:54.17 | Samot | Oh |
12:54.29 | Samot | Yeah, so a while |
12:54.37 | Samot | I though it was in 2015. |
13:18.26 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
13:50.30 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
13:52.43 | bounceman | Samot: you can call me an idiot but I have failed to find those security things you mentioned. Would you care to guide me a bit further? |
13:53.42 | file | http://lists.digium.com/pipermail/asterisk-announce/2017-December/date.html http://lists.digium.com/pipermail/asterisk-announce/2017-November/date.html |
13:54.28 | file | https://www.asterisk.org/downloads/security-advisories |
13:55.11 | bounceman | thank you file |
14:01.05 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
14:27.41 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
14:32.13 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
14:33.45 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
14:38.17 | *** join/#asterisk ghoti (~paul@75.98.206.5) |
14:45.52 | *** join/#asterisk NonSecwitter (~NonSecwit@unaffiliated/nonsecwitter) |
14:58.04 | *** join/#asterisk dar123 (~dar@107-203-254-117.lightspeed.sntcca.sbcglobal.net) |
14:59.17 | *** join/#asterisk kharwell (kharwell@nat/digium/x-fshymxsvkxclykkh) |
14:59.17 | *** mode/#asterisk [+o kharwell] by ChanServ |
15:17.49 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
15:22.52 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
15:22.53 | *** mode/#asterisk [+o bford] by ChanServ |
15:27.17 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
15:39.27 | *** join/#asterisk dar123 (~dar@107-203-254-117.lightspeed.sntcca.sbcglobal.net) |
15:41.43 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
15:44.01 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-ejrfueotmormcwfx) |
15:44.02 | *** mode/#asterisk [+o rmudgett] by ChanServ |
15:47.52 | *** join/#asterisk rpifan (~androirc@12.206.107.11) |
15:47.57 | rpifan | Anyone else at it expo |
15:48.01 | rpifan | Asterisk world east |
15:54.54 | *** join/#asterisk troyt (~troyt@c-73-65-211-33.hsd1.ut.comcast.net) |
15:55.19 | rpifan | Hi |
16:03.39 | *** join/#asterisk miralin (~Thunderbi@194.8.128.80) |
16:08.16 | *** join/#asterisk marlow2k (~Mario@rt-bb-d.Station-Berlin.Net) |
16:08.32 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
16:10.09 | marlow2k | Hey guys! Today I have no real idea how to debug that. My asterisk was running for years, and after a 6 hour downtime of our internet connection, in the log I get the error chan_sip.c: sip_reg_timeout: -- Registration for 'account@server' timed out, trying again |
16:10.09 | marlow2k | But I can connect via telnet to that server and get answers. It looks like the connection was running for a long time and now after a restart something changed. Any ideas? |
16:17.30 | *** join/#asterisk marlow2k (~Mario@rt-bb-d.Station-Berlin.Net) |
16:17.51 | marlow2k | Sorry was disconnected. Any ideas? |
16:17.52 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
16:18.54 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
16:19.16 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
16:19.17 | *** mode/#asterisk [+o cresl1n] by ChanServ |
16:30.05 | *** join/#asterisk jkroon (~jkroon@165.16.204.162) |
16:41.45 | *** join/#asterisk infobot (ibot@rikers.org) |
16:41.45 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.19.1 (2018/02/13), Standard: 15.2.1 (2018/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 |
16:41.59 | marlow2k | yes sip |
16:42.41 | marlow2k | sip show registry shows the state "Request Sent" |
16:43.09 | marlow2k | and i have the same for two independent sip servers |
16:44.13 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
16:46.59 | *** join/#asterisk startledmarmot (~startledm@2601:582:4301:a05c:ed92:14ec:1b39:9667) |
17:00.39 | *** join/#asterisk rpifan (~androirc@12.206.107.11) |
17:00.45 | rpifan | Hello |
17:03.59 | *** join/#asterisk rwb (~Thunderbi@74.85.159.242) |
17:06.13 | *** join/#asterisk viebig (c88fa9b5@gateway/web/freenode/ip.200.143.169.181) |
17:06.47 | viebig | hi all! Is it possible to listen to SIP status using AMI or ARI ? |
17:07.33 | viebig | for instance, I need to know all the sip status history of a call |
17:20.03 | *** join/#asterisk dakudos (~dakudos@c-73-203-6-107.hsd1.co.comcast.net) |
17:20.27 | *** join/#asterisk K0HAX (~michael@28.139.154.104.bc.googleusercontent.com) |
17:26.51 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
17:27.16 | [TK]D-Fender | viebig, What do you mean exactly? |
17:33.09 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
17:35.04 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
17:42.11 | *** join/#asterisk NotSecwitter (~NonSecwit@unaffiliated/nonsecwitter) |
17:51.34 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
18:00.35 | viebig | [TK]D-Fender: I need to reveive and record all SIP events |
18:00.41 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
18:01.02 | viebig | [TK]D-Fender: for instance, 183, 200 .. time between then etc |
18:07.04 | [TK]D-Fender | There is no mechanism for that in Asterisk |
18:39.03 | *** join/#asterisk ShaunR (~ShaunR@freenode/sponsor/NDChost.com) |
18:41.01 | ShaunR | Any recommendations on a good SIP Trunk provider in the US? Looking for a provider that allows a dynamic incomming concurrent connection count and mainly just charges for usage. |
18:58.37 | [TK]D-Fender | ~itsplist-us |
18:58.37 | infobot | Here are some popular ITSPs (USA) starting with the more respected ones: http://www.broadvoice.com, http://www.jnctn.com, http://www.sipstation.com, http://vitelity.net, http://voip.ms and http://flowroute.com |
18:58.48 | [TK]D-Fender | voip.ms |
19:03.16 | igcewieling | I've used Vitelity since 2005, but for very low volume. |
19:09.05 | *** join/#asterisk NonSecwitter (~NonSecwit@unaffiliated/nonsecwitter) |
19:09.37 | *** join/#asterisk karl370 (~karl@cpe-142-129-161-190.socal.res.rr.com) |
19:10.21 | drmessano | Twilio should be added to that list |
19:11.23 | *** join/#asterisk startledmarmot (~startledm@2601:582:4301:a05c:7d1d:549f:5a09:17e6) |
19:11.39 | *** join/#asterisk pruonckk (~pruonckk@135-143-11-177.raimax.com.br) |
19:16.30 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
19:16.30 | *** mode/#asterisk [+o cresl1n] by ChanServ |
19:32.47 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
19:34.13 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.213.148) |
19:40.53 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
19:51.50 | *** join/#asterisk Oooohboy (~Oooohboy@cpe-67-11-10-120.satx.res.rr.com) |
19:51.53 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
20:03.22 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b012:63f2:2102:b8df:1b2:4cc1) |
20:05.22 | *** join/#asterisk AndChat-620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
20:05.47 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
20:09.19 | karl370 | Hi everyone. I have a question in regards to a remote client having problems connecting to my hosted server. I'm wondering if it has something to do with an IPv6 address. |
20:09.33 | karl370 | I'm hosting a server, straight Asterisk, v14, and an IPv4 address. The remote user had been able to connect to the server just fine, until today. The user's credentials are fine. I was able to connect to the server using the user's config file, downloaded to a phone at a different remote location. But the other user cannot connect. I used TeamViewer and did a factory reset on their phone, then set it up to download the config file fr |
20:09.33 | karl370 | om my provisioning server (different than the asterisk server). The phone downloads the config file just fine, but I never see it attempt to register on my server (whereas the test phone did). Interestingly, on my provisioning server, I see that it is using an IPv4 address, but through a browser on their desktop, it shows both an IPv4 & IPv6 address. I can connect to the phone (through TeamViewer, using an IPv4 private address), but |
20:09.34 | karl370 | am wondering if the phone is using the client's public address (potentially IPv6) and having issues. I'm using fail2ban, and have whitelisted the user's IPv4 address. |
20:09.47 | karl370 | Having not done anything with IPv6, I was wondering if there is anything specific that needs to be done to allow IPv6 clients to connect? Additionally, does anybody have an idea as to what to try next to resolve this issue? |
20:10.54 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.213.148) |
20:31.11 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b012:63f2:496b:d3a2:c240:a2b4) |
20:34.17 | *** join/#asterisk pruonckk (~pruonckk@177.11.143.135) |
20:35.59 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
20:40.58 | *** join/#asterisk tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
20:49.24 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
20:58.25 | *** part/#asterisk ShaunR (~ShaunR@freenode/sponsor/NDChost.com) |
21:00.47 | *** join/#asterisk jhord (~jhord@c-73-181-14-245.hsd1.co.comcast.net) |
21:00.52 | jhord | wondering if someone could help with NAT hacking for Cisco phones |
21:02.35 | Kobaz | hmmm |
21:09.24 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
21:21.18 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
21:24.16 | *** join/#asterisk thiagoc_ (~thiagoc@unaffiliated/thiagoc) |
21:42.01 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b012:63f2:7190:12e9:c2a6:56df) |
21:42.23 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
21:43.09 | *** join/#asterisk AndChat-620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
21:45.34 | *** join/#asterisk Micc (~Micc@static-50-125-113-34.frr01.both.wa.frontiernet.net) |
21:45.55 | Micc | Is there a way to run some dialplan code whenever someone is placed on hold and picked up from hold? |
21:46.11 | file | no |
21:46.12 | Micc | I'd like to avoid using AMI if at all possible. |
21:46.25 | Micc | ok, good to know. |
21:47.55 | *** join/#asterisk pruonckk (~pruonckk@135-143-11-177.raimax.com.br) |
21:48.02 | Micc | I guess I'll need to make an AMI proxy/aggregator since I may have multiple apps needing to get AMI events, no reason for asterisk to have to do all that work for multiple connections. Is there anything like that in open source project? |
21:53.55 | Kobaz | Micc: i have a patch that adds hold unhold events |
21:54.05 | Kobaz | you would need ami |
21:54.10 | Kobaz | or stasis or whatever |
21:54.20 | Kobaz | you can't run dialplan nicely because it takes over the channel... ie, no audio bridging |
21:54.30 | Kobaz | while your dialplan is running, no one can talk |
21:54.44 | Kobaz | (even if you *could* run dialplan on hold/unhold) |
21:58.25 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b012:63f2:75e4:7436:4526:1f0b) |
21:59.05 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
21:59.42 | *** join/#asterisk jeffspeff (~Jeff@12.49.160.131) |
22:00.06 | kai[El] | hey jeff |
22:01.18 | *** join/#asterisk SSlater (~simon@mail.favour.com.au) |
22:14.57 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
22:18.40 | *** join/#asterisk pruonckk (~pruonckk@135-143-11-177.raimax.com.br) |
22:26.02 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b010:8dc6:b94b:9626:fdff:aa5e) |
22:33.24 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
22:42.49 | *** join/#asterisk kharwell (kharwell@nat/digium/x-iovxeshrqaplebme) |
22:42.49 | *** mode/#asterisk [+o kharwell] by ChanServ |
22:47.14 | *** join/#asterisk JohnWigley (~JohnWigle@johnwigley.plus.com) |
22:51.17 | *** join/#asterisk rwb (~Thunderbi@65.183.151.121) |
23:05.32 | *** join/#asterisk Alex_Bkash (84cde551@gateway/web/freenode/ip.132.205.229.81) |
23:13.21 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b010:8dc6:2c2b:d985:fa15:6f42) |
23:22.20 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
23:25.29 | *** join/#asterisk nix8n82 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
23:33.46 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68) |
23:35.00 | *** join/#asterisk AndChat|620489 (~AndChat62@67-130-74-235.dia.static.qwest.net) |
23:39.06 | *** join/#asterisk pruonckk (~pruonckk@135-143-11-177.raimax.com.br) |
23:42.00 | *** join/#asterisk freebs (freebs@gateway/vpn/privateinternetaccess/freebs) |