| 00:16.49 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-hsgacepsbfqakkvp) |
| 00:17.29 | *** join/#asterisk-dev piling (~piling@unaffiliated/piling) |
| 04:39.59 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:22.01 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 05:22.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:45.50 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:50.22 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 06:36.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:48.14 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:52.59 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:52.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:58.32 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 07:18.59 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 07:22.24 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:02.30 | *** join/#asterisk-dev tzafrir (~tzafrir@137.158.23.63) |
| 08:02.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:25.59 | *** join/#asterisk-dev jkroon (~jkroon@105.4.0.122) |
| 10:06.13 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-asswdsnmyfbyvgvi) |
| 11:18.33 | *** join/#asterisk-dev tzafrir (~tzafrir@137.158.23.63) |
| 11:18.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:21.58 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 11:40.48 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 11:55.55 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 12:28.15 | *** join/#asterisk-dev zerohalo (~zerohalo@uranium.zerohalo.net) |
| 13:26.17 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:26.18 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:58.24 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tqqsexwdtnurayit) |
| 14:05.54 | *** join/#asterisk-dev tzafrir (~tzafrir@137.158.23.63) |
| 14:05.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:32.37 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-pawuiulhigzsgxaq) |
| 14:32.37 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:19.24 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-yxgywwgzcxsgtbso) |
| 15:27.21 | *** join/#asterisk-dev tzafrir (~tzafrir@137.158.23.63) |
| 15:27.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:30.29 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 15:44.14 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-qznpratbjjcraxqk) |
| 15:44.14 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:06.01 | file | today seems to be Thursday |
| 16:24.57 | rmudgett | Are you sure? It feels like a Wednesday |
| 17:16.26 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:31.10 | rmudgett | file: https://issues.asterisk.org/jira/browse/ASTERISK-25904 explicitly makes the change that https://issues.asterisk.org/jira/browse/ASTERISK-26160 is concerned about. |
| 17:33.59 | *** join/#asterisk-dev jkroon (~jkroon@154.73.32.15) |
| 17:36.29 | mjordan | rmudgett: having an event that tells when a contact is updated is fine. The issue is that there are two events that are raised, where the first one contains information that is wrong |
| 17:37.08 | *** join/#asterisk-dev tzafrir (~tzafrir@137.158.23.63) |
| 17:37.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:37.14 | mjordan | it should be transmitting a single event when a contact is updated as the result of a new REGISTER request, but it should emit a single event, and it should contain that last known RTT time |
| 17:37.16 | rmudgett | Ah. Then the original patch would be implemented just wrong. |
| 17:37.19 | mjordan | Yup |
| 17:37.37 | mjordan | As it is, we get two events, where the first merely tells you that it was updated, but blows away the RTT time |
| 17:37.48 | rmudgett | I've been looking at how it does it and wondering how a recursion is not happening. |
| 17:37.50 | mjordan | It'd also be appropriate to not emit the verbose log message, as that gets spammy |
| 17:38.16 | mjordan | The new log messages are a result of the implementation as well, which hopefully would only emit a new event and not bother telling the CLI |
| 17:39.12 | rmudgett | Looking at AMI there is a test event that is output for every qualify. An AMI event appears to be generated for each update. |
| 17:39.59 | rmudgett | The original issue isn't clear about why the updates are needed. Just that chan_sip did it so chan_pjsip must do it too. |
| 18:03.22 | mjordan | I can think of reasons why you'd want to see it. |
| 18:04.02 | mjordan | It's a bit pedantic, but you may want to have live updates of when phones are registering. Ideally, you'd only care when a registration drops, but you could view the updates coming from Asterisk as confirmation (like a heartbeat) that all your devices are working properly. |
| 18:04.40 | mjordan | Qualify isn't really the issue here - I don't think I'd want an event on every qualification. I may be qualifying endpoints every 5 seconds - that'd be ... bad. |
| 18:05.06 | mjordan | I think the original intent was only to have it send an event when a device sends a REGISTER to Asterisk and Asterisk updates the registration for that device. |
| 18:19.11 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 18:37.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 18:37.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:46.51 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 19:28.25 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 20:30.49 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 21:47.06 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 21:57.18 | coreyfarrell | mjordan: I'm about to update the ref storage location logging code, my latest refcounter.py detects indirect leaks. so if you leak an ao2 container the linked objects will be mostly indirect leaks |
| 21:58.15 | coreyfarrell | are you suggesting instead of __ao2_ref_full just add the new parameter to __ao2_ref? |
| 22:20.57 | mjordan | yes |
| 22:20.59 | mjordan | potentially. |
| 22:21.07 | mjordan | Before you make the changes, I think it's worth having the discussion |
| 22:21.23 | mjordan | Because you'd *want* people to use the new API all the time, or at least as much as possible |
| 22:21.33 | mjordan | Which means everyone has to get used to the new API, *OR* you make the old API the new one |
| 22:21.50 | mjordan | But before anyone embarks on a world of sucky refactoring, we'd want to decide which way to go |
| 22:23.43 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 22:31.26 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 22:43.09 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-32-120-188.hsd1.al.comcast.net) |
| 22:43.09 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 23:29.46 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-tqqsexwdtnurayit) |