| 00:19.39 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:19.39 | *** 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:27.23 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 00:34.19 | *** join/#asterisk pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 00:57.32 | *** join/#asterisk rpifan (~rpifan@2600:1:d12d:35a:94fb:240f:645e:9fc2) |
| 01:33.27 | *** join/#asterisk tehgooch (~tehgooch@unaffiliated/tehgooch) |
| 02:45.26 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 02:50.24 | *** join/#asterisk rpifan (~rpifan@2600:1:d12d:35a:94fb:240f:645e:9fc2) |
| 03:09.17 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
| 03:45.36 | *** join/#asterisk overyander (~jeffspeff@mobile-166-175-191-118.mycingular.net) |
| 04:23.37 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:5169:f302:2757:562) |
| 04:23.56 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:00.01 | *** join/#asterisk cryptic (~cryptic@142.196.170.87) |
| 05:14.30 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:8031::177) |
| 05:54.35 | *** join/#asterisk sebastienthiry (~Thunderbi@109.134.212.7) |
| 06:45.29 | *** join/#asterisk areski (~areski@37.223.109.78) |
| 07:47.40 | *** join/#asterisk jkroon (~jkroon@154.73.35.201) |
| 08:04.10 | *** join/#asterisk sibyakin (~sibyakin@188.162.238.232) |
| 08:31.07 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:08.41 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:13.05 | *** join/#asterisk Oatmeal (Suzeanne@gateway/vpn/privateinternetaccess/suzeanne) |
| 09:46.04 | *** join/#asterisk CatCow97 (~mine9@c-24-22-38-85.hsd1.or.comcast.net) |
| 10:29.50 | *** join/#asterisk jamesaxl (~James_Axl@41.249.22.209) |
| 10:45.05 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 10:48.13 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:56.12 | sibiria | is there a way with outgoing calls (using chan_sip) to let asterisk wait with counting seconds towards WaitTime until it sees 180/Ringing? |
| 11:57.27 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 11:57.28 | sibiria | we've lately had many sessions that take up towards 10 seconds before they start to ringing, cutting a lot of ringing time resulting in just a few signals before the system prematurely terminates |
| 12:18.48 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:22.32 | *** join/#asterisk [sID] (~root@77.81.226.38) |
| 12:40.17 | Samot | That's not how it works. |
| 12:41.27 | Samot | Asterisk is going to make a call, it's going to wait for 1XX replies for X amount of time. If it doesn't get an 1XX reply that's a time out. |
| 12:41.57 | Samot | If it gets a 1XX reply and the calls dials for as long as the Dial() timer is set, then it's a no answer time out |
| 12:42.21 | Samot | The real question is, how fast are you getting the 1XX replies from the provider? |
| 12:51.51 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:55.27 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:02.15 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:09.48 | sibiria | Samot: at most about 6 seconds. the whole procedure from our invitation until we cancel is exactly WaitTime long, but the part between 180/Ringing and us canceling is just 6-7 seconds |
| 13:10.17 | sibiria | 14 seconds from invitation until finally 180/Ringing |
| 13:10.21 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:10.25 | Samot | So it is taking your provider 6 seconds to send back the first 1XX reply? |
| 13:11.16 | sibiria | no it sends 100/183, the first few progresses, quite instantly, but the last progress->ringing takes 6 seconds |
| 13:11.41 | Samot | 183 generally shouldn't precede a 180 |
| 13:11.47 | Samot | It should be 100/180/183 |
| 13:11.51 | Samot | Or 100/183 |
| 13:11.54 | Samot | Or 100/180 |
| 13:12.24 | sibiria | i think this is the norm with their setup before it actually gets to ringing, but it seems to make less |
| 13:12.29 | sibiria | importance |
| 13:12.30 | Samot | Also a "180 Ringing" actually doesn't mean "Ringing" in the sense of ringback or ringtone. |
| 13:12.47 | Samot | It means "We're calling the party" |
| 13:12.49 | sibiria | i interpret it in their case as when they finally got something to say from the actual operator they connect to |
| 13:13.16 | sibiria | but either way, Asterisk appears to act on WaitTime as the duration the entire process may take, before cancelling |
| 13:13.16 | Samot | 183 Session Progress is where the early media or ring back should hit. |
| 13:13.35 | Samot | WaitTime is not a Dial() setting |
| 13:13.43 | Samot | It's for how long to wait for input for DTMF. |
| 13:14.00 | sibiria | all affected customers tell us "why do you dial for 5 seconds and then hang up?", and what they tell us match the duration we see on the affected calls between 180 and 487 |
| 13:14.26 | sibiria | Samot: no; WaitTime for the call file. the ring cycle |
| 13:15.46 | Samot | OK, in that case the WaitTime is how long the Dial() should attempt. |
| 13:16.13 | Samot | So if the wait time is 30 seconds, it's waiting 30 seconds for the other side to answer or it will hangup |
| 13:16.53 | sibiria | yes, and this is a problem since this particular supplier on and off takes up towards 10 seconds before something is actually dialling at the other end. i was hoping there'd be a way to make Asterisk "reset" the counter if it sees 180 |
| 13:17.04 | Samot | No. |
| 13:17.47 | Samot | You need a proxy for that. |
| 13:18.07 | [TK]D-Fender | I don't see how one would even help |
| 13:18.17 | Samot | Because a proxy can do exactly that |
| 13:18.20 | [TK]D-Fender | * just counts its seconds from the moment it's issued |
| 13:18.26 | Samot | Reset timers based on the 1XX. |
| 13:18.39 | [TK]D-Fender | unless your proxy is the part the has the limit on it as well |
| 13:18.51 | Samot | I don't think there is one |
| 13:18.53 | [TK]D-Fender | and you don't limit the time to the proxy |
| 13:18.54 | Samot | I'm suggesting it. |
| 13:19.13 | Samot | If you want to have the counters reset on a 180 reply, you need a proxy and you need to tell the proxy to do so. |
| 13:19.43 | Samot | Or up the wait time. |
| 13:19.54 | Samot | What is the WaitTime in the callfile set to? |
| 13:20.09 | sibiria | varies, but in this case 20 seconds |
| 13:20.14 | Samot | Uhm |
| 13:20.22 | Samot | So you're attempting a call for 20 seconds. |
| 13:20.24 | Samot | That's it. |
| 13:20.28 | Samot | Doesn't matter about the rest. |
| 13:20.46 | Samot | Asterisk is going to Dial() and if there isn't an answer in 20 seconds it is hanging up. |
| 13:20.57 | Samot | Regardless how how slow or fast that 180 is coming in. |
| 13:21.07 | Samot | s/how/of |
| 13:21.36 | Samot | Why would you attempt a call for 20 seconds? |
| 13:21.57 | Samot | That's like 3-4 rings and not even enough time for the end point to time out or go to voicemail in most cases. |
| 13:22.19 | sibiria | no, that's a whole lot more than 3-4 rings, and in this *particular* case it's 20 seconds |
| 13:22.22 | sibiria | on request |
| 13:22.38 | Samot | A "ring" is about 5-6 seconds long. |
| 13:22.41 | Samot | Depending. |
| 13:22.45 | sibiria | uh, no. |
| 13:22.48 | Samot | OK. |
| 13:23.04 | Samot | The average voicemail timeout for things is about 30 seconds |
| 13:23.07 | sibiria | either way, it's not really a problem for the majority of cases - it's just that once this supplier stalls madly like this, it becomes one |
| 13:23.15 | Samot | Then don't use them. |
| 13:23.20 | Samot | Or get a proxy |
| 13:23.28 | Samot | Asterisk isn't going to be able to do what you want. |
| 13:23.28 | sibiria | it's 25 seconds (our statistics on millions of calls) - 20 seconds here is on customer request, nothing else |
| 13:23.36 | sibiria | clearly |
| 13:24.12 | sibiria | 20 seconds isn't a problem until sip provider stalls immensely. i had to ask since there just might've been a simple solution |
| 13:24.31 | Samot | I'm not sure how they are. |
| 13:24.41 | Samot | They are sending back a 100 Trying immediately? Yes? |
| 13:25.30 | sibiria | yes, and a few back and forth 183. the delay (when it does happen, which is relatively rarely) happens between the last 183 and 180 |
| 13:25.49 | sibiria | 95% of the times they patch up very fast |
| 13:26.27 | sibiria | i'm sure it's a capacity problem on their (or their operators' end) |
| 13:29.27 | Samot | So it sounds like the provider is sending you 183 Session Progress and then relaying the 180 to show the endpoint is actually receiving the INVITE. |
| 13:29.43 | Samot | So the issue is between the provider and their routes to the destination. |
| 13:29.56 | Samot | I would just not route those destinations to that provider. |
| 13:31.06 | *** join/#asterisk DanB_ (~DanB@178.138.98.72) |
| 13:33.17 | sibiria | yeah that's the immediate feeling we have, but economics etc. |
| 13:33.30 | sibiria | suits always have the last say |
| 13:36.34 | Samot | Then show the economics. |
| 13:36.52 | Samot | Show that X problem will cost Y amount. |
| 13:37.02 | Samot | And that Y amount can be avoided by Z solution. |
| 13:49.21 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:49.21 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:00.01 | *** join/#asterisk Eloy (~Eloy@89.101.24.185) |
| 14:10.48 | *** join/#asterisk sekil (~sekil@87.116.191.122) |
| 14:20.15 | *** join/#asterisk kharwell (kharwell@nat/digium/x-ufkwxfraecshiydx) |
| 14:20.15 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:23.30 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 14:37.55 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-fmhhbvpqxgpcaztg) |
| 14:37.55 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:40.25 | *** join/#asterisk mahafyi (~chatzilla@106.201.150.87) |
| 14:47.13 | *** join/#asterisk Kobaz (~kobaz@its.kobaz.net) |
| 15:27.56 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 15:33.23 | *** join/#asterisk danjenkins (danjenkins@gateway/shell/firrre/x-bpjbrlhrbespivey) |
| 15:33.23 | *** mode/#asterisk [+o danjenkins] by ChanServ |
| 16:20.48 | *** join/#asterisk DanB_ (~DanB@178.138.98.72) |
| 16:24.20 | *** join/#asterisk visip (~visix@gateway/tor-sasl/visip) |
| 16:25.14 | *** join/#asterisk DanB_ (~DanB@178.138.98.72) |
| 16:25.58 | *** join/#asterisk DanB_ (~DanB@178.138.98.72) |
| 16:28.20 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 16:57.36 | *** join/#asterisk WizJin (~WizJin@202.91.72.49) |
| 17:24.01 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 17:38.45 | *** join/#asterisk WizJin (~WizJin@202.91.72.49) |
| 17:38.52 | rndrndrnd | file, any news? |
| 17:39.07 | file | waiting on another team. |
| 18:35.37 | *** join/#asterisk DanB_ (~DanB@178.138.98.72) |
| 18:53.16 | *** join/#asterisk remote (~remote@rogers.chat) |
| 18:55.43 | *** part/#asterisk remote (~remote@rogers.chat) |
| 19:19.52 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 19:25.13 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 19:56.39 | *** join/#asterisk esteban (~esteban@unaffiliated/esteban) |
| 20:15.24 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
| 20:30.53 | *** join/#asterisk jkroon (~jkroon@165.16.204.165) |
| 21:03.37 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 21:21.50 | *** join/#asterisk mou (~donwillia@37.97.50.103) |
| 21:34.26 | *** join/#asterisk Rogach (uid6398@gateway/web/irccloud.com/x-rbbuzciajwscrbul) |
| 21:41.53 | *** join/#asterisk mhache (~mhache@CPE00907f892e2e-CM84948c574bd0.cpe.net.cable.rogers.com) |
| 21:43.15 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 21:49.21 | *** join/#asterisk visip (~visix@gateway/tor-sasl/visip) |
| 21:52.00 | *** part/#asterisk Rogach (uid6398@gateway/web/irccloud.com/x-rbbuzciajwscrbul) |
| 22:08.56 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:15.38 | *** part/#asterisk kharwell (kharwell@nat/digium/x-ufkwxfraecshiydx) |
| 22:15.39 | *** join/#asterisk misc-- (cbdb603a@gateway/web/freenode/ip.203.219.96.58) |
| 22:21.21 | *** join/#asterisk mou (~donwillia@37.97.50.103) |
| 22:26.51 | misc-- | hello, we've used asterisk for a number of years without issue then yesterday all of a sudden everything turned to crap - local handsets became unreachable by asterisk (even though they were pingable fine). Anyway to cut a long story short, it was a dns issue. The asterisk console said it couldn't look up host names but the server itself was able to look up host names fine |
| 22:28.16 | misc-- | we had the dns server set to google's dns (8.8.8.8) as is everything else on our network. As soon as we changed it to a different dns server, everything came back to life. I still don't understand why a perfectly normal dns server that could look up names, would not work for asterisk |
| 22:32.05 | *** join/#asterisk sibyakin (~sibyakin@188.162.228.155) |
| 23:22.45 | *** join/#asterisk mou (~donwillia@37.97.50.103) |
| 23:30.25 | *** join/#asterisk rpifan (~rpifan@2600:1:d12d:35a:25cb:4c35:9174:ee9b) |
| 23:31.52 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 23:34.48 | TheDoudou | hi |
| 23:35.19 | TheDoudou | i find TTS module for IVR |
| 23:36.03 | *** join/#asterisk WizJin (~WizJin@202.91.72.49) |
| 23:36.05 | TheDoudou | i try googletts.agi but don't work https://github.com/zaf/asterisk-googletts/issues/42 |
| 23:36.20 | TheDoudou | if you have other solution ... |
| 23:36.54 | WizJin | is there anybody here familiar with vos3000 |
| 23:36.59 | WizJin | i need help badly |