| 00:20.00 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 01:10.04 | *** join/#asterisk-dev snuff-work (~blatus@1.136.96.146) |
| 01:10.05 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:21.15 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 02:59.30 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 05:36.45 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 05:52.10 | *** join/#asterisk-dev Demon_VoIP (~demon@eoks.ivanovo.ru) |
| 06:40.17 | *** join/#asterisk-dev zpotoloom (~zpotoloom@173.88.50.84.sta.estpak.ee) |
| 07:48.39 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 07:48.39 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 08:10.43 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:10.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:15.29 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:15.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:24.59 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e5e8:1ffe:9b6f:5c51) |
| 08:27.21 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:27.55 | oej | Hello folks |
| 12:14.21 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hkrxnsucqxwjfsap) |
| 12:14.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:19.35 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:36.45 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 13:02.00 | skrusty | afternoon all |
| 13:02.22 | file | yo |
| 13:06.22 | mjordan | morning! |
| 13:07.33 | skrusty | mjordan: i was thinking about starting a discussion on the -dev mailing list about ari and progress/early media |
| 13:09.49 | mjordan | sure! |
| 13:09.58 | skrusty | not sure if others are running into it |
| 13:09.59 | mjordan | would probably be good to get the thoughts going on that |
| 13:10.09 | mjordan | I think a few folks did |
| 13:10.09 | skrusty | but it's starting to cause me a few problems here and there |
| 13:13.20 | skrusty | are there other places where people are talking about ari, seems in general little chatter on -dev mailing list. would be good to talk more with others using ari :) |
| 13:13.54 | file | app-dev and -dev are primarily it |
| 13:14.10 | file | I know people are using it because I see mention of it on Twitter, IRC, and the odd forum post here and there... |
| 13:14.10 | skrusty | yeah, sorry i meant app-dev |
| 13:14.56 | skrusty | i think you need to push forwards the ARI task force file ;) |
| 13:15.12 | file | sorry, I'm pushing the DNS task force forwards |
| 13:15.14 | file | :P |
| 13:26.30 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-ccbnyzhymhprvbeb) |
| 13:36.38 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 13:36.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:39.25 | *** join/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:39.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:44.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@86.62.67.131) |
| 13:47.05 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-ninpliiqaekfwlqs) |
| 13:50.53 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 13:50.53 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 13:51.21 | *** join/#asterisk-dev newtonr (~RustyNewt@173-21-90-203.client.mchsi.com) |
| 13:51.21 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:14.13 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-eblxdqdrnayxyalv) |
| 14:21.33 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-ryjajwpjavpymezb) |
| 14:22.33 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-czgjfceqdbignfgr) |
| 14:22.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:26.09 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:26.09 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:37.56 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-lseqkfaibrvomrzd) |
| 14:48.00 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-bqazeelxaotivdpp) |
| 14:53.14 | *** join/#asterisk-dev jgowdy (bt@hur.ruhr) |
| 14:53.44 | Demon_VoIP | newtonr, Hello. I did the patch. https://issues.asterisk.org/jira/browse/ASTERISK-24852 |
| 14:55.39 | newtonr | Demon_VoIP, cool, I'll take a look at it when I get a chance |
| 14:55.56 | newtonr | Demon_VoIP, go ahead and take a look at the information on code review here: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process |
| 14:56.56 | newtonr | and get the patch up on Reviewboard so others can review it |
| 14:58.06 | Demon_VoIP | newtonr, thanks. "bug marshals will triage the issue per the Issue Tracker Workflow". Do I have to create something? Or should I wait? |
| 15:34.18 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:34.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:45.34 | *** join/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:45.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:10.21 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-ykqgdrrviyppstbv) |
| 16:10.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:12.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@86.62.67.131) |
| 16:37.11 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-hdnadazjgblynpcz) |
| 16:49.22 | *** join/#asterisk-dev nix8n82 (~AndChat56@2601:1:9780:76d:bd93:703c:2147:dea8) |
| 17:01.48 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 17:25.07 | mjordan | nuts. We only support a single authenticator at a time in PJSIP. |
| 17:26.42 | file | that statement is factual |
| 17:26.48 | mjordan | wouldn't be hard to change. |
| 17:28.12 | mjordan | contemplating daniel's e-mail. The authentication change would be pretty straight forward; I'm not sure if the implication is also endpoint identification - which feels like part of the problem alluded to in the notion of spinning up new resources and trusting the requests you receive from them |
| 17:33.28 | mjordan | maybe not 'trusting' at that stage. More like knowing who is now in your network of peers. But I guess that boils back down to realtime, if anything. |
| 17:36.39 | file | unless you push the data along to construct them and do it on the fly |
| 17:36.58 | mjordan | true. That'd be a bit large. |
| 17:37.17 | mjordan | rather interesting too. |
| 17:37.27 | mjordan | Probably wouldn't even be a REGISTER. Could really be anything sent to the system. |
| 17:37.41 | mjordan | "Here's my JSON: Make me an endpoint!" |
| 17:37.48 | mjordan | cra cra |
| 17:46.13 | file | PJSIP Endpoints: On Demand! Coming to a TV provider near you. |
| 17:46.36 | mjordan | the possibilities are endless! Sort of. Mostly you can just pass in JSON and make endpoints on the fly. |
| 17:46.56 | mjordan | oh for an infinite amount of free time and an actual business need |
| 17:47.14 | file | mjordan, your face is a business need! or something |
| 18:15.16 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:15.16 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:23.05 | *** join/#asterisk-dev goddva (~goddva@2001:840:4259:a53:2ab2:bdff:feef:adf8) |
| 18:44.57 | *** join/#asterisk-dev y_ateya (~y_ateya@41.45.38.160) |
| 18:46.45 | y_ateya | Hi, I was wondering about the importance LAGRQ and LAGRP packets in IAX? |
| 18:47.08 | y_ateya | They seem pretty useless. |
| 18:48.32 | mjordan | y_ateya: hey, I saw your e-mail to the -dev list |
| 18:48.42 | mjordan | I haven't had a chance to dig into the RFC and the code to find out whether or not they are really useful or not |
| 18:48.53 | mjordan | but it's on my list of things to respond to :-) |
| 18:49.06 | y_ateya | ok, thanks :) |
| 18:49.29 | y_ateya | Well, I also traced PING/PONG (when jitter buffer is disabled). |
| 18:49.59 | y_ateya | PING/PONG if only useful when jitter buffer is enabled. |
| 18:52.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@79.164.130.75) |
| 18:53.48 | gtjoseph | y_ateya: I think PING/PONG also provides the equivalent of a SIP qualify whether jitter buffer is used or not. |
| 18:54.34 | y_ateya | on IAX, qualifying is done using POKE/PONG |
| 18:54.48 | gtjoseph | Ah, you're correct. It's POKE. |
| 18:55.24 | y_ateya | PING/PONG just do this "iaxs[fr->callno]->lag" . and this lag it not used anywhere else. |
| 18:55.53 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:55.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:08.23 | y_ateya | mjordan: While debugging in IAX I added more details to debug messages and some comments. It is allowed to commit them? |
| 19:10.45 | mjordan | depends - you can certainly put them up for review |
| 19:11.15 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Code+Review |
| 19:11.24 | mjordan | but if you think they'd be helpful, then please do put it up for review |
| 19:22.02 | goddva | Hi guys, is the REF_DEBUG removed from the 'make menuselect' ? |
| 19:26.37 | mjordan | no |
| 19:30.39 | y_ateya | goddva: I have it in v13.2.0 |
| 19:31.34 | goddva | ok, thanks, then I need to do some more research :) |
| 19:33.52 | goddva | I'm so sorry, it was 11.6 :/ |
| 19:34.16 | goddva | see that it was first available from 11.10 |
| 19:48.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 19:49.27 | *** join/#asterisk-dev Demon_VoIP (~demon@ip253.net222.n37.ru) |
| 19:54.14 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 19:55.04 | y_ateya | mjordan: In your last email, you meant PING/POKE or PING/PONG? because POKE/PONG are used for reachability and PING/PONG used for jitter buffer calculations. |
| 19:59.48 | mjordan | both POKE and PING are used for reachability. As an implementation detail, PING is also used for some aspect of jitter. |
| 20:02.56 | mjordan | although I suspect that it isn't really even used by the jitter buffer. Dumping out the value doesn't really count for that. |
| 20:03.19 | mjordan | all the jitter buffer should care about is the origin timestamp for the voice frame being buffered |
| 20:05.19 | y_ateya | in the code, I see that only PONG-reply-to-POKE can change client state. PONG-reply-to-PING just update jitter buffer. |
| 20:05.20 | mjordan | of course, IAX2 does have the weird control frames. Even still, the fact that a PING changes the qualify round trip time of a peer shouldn't matter to the jitter buffer. |
| 20:05.30 | mjordan | y_ateya: where do you think it modified the jitter buffer? |
| 20:05.48 | y_ateya | in PONG handling, there is this if condition if (iaxs[fr->callno]->peerpoke) { /*update client state*/ } |
| 20:06.59 | mjordan | that has nothing to do with the command that was sent. |
| 20:07.07 | mjordan | peerpoke is simply the peer that was poked. |
| 20:07.15 | mjordan | A PONG Command is received for both pings and pokes. |
| 20:07.34 | mjordan | in both cases, so long as a peerpoke was set up (which it probably would be in both situations), the response time to the peer will be updated. |
| 20:07.55 | mjordan | log_jitterstats doesn't actually modify the jitter buffer. It just dumps the stats from the jitter buffer. |
| 20:09.03 | mjordan | and in either case, even if a ping doesn't have a poke peer, it kind of doesn't matter. The principle is academic (and the notion of having PING versus POKE is kind of silly anyway.) |
| 20:09.30 | mjordan | the purpose of the PING is still to "test connectivity of the remote IAX endpoint on an existing call." |
| 20:09.51 | mjordan | thinks IAX went a little overboard with all this stuff |
| 20:17.59 | *** join/#asterisk-dev nix8n82 (~AndChat56@2601:1:9780:76d:bd93:703c:2147:dea8) |
| 20:43.29 | y_ateya | mjordan: I am working on separating qos configurations. Function setsockopt implementation (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/core/sock.c?id=refs/tags/v3.19.1#n782) seems really small (just sets sk->sk_priority). |
| 20:44.16 | y_ateya | Calling it don't have any other side effects. |
| 20:52.03 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 20:53.29 | mjordan | what I don't know is what that does to enqueued packets on a socket, particularly in the presence of overlapping signalling/media on a busy socket. I can't say that it's a bad idea - but I think it'd be safest at the least to keep the existing behaviour as a default and - if someone wants to toggle the qos on the socket based on the frame being sent - have that be a separate config option. |
| 20:55.52 | y_ateya | sure, I was planning to make a separate configurations for it and make it disabled by default. Will put it for review when I finish. |
| 20:57.24 | mjordan | cool! |
| 20:58.03 | y_ateya | Regarding its effect on enqueued packets, I am diving in linux kernel code to be sure that it effect following packets OR following-and-queued packets. I used it before on another network application and noticed that it affects following packets only. but better to confirm. |
| 21:06.01 | mjordan | yay! Found a new undocumented config option |
| 21:23.15 | gtjoseph | and that would be... |
| 21:25.18 | mjordan | asterisk.conf entityid |
| 21:25.39 | mjordan | I would expect it to be unused, and really probably shouldn't be specified unless you know you want it |
| 21:25.47 | mjordan | And I mean, *really* know you want it |
| 21:26.08 | mjordan | overrides the calculation of the default Asterisk EID |
| 21:26.21 | gtjoseph | I want it! I want it! |
| 21:26.27 | mjordan | which could lead to hilarity if two systems had the same one |
| 21:26.33 | gtjoseph | I have no idea why but I do. |
| 21:26.36 | mjordan | lol |
| 21:26.46 | mjordan | distributed device state would be "interesting" |
| 21:26.59 | gtjoseph | I take it it's currently calculated? |
| 21:27.15 | mjordan | yeah, based on MAC address (at least) and I think a few other things (can't recall) |
| 21:27.19 | mjordan | probably would end up with some lovely infinite message loops in Corosync |
| 21:27.27 | gtjoseph | oh, like the wonderful asthostid? |
| 21:27.55 | gtjoseph | actually it might be useful if you were planning on a hot standby environment.had to |
| 21:28.41 | gtjoseph | by specifying the entityid you could configure the standby to come up with the same id. |
| 21:34.47 | mjordan | yeah |
| 21:34.55 | mjordan | I actually need it for a test I'm writing |
| 21:35.14 | mjordan | I'll get it documented up in a bit. Heading home now... |
| 21:35.50 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-ykqgdrrviyppstbv) |
| 22:17.27 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 22:17.27 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 13.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 22:19.26 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 23:27.21 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-eblxdqdrnayxyalv) |