| 00:17.13 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 00:44.37 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 02:31.30 | *** join/#asterisk tsal_ (~tsal@i59F5F7C4.versanet.de) |
| 02:42.06 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 03:06.02 | grummund_ | added g722 |
| 03:28.21 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 03:30.15 | *** join/#asterisk skrusty (~skrusty@88.150.145.104) |
| 03:30.15 | *** mode/#asterisk [+o skrusty] by ChanServ |
| 03:39.58 | *** join/#asterisk genevino (~genevino@m2m.pm) |
| 06:00.43 | *** join/#asterisk infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 06:00.43 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 18.1.1, 16.15.1 (2020/12/22) Final Bugfix: 13.38.1, 17.9.1 (2020/12/22); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
| 06:19.56 | *** join/#asterisk erichowey (uid462861@gateway/web/irccloud.com/x-kbiqxfjlqgmklxpq) |
| 06:21.00 | *** join/#asterisk hardwire (sid415742@gateway/web/irccloud.com/x-bpjjnwyahdtcugpy) |
| 08:03.09 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 08:04.53 | *** join/#asterisk genevino (~genevino@m2m.pm) |
| 08:05.30 | *** join/#asterisk skrusty (~skrusty@88.150.145.104) |
| 08:05.30 | *** mode/#asterisk [+o skrusty] by ChanServ |
| 08:32.58 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 08:46.23 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 08:49.18 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 09:40.01 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 09:55.42 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 10:00.48 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 10:27.56 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 10:48.18 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:02.26 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 11:12.58 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:42.26 | grummund_ | i have a problem with one siptrunk (but not another with similar config), that is inbound calls take a long time to connect, if at all. |
| 11:43.54 | grummund_ | looking at pjsip history there is no incoming traffic until asterisk attempts a REGISTER to the provider. |
| 11:45.38 | grummund_ | the REGISTER gets a 401 reply, asterisk immediately sends another REGISTER which gets a 200 OK |
| 11:47.09 | grummund_ | then the provider sends an INVITE, which succeeds, but the caller has already had 10-20s of ringing by this time. |
| 11:51.04 | grummund_ | or the caller gets silence and then a connect error, but no traffic in the pjsip history. |
| 11:52.37 | grummund_ | is this a NAT issue? should the router be configured to forward port 5060 to the asterisk box? |
| 12:08.36 | *** join/#asterisk Andee (~Andee@94.101.148.71) |
| 13:37.10 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 14:18.36 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 14:25.28 | grummund_ | setting 'expiration=60' may have fixed it. |
| 15:03.22 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:03.36 | *** join/#asterisk [TK]D-Fender (~joe@modemcable142.109-203-24.mc.videotron.ca) |
| 15:06.47 | *** join/#asterisk Andee (~Andee@94.101.148.70) |
| 15:10.23 | *** join/#asterisk Andee (~Andee@94.101.148.71) |
| 15:56.44 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 16:08.55 | *** join/#asterisk tsal (~tsal@i59F5F7C4.versanet.de) |
| 16:10.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 16:22.33 | *** join/#asterisk juser123 (~juser123@d28-23-197-92.dim.wideopenwest.com) |
| 16:25.09 | *** join/#asterisk zgu (~steve@2603-7080-b744-4900-16ad-d120-de49-dc8b.res6.spectrum.com) |
| 16:35.38 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 16:41.22 | *** join/#asterisk Barbosa (~barbosa@gn01-186-192-102-151.sim.goiania.br) |
| 16:53.28 | *** join/#asterisk Kobaz (~kobaz@its.kobaz.net) |
| 16:58.46 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 17:10.02 | grummund_ | answering my own question... |
| 17:10.04 | grummund_ | it seems the correct way to do this is [..._aor] qualify_frequency=50; qualify_timeout=0; |
| 17:13.41 | Kobaz | qualify timeout = 0 ??? |
| 17:13.55 | Kobaz | i'm jumping in last minute here, but that seems bad on so many levels |
| 17:16.20 | grummund_ | ok, well i read that with non-zero qualify_timeout, then upon no reply asterisk will remove the connection, even mid-call. |
| 17:16.44 | Kobaz | it's not a connection |
| 17:16.46 | Kobaz | it's a contact |
| 17:16.53 | Kobaz | it's AOR = address of record |
| 17:17.02 | Kobaz | for when you place a new call to that endpoint that uses the contact |
| 17:17.10 | Kobaz | if a qualify timeout fails, you don't drop the call |
| 17:17.19 | grummund_ | hmm, i read that it did. |
| 17:17.32 | Kobaz | if the ENDPOINT fails, you drop the call. if your endpoint is failing, all bets are off, and your contact and your call will go away |
| 17:18.04 | grummund_ | anyway seeing as all we want is to keep the nat table udp entry alive, does it matter? |
| 17:18.14 | grummund_ | qualify is off by default. |
| 17:18.20 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 17:18.56 | Kobaz | you might have undefined/adverse behavior for qualify enabled, and qualify_timeout=0 |
| 17:19.21 | Kobaz | like, what in your mind would happen, if you're qualifying every, say... 60 seconds, and there's no timeout? |
| 17:19.35 | Kobaz | it would just qualify and sit there... forever... doing.... nothing |
| 17:19.55 | Kobaz | timeouts are good, use them for your benefit |
| 17:20.50 | grummund_ | ok, in my mind... ;) REGISTER would expire, just as it would without qualify enable. |
| 17:21.34 | Kobaz | right, registrations have timeouts |
| 17:21.43 | grummund_ | we actually don't care if the OPTIONS packet reaches the server. |
| 17:21.49 | Kobaz | there is an implicit timeout |
| 17:22.04 | Kobaz | it's the registration period, becomes the timeout... there's always a timeout in any kind of sane communication system |
| 17:22.30 | grummund_ | btw, this is my limited noobie understanding, just piecing thing together. |
| 17:23.12 | Kobaz | curious... why don't you care if options goes out (and comes back?) |
| 17:23.27 | Kobaz | it's a great way to test if your stuff's actually working to some effect |
| 17:23.54 | grummund_ | it's just to keep the udp entry in the nat table alive (inside the router). |
| 17:24.24 | grummund_ | that is my theory as to why incoming calls fail, with this particular sip trunk. |
| 17:24.28 | Kobaz | from your end.. right? |
| 17:24.43 | Kobaz | asterisk is behind a nat? |
| 17:24.46 | grummund_ | yes |
| 17:25.02 | Kobaz | that's typically what registration is for |
| 17:25.06 | grummund_ | behind a nat and tregistering with a sip provider |
| 17:25.09 | Kobaz | registration from your asterisk -> ITSP |
| 17:25.40 | Kobaz | try lowering the registration period, and if your incoming calls are sometimes failing, your router needs attention |
| 17:25.52 | grummund_ | the register expiry is (my guess) longer than the timeout used inside the router for udp entries. |
| 17:26.02 | Kobaz | sip options might help, but... sounds like a router problem |
| 17:26.22 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 17:26.23 | grummund_ | yes, forcing a lower register expiry works too. |
| 17:26.48 | grummund_ | <PROTECTED> |
| 17:27.10 | grummund_ | http://forums.asterisk.org/viewtopic.php?t=95303 |
| 17:27.16 | Kobaz | and then you'll know if the service is 'up' or not |
| 17:27.20 | Kobaz | if your qualify is failing |
| 17:27.43 | grummund_ | true |
| 17:27.55 | Kobaz | just because it's responding to options doesn't mean it will take a call |
| 17:28.00 | Kobaz | but it's a nice early warning system to know something's up |
| 17:28.07 | Kobaz | there's no reason to disable timeouts or muck that up |
| 17:28.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 17:29.18 | grummund_ | with the other siptrunk i have (that works), the response to REGISTER sets an expiry of 60s. |
| 17:29.46 | grummund_ | so from the provider's side they effectively fix the issue. |
| 17:32.00 | grummund_ | apparently (i read) it's not unusual for a router to delete udp entries from the nat table even down to 30s. |
| 17:33.22 | Kobaz | depends on the router, there's no standard with that |
| 17:33.24 | Kobaz | what router? |
| 17:33.42 | grummund_ | technicolor adsl router |
| 17:34.54 | grummund_ | "connection state timeout values vary from product to product, but typical values are 30â¦180 seconds for UDP and 30â¦60 minutes for TCP" |
| 17:35.10 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 17:35.39 | Kobaz | adsl.. i'm sorry |
| 17:44.50 | grummund_ | btw, would forwarding udp port 5060 from the router to the asterisk machine also resolve this? |
| 17:45.06 | grummund_ | because i have to do that anyway. |
| 17:45.28 | grummund_ | (it's currently not forwarded, but will be) |
| 17:48.24 | Kobaz | yeah sure would |
| 17:48.33 | Kobaz | then the connection tracking wouldn't expire |
| 17:56.10 | grummund_ | so once a call has started the contact is no longer needed? |
| 17:56.23 | Kobaz | correct |
| 18:08.56 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 18:23.37 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:35.11 | *** part/#asterisk juser123 (~juser123@d28-23-197-92.dim.wideopenwest.com) |
| 18:35.51 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:39.59 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 18:40.19 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 18:40.27 | *** join/#asterisk mbecroft (mb@ak2.becroft.co.nz) |
| 19:17.55 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 19:21.21 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 20:25.21 | *** join/#asterisk retentiveboy (~retentive@c-24-125-16-104.hsd1.ga.comcast.net) |
| 20:29.24 | *** join/#asterisk retentiveboy_ (~retentive@c-24-125-16-104.hsd1.ga.comcast.net) |
| 20:30.03 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 20:44.02 | *** join/#asterisk paulgrmn__ (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 21:02.39 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 21:31.31 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 22:10.05 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 22:19.28 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 22:26.53 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 22:30.34 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 22:36.32 | *** part/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
| 22:58.54 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 23:14.35 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 23:23.11 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 23:23.15 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 23:42.41 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |