| 00:18.08 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:18.08 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.21.0 (2018/05/01), Standard: 15.4.0 (2018/05/01); 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:42.26 | *** join/#asterisk nimbius (~nimbius@2604:180:1:4e6::3) |
| 00:42.30 | nimbius | is there a way to get shorter VM prompts? |
| 00:58.53 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 01:12.41 | *** join/#asterisk vandyk (~vandyk@201.37.125.118) |
| 01:15.26 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 01:29.39 | *** join/#asterisk rpifan (~rpifan@2600:1:c11b:dc97:c4db:d38d:9c84:b269) |
| 01:29.41 | rpifan | hi |
| 01:38.21 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 01:58.11 | *** join/#asterisk pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 02:03.44 | *** join/#asterisk pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 02:09.08 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 02:16.25 | Penguin | Is there a way to detect transfers and three-way calls on the far end when asterisk is in the path of a call? |
| 02:18.35 | rpifan | hi |
| 03:39.29 | *** join/#asterisk tehgooch (tehgooch@unaffiliated/tehgooch) |
| 04:47.48 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 05:19.11 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:08.45 | *** join/#asterisk jkroon (~jkroon@105.0.2.117) |
| 06:55.52 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:13.52 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.145) |
| 07:27.41 | *** join/#asterisk ganbold (~ganbold@173.244.215.173) |
| 07:59.08 | *** join/#asterisk sebastienthiry (~Thunderbi@109.134.212.7) |
| 08:13.07 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 08:14.52 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 09:24.25 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:ec98:49a3:4256:4a9) |
| 09:50.53 | *** join/#asterisk jamesaxl (~James_Axl@41.249.131.53) |
| 10:36.12 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.213.148) |
| 11:00.09 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:05.11 | *** join/#asterisk vandyk (~vandyk@201.37.125.118) |
| 11:06.54 | *** join/#asterisk Adriano (~AdrianoOl@109.255.161.15) |
| 11:58.15 | *** join/#asterisk jamesaxl (~James_Axl@41.248.126.83) |
| 12:08.39 | *** join/#asterisk jkroon (~jkroon@165.16.204.165) |
| 12:28.27 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 12:36.11 | *** join/#asterisk Alblasco1702 (~Alblasco1@ip5456b46b.speed.planet.nl) |
| 12:45.56 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 13:20.40 | *** join/#asterisk roxlu (~roxlu@2a01:7c8:aac0:286:8c3a:b01c:3830:245b) |
| 13:20.45 | roxlu | hi |
| 13:21.37 | roxlu | someone around who maybe knows a bit about webrtc? I'm wondering if the STUN binding response from an ice-lite based server needs to calculate the message-interity using it's own ice-pwd or the ice-pwd of the other agent? |
| 13:27.10 | *** join/#asterisk mahafyi (~chatzilla@122.174.23.218) |
| 13:48.07 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 13:50.40 | *** join/#asterisk cryptic (~cryptic@142.196.170.87) |
| 14:14.35 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 14:32.11 | *** join/#asterisk gtTuna (~Tuna_@cpe-98-30-192-115.columbus.res.rr.com) |
| 14:41.36 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:41.36 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:43.19 | *** join/#asterisk craysiii (sid205503@gateway/web/irccloud.com/x-ttvpubqiwtjhmhqx) |
| 14:44.13 | *** join/#asterisk vandyk (~vandyk@201.37.125.118) |
| 14:47.09 | *** join/#asterisk file (sid178970@asterisk/developer-and-muffin-lover/file) |
| 14:47.10 | *** mode/#asterisk [+o file] by ChanServ |
| 15:04.49 | *** join/#asterisk craysiii (sid205503@gateway/web/irccloud.com/x-bnxbsqkiqerqshyi) |
| 15:37.11 | *** join/#asterisk craysiii (sid205503@gateway/web/irccloud.com/x-ifdgqsyocyqakqha) |
| 15:37.34 | *** join/#asterisk Dirk23 (Dirk23@diehildebrands.de) |
| 15:38.22 | *** join/#asterisk gregs (sid160074@gateway/web/irccloud.com/x-cmfrihgbzddhiffx) |
| 15:38.52 | *** join/#asterisk [J]oules (uid217910@gateway/web/irccloud.com/x-ghyksisagifkpmkt) |
| 15:39.04 | *** join/#asterisk ashka (~postmaste@pdpc/supporter/active/ashka) |
| 15:45.21 | *** join/#asterisk jkroon (~jkroon@165.16.204.165) |
| 16:27.28 | Penguin | Is there a way to detect transfers and three-way calls on the far end when asterisk is in the path of a call? |
| 16:43.19 | jkroon | blind xfer yes. |
| 16:43.34 | jkroon | the rest, not that i'm aware of. |
| 17:47.23 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
| 17:59.45 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 17:59.45 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 18:21.12 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 18:31.51 | Samot | Penguin: What do you mean by "far end" |
| 18:33.41 | Samot | If by "far end" you mean an endpoint, no. You will see there are three channels up for that endpoint but how the phone mixes/joins those channel is a phone thing. Asterisk will not know if those three channels are being mixed/joined at the phone. |
| 18:34.52 | Samot | In regards to the transfers. If the "far end" is the other side of a call over the PSTN or even a peer to the another PBX you still will not know if they transfer the call or not. |
| 18:35.24 | Samot | The only transfers Asterisk will know about are ones that are sent to it or it has to handle. |
| 18:35.41 | *** join/#asterisk gurgyblux (~sibiria@unaffiliated/sibiria) |
| 18:36.57 | Samot | Basically, Asterisk doesn't know what the "far end" is doing unless that far end sends something to Asterisk. |
| 18:37.30 | Penguin | Are you familiar with Securus? They have a policy that they don't allow three-way calling. If they "detect" it, they terminate the call. I'm interested in doing whatever they're doing. |
| 18:38.38 | Penguin | One of the things they say they detect is answering call waiting. If you answer call waiting and they detect it, they end the call. |
| 18:39.29 | Samot | But those are endpoints that have to connect to that server. |
| 18:39.34 | Samot | So that server is sending them a call |
| 18:39.38 | Samot | Or accept calls from them. |
| 18:39.44 | Samot | Just like you could do with Asterisk |
| 18:39.56 | Samot | You can only control the endpoints that are on Asterisk. |
| 18:40.12 | Penguin | In the case of Securus, the "far end" is your phone when your cousin calls you from jail. Securus being the service provider on the near side, they send the call to your phone carrier, and your phone carrier eventually connects the call to your phone.. |
| 18:40.12 | Samot | You cannot, however, tell if an endpoint joins calls together locally. |
| 18:41.11 | Samot | OK. |
| 18:41.30 | Penguin | I can't determine how they can detect if an unrelated phone is answering call waiting or starting a three-way call. |
| 18:41.34 | Samot | And if you, as the far end, try to do a three way call they drop the call? |
| 18:41.44 | Penguin | Yes, they will terminate the call. |
| 18:41.47 | Samot | OK |
| 18:42.04 | Samot | That's because in order to do a three way call you have to put the first call on hold. |
| 18:42.12 | Samot | When that happens, the media flow changes. |
| 18:42.18 | Samot | That's what they are looking for. |
| 18:42.25 | Samot | My guess. |
| 18:43.34 | Penguin | If I want to implement a policy similar to the one Securus has, I would want to make sure it won't be circumvented easily. |
| 18:44.34 | Penguin | I can detect silence, but I'm guessing that's easy to trick. So detecting silence is probably not what I want, at least not by itself. |
| 18:44.58 | Samot | Is this just for a single PBX? |
| 18:45.27 | Samot | Securus is a provider of a very specialized phone service. |
| 18:45.47 | Samot | All parts involved have to have service with them, including the correctional facility. |
| 18:46.17 | Penguin | Yes. I have one instance of asterisk which sends calls out to the PSTN. I want to ensure people on the far end are not doing three-way or conferences. But since their phones are not my phones, I can't control them directly. |
| 18:46.19 | Samot | Well at least some level of service. |
| 18:46.30 | Samot | This is more than just Asterisk. |
| 18:46.33 | Samot | They are a provider. |
| 18:46.58 | Samot | There is a lot more involved in what they do because they control switches, network, etc. |
| 18:47.20 | Penguin | I'm interested in a very small piece of their service, though. I want to emulate their three-way calling detection so I can implement a similar policy. |
| 18:47.29 | Samot | OK. |
| 18:47.33 | Samot | I get what you are trying to do. |
| 18:47.36 | Penguin | ok |
| 18:47.43 | Samot | But what I am telling you is, they have more than a PBX. |
| 18:47.58 | Samot | They have SBCs, media gateways, switches, etc. |
| 18:47.59 | file | without controlling things you can only deduce it based on what is happening without certainty |
| 18:48.01 | Samot | They are a telco. |
| 18:48.27 | file | or just limit to 1 simultaneous call, then you can't have a second so no chance of a three-way call or conference |
| 18:48.36 | Penguin | I'm guessing that their system is arbitrarily making decisions based on something on the far end (which they don't control). |
| 18:48.52 | file | ah that far end |
| 18:49.11 | file | entirely possible. |
| 18:49.41 | Penguin | If someone in the office here calls Joe Schmoe at his house, I need to ensure that Joe doesn't set up a conference on his side. I can stop my users from doing stuff, but I can't directly control what the far end does. |
| 18:49.56 | file | you can only guess and deduce. |
| 18:50.12 | Samot | Like I said, they are a telco. |
| 18:50.19 | Samot | They probably have deals with carriers. |
| 18:50.46 | Samot | They provide a specialized phone service to correctional facilities. |
| 18:50.46 | Penguin | In the case of Securus, I'm sure silence detection is only one of the mechanisms. |
| 18:50.54 | Samot | Stop. |
| 18:50.58 | Penguin | I know I can detect silence, but is there anything else I can do with asterisk? |
| 18:51.06 | Samot | This is _higher_ level stuff at work. |
| 18:51.20 | Samot | They work _with_ carriers. |
| 18:51.24 | Penguin | Are you saying there's nothing I can do with asterisk to emulate the behavior? |
| 18:51.29 | Samot | Yes. |
| 18:51.35 | Samot | Because they are using more than just a PBX |
| 18:52.27 | file | Asterisk isn't psychic, it just gets an audio stream from the remote - it's up to you to figure out the best way to analyze and deduce if you want to do that |
| 18:52.53 | Penguin | Right. And I'm asking for ideas on how to make those decisions. |
| 18:53.05 | Samot | I'm about 95% sure that part of the reason calls take so long to connect is because of how they interconnect with carriers. |
| 18:53.30 | Samot | The best you're going to get is the media flow update. |
| 18:53.34 | Samot | When the call is put on hold. |
| 18:53.58 | Penguin | And there's a good chance I won't even see it. |
| 18:53.59 | Samot | Asterisk will be told to send it's media to either a unroutable IP or receive only |
| 18:54.10 | Samot | You're going to need a switch. |
| 18:54.17 | Samot | Or a SIP proxy/router. |
| 18:54.30 | Samot | You want to look at the call much deeper than Asterisk can do. |
| 18:57.03 | Samot | I'm not completely sure, off the top of my head, on how you would achieve your goal but Asterisk cannot be the main source of it. |
| 18:57.15 | Penguin | ok |
| 18:57.20 | Samot | It can be part of the solution but it's going to require other pieces. |
| 18:58.39 | Samot | Like I said a SIP proxy/router/switch/SBC or something along those lines will let you dig into the SIP packets and the transaction/dialog of the call more than Asterisk can. |
| 19:00.24 | Penguin | At least I've got some more info to think about now. |
| 19:00.36 | Penguin | This may be something that I can't achieve. |
| 19:04.44 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 19:19.03 | jkroon | Penguin, MOH etc also have interesting characteristics. don't think it's built into asterisk, and i've got no definitive information on exactly how to do it, but you will be able to bridge off all calls into a separate channel, if i'm not mistaken you could even get each direction separate, so if you can apply a fft (fast fourier transform) I reckon you may well be able to distinguish between voice and moh too. |
| 19:21.07 | Penguin | If this project gains any traction, I will keep these ideas in mind. |
| 19:21.18 | Samot | jkroon: That doesn't solve how he will know when, on my mobile, I Flash-Hook - make another call - join both calls together. |
| 19:24.21 | Samot | Penguin: The best I have is looking at RE-Invites in the call dialog that update the SDP. |
| 19:24.40 | Samot | Because when the other side puts you on hold/flash-hooks that happens. |
| 19:25.41 | Penguin | I doubt I would see anything like that from a phone on the other side of the PSTN. |
| 19:25.43 | Samot | What really needs to happen is a bunch of test calls to various destination types. |
| 19:25.46 | Samot | Well |
| 19:25.48 | Samot | You need to test. |
| 19:26.13 | Samot | You should really be looking at what you see via a tcpdump from the provider when you do things on these calls. |
| 19:26.28 | Samot | Make a test to a mobile phone, when they flash hook what do you see? |
| 19:26.41 | Samot | If you see a change, then you know you can work with that change. |
| 19:27.02 | Samot | You're going to have to look at how your carrier is passing this information to you before you even look at how Asterisk can process/handle it. |
| 19:27.12 | Samot | Because you need to know what to look for or process. |
| 19:29.31 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
| 19:30.08 | jkroon | Samot, i agree, i'm just throwing an idea out there that could help him detect possible unwanted actions by way of audio analysis. so hook flash on my mobile starts a different voice continuously stating "you're call has been placed on hold" ... the characteristings of that voice *changes*, and thus so will the frequency analysis. it's the HARD way, so at any point one detects multiple voices from the far end, then his constraints has been violated. |
| 19:31.13 | Samot | This is going to be a large test set. Because you'll need to know what/how ATT sends this stuff back. Not only that you need to see if ATT's "landline" service sends information the same as ATT's "mobile/cell" service or their SIP/VoIP services... |
| 19:31.37 | Samot | You'll need to see how each carrier and each service type of the carrier handles this stuff. |
| 19:33.09 | Samot | jkroon: MOH is a local thing. |
| 19:33.29 | Samot | My mobile phone isn't playing MOH to your phone. |
| 19:33.40 | Samot | Unless my carrier is interjecting that. |
| 19:34.22 | Samot | "HOLD" does not immediately mean MOH |
| 19:34.53 | Samot | MoH is an additional feature that is done when the HOLD state happens. |
| 19:37.59 | Samot | It will all depend on if the provider passes that back to him or not. |
| 19:38.45 | Samot | Some systems/endpoints will "hold" someone by updating their media IP in the SDP to 0.0.0.0 (Cisco SPAs do that). |
| 19:39.38 | Samot | Some change the media direct from "sendrecv" (both ways) to "sendonly" |
| 19:40.13 | Samot | Which tells the other side, " I don't want to receive RTP from you, I'm only sending it" |
| 19:44.50 | *** join/#asterisk ashka (~postmaste@pdpc/supporter/active/ashka) |
| 20:34.03 | *** join/#asterisk rpifan (~rpifan@2600:1:d11c:8c85:c4db:d38d:9c84:b269) |
| 20:34.07 | rpifan | hi |
| 20:35.24 | igcewieling | dir |
| 20:37.30 | rpifan | cd .. |
| 21:13.15 | [TK]D-Fender | segfaults |
| 21:42.40 | *** join/#asterisk Typhon (~Typhon@dslb-092-078-206-163.092.078.pools.vodafone-ip.de) |
| 22:07.47 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:50.37 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
| 22:59.41 | *** join/#asterisk dan_j (sid21651@gateway/web/irccloud.com/x-mapzejzoleeeldat) |
| 23:01.55 | Penguin | rpifan: I don't know about you, but I can't think of a time when I needed to be in /home |
| 23:08.31 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.82) |