00:01.42 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
00:02.12 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
00:57.10 | *** join/#asterisk Bhakimi (~textual@cpe-104-33-221-31.socal.res.rr.com) |
01:03.00 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
01:50.03 | life_of_e | There's a bit of silence on the ATA when it dials out (a good four or five seconds). Is there a way to send a ringing signal back to the calling handset? I tried using Ringing() but I still get silence. |
01:50.45 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
01:51.07 | [TK]D-Fender | there is ATA dial timeout before it even passes a call to the PBX |
01:51.16 | [TK]D-Fender | which is quite likely what you're hitting |
01:51.34 | [TK]D-Fender | go look at CLI and compare the time between your last digit and the actual start of processing |
01:51.40 | life_of_e | It's about ten seconds |
01:52.35 | life_of_e | But I have every setting I can think of in the ATA set as short as I can for that timeout. But while the handset is waiting for that connection, those ten seconds are silent |
01:54.55 | [TK]D-Fender | I recall some of those GS ATA's not even HAVING a timeout setting and you're stuck with one basic value |
01:55.00 | [TK]D-Fender | and no local dialplan |
01:55.13 | [TK]D-Fender | Not sure on your specific model if they've changed.... |
02:02.16 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
02:04.57 | life_of_e | I may need to check via the SSH interface |
02:05.59 | life_of_e | BUt it does have local dialplans |
02:06.35 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:43d6:1e7a:4102:cb0c) |
02:07.17 | *** join/#asterisk yoavz (~yoavz@82.166.176.37) |
02:10.58 | *** join/#asterisk dadrc (~quassel@unaffiliated/drc) |
02:15.07 | life_of_e | There's 10 seconds between Asterisk in the console saying Called the endpoint and the endpoint "is ringing" |
02:28.02 | [TK]D-Fender | from where to where? |
02:28.15 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
02:32.48 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
02:42.49 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
02:46.37 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
02:47.55 | life_of_e | From any internal phone dialing out to the FXO |
02:53.11 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
02:53.50 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
03:17.15 | *** join/#asterisk cp- (~cp@b157153.ppp.asahi-net.or.jp) |
03:54.15 | *** join/#asterisk cp- (~cp@b157153.ppp.asahi-net.or.jp) |
04:17.22 | *** join/#asterisk azyl (~azyl@71-80-227-144.dhcp.mghl.ca.charter.com) |
04:49.35 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
04:50.37 | *** join/#asterisk andy09usa (~user@unaffiliated/andy09usa) |
05:10.05 | *** join/#asterisk ldjmx (uid357723@gateway/web/irccloud.com/x-wjvsvcmvclzmehtv) |
05:22.18 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
05:35.49 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
05:54.57 | *** join/#asterisk FelineBovine (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
06:04.15 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
06:04.54 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
06:12.53 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:22.56 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:27.23 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
06:53.37 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
06:55.00 | *** join/#asterisk jkroon (~jkroon@165.16.203.121) |
07:11.12 | *** join/#asterisk Downlots (~Downlots@185.73.41.1) |
07:13.10 | *** join/#asterisk Downlots (~Downlots@185.73.41.1) |
07:16.29 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
07:41.47 | *** join/#asterisk Da-Geek (~Da-Geek@212.183.131.194) |
07:43.07 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
07:45.45 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
07:47.33 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
07:47.59 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
07:53.14 | *** join/#asterisk sekil (~sekil@87.116.190.31) |
07:56.53 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
08:01.42 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
08:42.19 | *** join/#asterisk jkroon (~jkroon@165.16.203.121) |
08:57.47 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
09:04.21 | *** join/#asterisk lostinsip (~nick@82-71-3-134.dsl.in-addr.zen.co.uk) |
09:06.08 | lostinsip | Hi I dont know if anyone can offer any ideas as to why I cant make a call between extensions, although the phones are registered to the PBX? |
09:06.26 | lostinsip | this happened since a new switch installation |
09:07.14 | lostinsip | if I dial an extension that is actually not connected I go to the unavailable/voicemail |
09:08.20 | lostinsip | but with a pair of "Test" extensions sat next to me I get "The person at extension xx is unavailable" if i dial either extension from the other |
09:08.47 | lostinsip | I have made no changes to the PBX setup |
09:08.51 | lostinsip | any ideas? |
09:10.06 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
09:18.39 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
09:18.50 | *** join/#asterisk HB9GNF (~fwalder@unaffiliated/fwalder) |
09:27.16 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
09:30.43 | *** join/#asterisk yeehi (~yeehi@unaffiliated/yeehi) |
10:28.29 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
10:48.59 | *** join/#asterisk Downlots (~Downlots@194.219.160.131) |
10:49.16 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
11:03.49 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
11:09.38 | *** join/#asterisk Downlots_ (~Downlots@185.73.41.1) |
11:14.29 | Shorty_ | has anyone had any issues with T.38 re-invitations? I'm seeing a T.38 reinvite from my provider, which we reject with a 488 (I don't want to do it), I then see another re-invite for audio, which we also 488. The other end then hangs that channel up on us |
11:28.13 | Shorty_ | best I can tell, asterisk should *not* be 488'ing that second re-invite |
11:28.40 | file | what SIP implementation? |
11:31.13 | *** join/#asterisk yeehi_ (~yeehi@unaffiliated/yeehi) |
11:34.40 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
11:40.24 | Shorty_ | file: PJSIP |
11:41.04 | file | What version of Asterisk and PJSIP? |
11:41.14 | Shorty_ | for comparision, I've done a call to the same number and provider on my asterisk 11 instance running normal SIP.. it handles the call correctly |
11:41.25 | Shorty_ | Asterisk 16.2.1~dfsg-0~ppa1 built by nobody @ buildd.debian.org on a unknown running Linux on 2019-02-28 21:36:30 UTC |
11:41.35 | Shorty_ | PJPROJECT version currently running against: 2.8 |
11:42.27 | Shorty_ | I did capture some debug out of it at some point in the past I can probably dig up, I saw that the media request was saying it was an image, even though the re-invite definately wasn't.. almost like it was caching the media type of 'image' |
11:42.50 | Shorty_ | I tried digging through the code, but I'm not very strong with C so I got lost |
11:43.04 | Shorty_ | as it was I have to lodge 3 crashing bugs with T.38 handling (one of the reasons it's now off) |
11:45.05 | file | I don't know if anyone has tested the scenario, although it should be fine |
11:45.23 | Shorty_ | I have a PCAP showing the rejection |
11:45.28 | file | It's not necessary to reinvite again after the 488 so few impls do |
11:45.46 | Shorty_ | the other end is asterisk fwiw |
11:45.52 | Shorty_ | which version I don't know |
11:46.18 | file | I'd file an issue then |
11:48.46 | file | This does assume the second reinvite isn't wonky |
11:49.02 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
11:55.23 | Shorty_ | as mentioned, asterisk 11 handles the same thing fine, so |
11:55.33 | Shorty_ | where's the best place to whack issues these days? |
11:56.55 | file | JIRA. https://issues.asterisk.org/jira |
11:57.03 | file | No time frame on when it will get looked at |
11:57.33 | Shorty_ | *nod* fair call |
11:59.44 | Shorty_ | am I missing something, there's no way to make an issue without an account and I have to contact an admin for one? |
12:00.55 | Shorty_ | ah found the guidelines |
12:02.41 | file | There's also the signup notice in big letters on the left hand side of the main page |
12:02.54 | file | We can't alter things further without forking JIRA and modifying it |
12:04.23 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
12:13.18 | Shorty_ | fair call, I must've missed it, sorry about that |
12:15.42 | file | Many do |
12:16.00 | file | I've tried to find other ways to make it stand out without luck |
12:30.30 | Shorty_ | submitted, thanks for your help |
12:36.21 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
12:42.05 | Shorty_ | I tell you what, I'm so far over faxing xD |
12:45.13 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
12:46.35 | file | Shorty_: you should always attach files, not link elsewhere as external can go away - even if it's your own external source |
12:52.18 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-lcsumwrkdodseekr) |
12:52.18 | *** mode/#asterisk [+o bford] by ChanServ |
12:52.36 | Shorty_ | will fix shortly |
13:04.38 | sibiria | did asterisk in the past use "end + 1" of the rtp port range in rtp.conf? |
13:04.56 | sibiria | ie. setting the range to -20000 could lead to 20000 for RTP and 20001 for the connected RTCP |
13:05.01 | sibiria | if yes, is it still like this? |
13:05.14 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
13:05.49 | sibiria | i suppose it should be so, since RTCP should always land on the following uneven port |
13:09.29 | *** join/#asterisk ThE-mASkBG (~mASk@94.26.62.87) |
13:10.44 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@176.98.158.240) |
13:15.11 | ThE-mASkBG | Hello guys! |
13:15.11 | ThE-mASkBG | I have a problem. |
13:15.11 | ThE-mASkBG | Can anybody help me with configuration of confbridge.conf |
13:16.39 | file | if you ask a question, someone may answer |
13:21.24 | ThE-mASkBG | I want to make a conferencing with a user and an administrator |
13:21.24 | ThE-mASkBG | When dial number 123456, ask for identification with a pin if it is a user or an administrator |
13:34.29 | Gugge | playback a soundfile, read some dtmf, check the variable, start the conference |
13:34.55 | *** join/#asterisk Downlots (~Downlots@185.73.41.1) |
13:36.11 | Samot | Well I'm still waiting to hear what the actual problem is. |
13:36.32 | Samot | So far we've gotten a "would like list" |
13:37.16 | ThE-mASkBG | exten => 1,1,Answer() |
13:37.16 | ThE-mASkBG | same => n,Set(CONFBRIDGE(user,template)=default_user) |
13:37.16 | ThE-mASkBG | same => n,Set(CONFBRIDGE(user,admin)=yes) |
13:37.16 | ThE-mASkBG | same => n,Set(CONFBRIDGE(user,marked)=yes) |
13:37.16 | ThE-mASkBG | same => n,ConfBridge(1) |
13:37.24 | ThE-mASkBG | This works |
13:38.39 | ThE-mASkBG | I want to make sure that anyone who chooses 1 asks for a pin if they will be a user or an admin in the conference |
13:39.22 | *** join/#asterisk jkroon (~jkroon@165.16.203.121) |
13:39.34 | ThE-mASkBG | I dont know how to do it |
13:40.02 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Configuration_app_confbridge |
13:40.43 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_ConfBridge |
13:41.08 | Samot | https://github.com/asterisk/asterisk/blob/master/configs/samples/confbridge.conf.sample |
13:52.08 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
14:07.16 | ThE-mASkBG | thank you |
14:09.41 | *** join/#asterisk kharwell (kharwell@nat/digium/x-tfbdihbvvmxefett) |
14:09.41 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:40.26 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
14:46.11 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
14:51.40 | *** join/#asterisk rpifan (~rpifan@dslb-178-000-176-246.178.000.pools.vodafone-ip.de) |
15:08.10 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
15:21.51 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
15:27.07 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
15:49.13 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
16:08.13 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
16:23.50 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
16:48.49 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
16:54.22 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
17:26.42 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
17:33.24 | life_of_e | I guess I might not consider a GDS3710 door camera after all. Someone just found it making SIP connections to an IP address in China and that IP is not found anywhere in the configuration files. |
17:34.10 | seanbright | source? |
17:35.00 | life_of_e | Grandstream's helpdesk |
17:35.14 | seanbright | no source then? |
17:35.24 | life_of_e | https://forums.grandstream.com/t/gds3710-backdoor/35491 |
17:35.33 | life_of_e | PCAP data in that post |
17:37.11 | seanbright | no payload? shame |
17:37.42 | seanbright | it's using SIP backoff timing |
17:37.54 | seanbright | so probably just a misconfiguration |
17:39.20 | seanbright | and isn't 1.1.0.0 a network? can you even route packets to it? |
17:39.30 | seanbright | not really a networking guy |
17:39.34 | zaf | the chances of "1.1.0.0" being a misconfiguration is pretty high compared to the chances of it being something nefarious |
17:42.53 | seanbright | yeah, seems like a whole lotta nothing |
17:44.06 | file | I don't even think that range is announced on the public internet |
17:44.09 | life_of_e | You can address something ending in .0 if it's part of a larger block. I do agree that it's a misconfiguration but why is there a hardcoded IP in the firmware? If that IP isn't showing up in any configuration file there's no way to put it in. |
17:44.31 | *** join/#asterisk overyander (~jeffspeff@209.141.208.197) |
17:44.31 | seanbright | kinda shitty of that user to use the subject "GDS3710 backdoor" as if it was a foregone conclusion |
17:44.39 | seanbright | FUD |
17:44.42 | life_of_e | I agree with that |
17:45.00 | life_of_e | I'm just not a general fan of things making hidden contacts no matter the reason |
17:45.22 | life_of_e | 1.1.0.0 is indeed routed and advertised. It belongs to China Telecom |
17:45.27 | seanbright | have you never had a device require a factory reset? |
17:45.58 | life_of_e | Sure, but I always can see what it attempts to contact. |
17:45.59 | seanbright | it's possible that the config is just corrupted |
17:46.25 | seanbright | i'd like to see the payload of those packets |
17:46.48 | life_of_e | That would be fascinating. |
17:46.49 | seanbright | well, i take that back |
17:46.55 | seanbright | it's not asterisk |
17:47.00 | seanbright | and i don't own a grandstream |
17:47.11 | seanbright | so i don't really care |
17:47.15 | life_of_e | :) |
17:47.34 | life_of_e | I'm just fascinated from a network security perspective. It's one of my hobbies |
17:52.45 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
18:02.42 | [TK]D-Fender | "some guy in a forum" = wrong by default 99% of the time :) |
18:04.38 | Samot | "some guy on IRC" = wrong by default 99% of the time :) |
18:04.43 | Samot | Same applies. |
18:06.59 | life_of_e | It got me curious enough to put a monitor on the firewall just to see if my ATA is doing anything |
18:08.15 | life_of_e | I know I have enough chatty devices that I have to block already. |
18:19.36 | *** join/#asterisk rpifan (~rpifan@dslb-178-000-176-246.178.000.pools.vodafone-ip.de) |
18:54.53 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
19:01.37 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
19:05.27 | life_of_e | Grandstream's support is a bit slow on the reading comprehension |
19:06.40 | life_of_e | They asked for PCAPs and debug syslogs. So I made them, zipped them up and sent them in. Then they return a message saying "We need the debug logs." Uh, open the zip file. |
19:09.28 | seanbright | oh |
19:09.31 | seanbright | you're the OP? |
19:13.32 | *** join/#asterisk defsdoor_ (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
19:16.52 | life_of_e | for the camera? no, this is captures trying to figure out why there's a 10 second delay dialing out the FXO |
19:17.12 | seanbright | hmmm... |
19:18.50 | life_of_e | I can see it in the Asterisk console, between the time Asterisk says "Called..." to the time it says "...is ringing" is about ten seconds. Nothing else shows up in the console between those. |
19:21.18 | life_of_e | It takes 5 seconds from the time the endpoint sends off the dial to the time that the ATA starts sending DTMF tones to the PSTN. Then the tones play very slowly (about 0.5 seconds per digit). |
19:21.25 | [TK]D-Fender | Then maybe the HT is really slow before, while dialing, and slow to pick up progress in audio (which is probably what it is doing). |
19:22.11 | life_of_e | perhaps so, I had to add the ring option to the dial command so someone would know the dialing was happening. Otherwise the channel is dead silent. |
19:29.45 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
19:31.51 | *** join/#asterisk ketas (~ketas@9-103-46-176.dyn.estpak.ee) |
19:32.59 | life_of_e | We'll see what they say. The person responding on the helpdesk says they'll take the captures "So we can check in laboratory" |
19:35.31 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
20:15.52 | life_of_e | They seem lost now. Every thing they've asked me to set, reset, change, whatever, are all related to inbound calls from PSTN when I've stated multiple times the delay is calls to the PSTN not from it. |
20:32.17 | *** join/#asterisk miralin (~Thunderbi@81.177.58.137) |
20:39.26 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
20:40.42 | *** join/#asterisk miralin1 (~Thunderbi@81.177.58.137) |
21:04.33 | life_of_e | I guess the concept with any Grandstream product is that it better work exactly right for what you need because anything else and you won't really get any help from them. |
21:08.33 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
21:16.33 | life_of_e | They're trying to blame it all on the POTS line taking 10 seconds to process the DTMF tones |
21:21.05 | life_of_e | I can hear everyone rolling their eyes. :) |
21:28.31 | avb | life_of_e: :) i think the concept of all GS AT always been 'or its working or not' :) |
21:29.00 | avb | if something is wrong, its less likely that you will make it work |
21:30.26 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
21:35.48 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
21:43.00 | life_of_e | I know, but boy is the support system infuriating |
21:43.59 | life_of_e | Somehow the phone company is causing the delay even though the ATA hasn't even picked up the phone line to begin dialing. This is Grandstream's claim anyway. |
22:08.51 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
22:10.46 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
23:21.42 | *** part/#asterisk kharwell (kharwell@nat/digium/x-tfbdihbvvmxefett) |
23:33.52 | *** join/#asterisk techquila (~techquila@2407:7000:9125:e400:f1c2:df9f:be37:22a2) |
23:54.39 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |