| 00:25.44 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-wvbgjqtxekvtfppi) |
| 01:18.16 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:18.16 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 02:00.05 | *** join/#asterisk-dev leedm777 (~textual@216.186.181.138) |
| 02:00.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 02:55.53 | *** join/#asterisk-dev leedm777 (~textual@50-81-29-44.client.mchsi.com) |
| 02:55.53 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:01.36 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:6dee:987d:bd0e:d97f) |
| 05:01.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:16.21 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 07:47.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:a100:9100:8164:24ed) |
| 08:10.50 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:43.49 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:52.48 | snuff-work | apparently.. @see is used for URLs etc if u hadnt found it already.. |
| 09:53.08 | snuff-work | man.. i remember doing some of the doxygen fixes.. man that was a while ago now |
| 10:04.11 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 10:04.11 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 10:09.07 | *** join/#asterisk-dev Dovid (~dovid@ool-45738ae3.dyn.optonline.net) |
| 11:58.25 | *** join/#asterisk-dev jkroon (~jkroon@209.203.34.30) |
| 12:10.09 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 13:09.49 | file | achoo. |
| 14:08.36 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-loiallshncvehomo) |
| 14:08.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:56.53 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-vblzntlpdqzjqpeh) |
| 14:56.53 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:33.19 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:33.19 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:48.45 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 15:52.36 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bbryybjlqgmnxyma) |
| 15:52.36 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:01.26 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rpcynbbkcogyfngf) |
| 16:01.26 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:58.21 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:58.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:58.49 | coreyfarrell | anyone see harm in traud's suggestion to pass the same path to ldconfig for uninstall as we do for install? I'm thinking this should be fine but admittedly the Asterisk Makefile never runs ldconfig for me (it's always done by RPM or I'm non-root with an rpath). https://gerrit.asterisk.org/8000 |
| 17:02.29 | file | probably fine? |
| 17:21.39 | coreyfarrell | also https://gerrit.asterisk.org/8061 - replacing 4 cases of typeof with __typeof__. the root problem is that net-snmp on FreeBSD tells us to use '-std=c99' for CFLAGS instead of just telling us where to find the headers. |
| 17:22.16 | coreyfarrell | I'm thinking there is nothing for us to do in Asterisk, we explicitly require GCC extensions (documented since forever in the README). |
| 17:23.55 | file | I'd agree with that |
| 18:31.06 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-heqjvoxirchybeeb) |
| 18:31.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:03.42 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:03.42 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:28.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0074d1292d58bf807d.ipv6.abo.wanadoo.fr) |
| 19:52.53 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 19:52.53 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 20:00.10 | X-Rob | hey file - dumb question. We've discovered that we can cause asterisk to stop processing RTP packets for ~100msec when an AGI is run. Any idea what could still be single threaded in 14.7 that we could be tickling? |
| 20:00.34 | file | RTP is read and handled in the thread executing the channel |
| 20:00.46 | file | if res_agi blocks for a period of time for some reason, then it'll cause that |
| 20:01.16 | X-Rob | Yeah, but this is unrelated, it appears to be system wide. tm1000, jsmith and I are in a conf, and watching logs, and we're getting brief packet loss when dialparties.agi is run |
| 20:01.28 | X-Rob | for other calls on the system |
| 20:01.31 | file | then nope |
| 20:01.44 | file | haven't heard of anything like that, and shouldn't occur |
| 20:01.48 | X-Rob | That's what I think |
| 20:01.54 | jsmith | file: It *may* be related to AstDB lookups -- that's our current theory |
| 20:01.57 | X-Rob | What about astdb? |
| 20:02.00 | X-Rob | ^^^^ snap |
| 20:02.06 | jsmith | file: The AGI script is doing a bunch of AstDB database lookups |
| 20:02.25 | file | if multiple threads are accessing AstDB then they'd block each other if I recall |
| 20:02.33 | X-Rob | but not RTP |
| 20:02.34 | file | but the act of AstDB doesn't stop other unrelated threads |
| 20:03.03 | X-Rob | Hmmm. hints? I've noticed packet loss when bulk hints are updated on a reload? |
| 20:03.04 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-clzttpwhdlvrxpfm) |
| 20:03.04 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:03.11 | X-Rob | but I feel that's unrelated |
| 20:03.12 | jsmith | file: That's what I thought, but there at least seems to be a correlation in what we're seeing .. we're still trying to narrow it down. |
| 20:03.18 | file | nope, no idea |
| 20:03.40 | X-Rob | Thanks anyway, file. I feel slightly vindicated that we can stump you 8) |
| 20:06.27 | gtjoseph | coreyfarrell: you just couldn't wait to delete res_pjsip_registrar_expire from master could you? :) |
| 20:06.38 | coreyfarrell | I like deleting things |
| 20:06.56 | gtjoseph | was it keeping you up last night worrying about it? |
| 20:07.26 | coreyfarrell | no. and I can abandon if you're not done with it. |
| 20:07.42 | gtjoseph | nope just a little afternoon humor |
| 20:08.12 | coreyfarrell | :) you think I should do something in 13/15? |
| 20:09.13 | gtjoseph | i'd poll the studio audience on that one. i'm fine with it. what happens when someone's modules.conf tries to explicitly load it? |
| 20:10.01 | coreyfarrell | if we delete the module load=res_pjsip_registrar_expire would warn. require=.. would abort startup. |
| 20:10.10 | file | I'd prefer not to because of that warning |
| 20:10.16 | gtjoseph | yeah |
| 20:10.22 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.167) |
| 20:10.45 | coreyfarrell | but I was more thinking that we should make it deprecated it in 13/15. |
| 20:10.56 | gtjoseph | oh, that's fine |
| 20:11.13 | gtjoseph | with a note in CHANGES |
| 20:11.40 | X-Rob | file: sooooo we've done a bunch of AGI(/bin/true) and when we're in a CONFERENCE it's messed up. Direct calls are fine. |
| 20:11.54 | X-Rob | in confbridge |
| 20:13.35 | file | the only difference is that confbridge uses a timing source and mixing thread, if something is hogging up the system such that those don't go CPU time then depending on the jitterbuffers in use the audio can go wonky |
| 20:14.09 | X-Rob | We're just trying it with meetme now, out of curiosity |
| 20:14.12 | jsmith | file: We're definitely hearing "wonky"... |
| 20:14.24 | file | meetme mixes in kernel land. |
| 20:15.58 | gtjoseph | coreyfarrell: are you ok with alexander's autoconf ->2.60a patch now? |
| 20:16.02 | X-Rob | meetme is fine. confbridge is sadpanda. |
| 20:16.25 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:16.26 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:19.01 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:19.01 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 20:21.10 | coreyfarrell | gtjoseph: yeah |
| 20:21.42 | coreyfarrell | about the CHANGES are you asking me to add that to master for the delete or 13/15 for the deprecation? |
| 20:21.47 | gtjoseph | thanks...trying to clear out some backlog |
| 20:22.02 | gtjoseph | both please |
| 20:22.22 | coreyfarrell | hates the CHANGES file. |
| 20:22.41 | coreyfarrell | I'll get that done after I eat. |
| 20:22.46 | file | is hated |
| 20:23.34 | gtjoseph | i'm going to propose that each change become single file and that we put them in a changes/<branch> dir and let the release scripts generate CHANGES |
| 20:23.50 | X-Rob | file: OK, so we've narrowed it down to running a confbridge, and having people join. Then have someone else run this, and the audio is derped in the confbridge. |
| 20:23.53 | gtjoseph | you just put your file into the appropriate dir |
| 20:23.56 | X-Rob | https://www.irccloud.com/pastebin/LRQCPccK/agibug.txt |
| 20:24.08 | file | ok |
| 20:24.09 | X-Rob | So, file, does this feel like a bug to you, and should I be opening a ticket? |
| 20:24.20 | file | 14.7 is not supported for bug fixes :P |
| 20:24.26 | X-Rob | Heh |
| 20:24.37 | X-Rob | What would you like me to run? |
| 20:24.49 | file | Asterisk 13 and Asterisk 15 are the only branches that receive bug fixes |
| 20:25.15 | X-Rob | That's a good point. |
| 20:25.25 | X-Rob | OK, I will switch to 15. |
| 20:25.39 | file | you can file an issue, gtjoseph will triage it |
| 20:25.53 | X-Rob | file: Thanks man. |
| 20:25.59 | file | but if it's starving the confbridge for some reason, then this can and will happen |
| 20:26.04 | gtjoseph | 404 not found |
| 20:27.57 | coreyfarrell | gtjoseph: that would be awesome. |
| 20:30.16 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-lckumkgcngwjpgpm) |
| 20:30.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:22.21 | seanbright | hello friends |
| 21:22.45 | seanbright | question about asterisk & pjsip & tls & NAT |
| 21:23.02 | seanbright | so i have a domain name that points to a public IP |
| 21:23.09 | seanbright | that public IP is natted to a private IP |
| 21:23.38 | seanbright | i set external_signalling_address on that transport to the domain name |
| 21:24.18 | seanbright | but the contact header that asterisk sends (in a 200 OK for example) is the resolved IP of the domain name |
| 21:25.00 | file | placing a domain name into there is not supported currently |
| 21:25.07 | seanbright | ok, so how do i do what i want to do? |
| 21:25.29 | file | what do you desire to do? |
| 21:26.00 | seanbright | i desire that when the session timer expires that my client not try to validate the certificate as the IP |
| 21:26.10 | seanbright | which fails |
| 21:26.44 | seanbright | let me back up |
| 21:26.53 | seanbright | i have a domain, foo.bar.com which is public IP 1.2.3.4 |
| 21:26.56 | file | ah, that hasn't been explored/tweaked |
| 21:27.01 | seanbright | oh |
| 21:27.07 | file | generally clients reuse the existing connection |
| 21:27.18 | seanbright | pjsua does not for whatever reason |
| 21:28.02 | coreyfarrell | gtjoseph: minor thing I'd prefer it be "Changes/<branch>" or something not starting with "ch" so "vim ch<tab>chan_pjsip.c<enter>" would still work as it does now. I know it seems trivial but I use bash completion a lot. also hopefully UPDATE.txt can be managed the same way. |
| 21:28.03 | file | there are pjsua based clients that do |
| 21:28.18 | seanbright | can you point me to one? |
| 21:28.41 | file | I think Blink does, and I can't point you to another because of stuff and things |
| 21:29.10 | seanbright | hmmm |
| 21:29.34 | seanbright | well... thanks? |
| 21:29.54 | file | PJSIP itself will reuse a connection if there is one with the IP address and port already present |
| 21:29.56 | seanbright | out of curiosity, why can't the contact header have the domain name in it? |
| 21:30.06 | seanbright | that seems not correct |
| 21:30.16 | file | from a protocol perspective it can |
| 21:30.20 | seanbright | yeah, it's not doing that for whatever reason |
| 21:30.52 | seanbright | of course these assholes use some esoteric vcs system |
| 21:30.55 | file | but it gets resolved down on our side currently to match previous behavior |
| 21:30.56 | seanbright | darcs... pfft |
| 21:31.14 | seanbright | ah. git mirror, cool. |
| 21:31.34 | file | is the client doing an outbound registration to the server? |
| 21:32.01 | seanbright | it is not |
| 21:32.07 | seanbright | should i do that? |
| 21:32.15 | file | actually even with a normal call I'd expect the connection to get reused |
| 21:32.29 | file | unless it was torn down or disconnected |
| 21:34.26 | file | ah, unless it was from server to client... then there would be none... |
| 21:34.52 | seanbright | file: https://pastebin.com/raw/CuYVH9Ps |
| 21:35.37 | file | what's the direction of the initial call? |
| 21:36.13 | seanbright | client -> server |
| 21:36.17 | seanbright | pjsip -> asterisk |
| 21:36.22 | file | odd |
| 21:36.34 | file | was the TLS connection terminated before hand? |
| 21:38.04 | seanbright | tlsc0713C044 !TLS transport destroyed normally |
| 21:38.16 | file | ah yeah |
| 21:38.28 | file | that explains that (albeit not why it went away, but that's fine) |
| 21:38.38 | seanbright | 30 or so seconds after the ACK |
| 21:38.49 | file | yeah, you'd need to change the code to allow a domain or disable verification |
| 21:39.27 | seanbright | any idea why pjsua would destroy the transport? |
| 21:39.30 | seanbright | i realize we are OT at this point |
| 21:40.13 | file | there's an idle timer in the transport layer for it that will terminate it if it's been idle long enough, but keepalives normally keep it er alive |
| 21:40.26 | seanbright | and KAs only happen if you're registered |
| 21:40.35 | seanbright | at least that was my recollection |
| 21:40.39 | file | nah |
| 21:40.53 | seanbright | ok, so keep alives aren't working i guess |
| 21:40.55 | file | there's a transport level keepalive which occurs on active reliable transports (TCP and TLS) |
| 21:41.04 | seanbright | do you have to toggle that on? |
| 21:41.09 | file | there's one in PJSIP and one up above in our land (configurable in pjsip.conf) |
| 21:41.30 | seanbright | i have this set in global: keep_alive_interval = 15 |
| 21:41.49 | file | yeah, that should keep it alive |
| 21:41.53 | file | type=global for that section I assume? |
| 21:41.57 | seanbright | correct |
| 21:42.08 | seanbright | i guess i will wireshark it |
| 21:42.08 | file | dunno then |
| 21:42.22 | seanbright | application layer keep alives? |
| 21:42.30 | seanbright | like \r\n? |
| 21:42.33 | file | yes |
| 21:42.36 | seanbright | k |
| 21:42.57 | file | gtjoseph has been in that are recently and could provide further insight probably, albeit tomorrow as he's done for the day |
| 21:43.13 | seanbright | wish i had until then :-) |
| 21:48.45 | seanbright | pjsua claims that the ka_interval will only happen "after registration" |
| 21:48.54 | seanbright | going to try enabling that |
| 21:48.58 | seanbright | registration, that is |
| 21:49.45 | file | oic |
| 21:50.20 | seanbright | asterisk is sending them every 15, but that isn't stopping the transport from shutting down |
| 21:51.00 | seanbright | k. i think that may have done it. |
| 21:51.13 | seanbright | although registering is dumb |
| 21:51.15 | seanbright | but whatever |
| 21:51.44 | file | lack of cookies is also dumb |
| 21:52.00 | seanbright | but the registration thing especially |
| 21:53.42 | gtjoseph | reads history |
| 21:54.02 | rmudgett | Why not read the future to see what's coming? |
| 21:54.40 | gtjoseph | seanbright: do youhave the res_pjsip_transport_management module loaded? |
| 21:54.58 | seanbright | i do |
| 21:54.59 | gtjoseph | that's what does the asterisk KAs on reliable transports. |
| 21:55.03 | seanbright | asterisk is sending the KA |
| 21:55.10 | gtjoseph | ok, i'm stiull reading |
| 21:55.11 | seanbright | pjsua doesn't seem to care |
| 21:55.37 | gtjoseph | on the client side? |
| 21:55.44 | seanbright | correct |
| 21:55.56 | seanbright | until i enable registration, then it sends the KA |
| 21:56.03 | seanbright | and doesn't term the connection |
| 21:56.13 | seanbright | which i can live with, i'm just annoyed by it :-) |
| 21:56.55 | gtjoseph | yeah. a KA is just a crlf so it never gets far enough into the pj stack to be a KA at that level |
| 21:58.00 | gtjoseph | same for a TCP KA. |
| 21:58.09 | gtjoseph | it would have ot be an OPTIONS or something |
| 21:58.18 | seanbright | the real wtf is the external_signalling_address not allowing a domain name, but beggars can't be choosers |
| 21:58.42 | gtjoseph | in asterisk? |
| 21:58.47 | seanbright | yes |
| 21:58.53 | gtjoseph | i thought we just fixed that |
| 21:59.00 | gtjoseph | maybe i'm thinking of something else |
| 21:59.02 | seanbright | how recently is 'just' |
| 21:59.17 | gtjoseph | a month or two |
| 21:59.21 | file | gtjoseph: we resolved it to an IP for dynamic IPs |
| 21:59.23 | seanbright | then no |
| 21:59.30 | seanbright | it gets resolved |
| 21:59.41 | seanbright | anyway, i have a workaround so i'll stop complaining |
| 21:59.43 | seanbright | thanks for your help |
| 21:59.50 | gtjoseph | kk |
| 22:00.02 | seanbright | well... in 11 minutes i'll know if i have a workaround |
| 22:05.52 | seanbright | huzzah. |
| 22:26.31 | *** join/#asterisk-dev leedm777 (~textual@73.106.79.154) |
| 22:26.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:09.36 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-vblzntlpdqzjqpeh) |
| 23:30.16 | *** join/#asterisk-dev leedm777 (~textual@2607:fb90:99e:d5dd:b029:46fd:ab35:147e) |
| 23:30.16 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |