| 00:10.36 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-zzeuettaveclgwok) |
| 01:30.30 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:30.30 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:31.00 | *** part/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:26.19 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:26.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:02.01 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-nkjqdwamlllhhgef) |
| 04:03.26 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 04:03.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:14.55 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 07:22.09 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 07:28.24 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:32.28 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:43.54 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 07:45.07 | *** join/#asterisk-dev opticron (~opticron@75.76.148.219) |
| 07:45.07 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 08:08.03 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:47.13 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:47.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:08.17 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5587:fa5a:a1bb:f0f) |
| 12:40.18 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:40.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:01.03 | *** join/#asterisk-dev DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 13:15.36 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 13:33.23 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:48.24 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 14:21.22 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-zmftlfzuaxlrtrrh) |
| 14:45.58 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:45.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:54.52 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-cdfjbdhqnhqpaacw) |
| 14:56.19 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-bwcfapynuhaarlfn) |
| 14:57.44 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-rsftjhtlrzjwbumb) |
| 14:57.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:09.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:09.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:13.02 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-xkxcgrjouaeoeuqc) |
| 15:13.02 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:15.32 | file | so - pjsip_get_dest_info is driving me slightly cray cray |
| 15:16.10 | file | it's come up a few times now where someone has an older pjproject without it |
| 15:16.39 | file | since it's only used for the dialplan function I think we should have a configure check that makes that specific part of the dialplan function spit out an error if invoked and pjsip_get_dest_info is not available |
| 15:16.59 | file | turning off all PJSIP functionality just for that would be silly |
| 15:17.45 | putnopvut | file: I can agree with that. I wonder if there might be an alternative way to get the information that the dialplan function is after. I imagine that PJSIP releases prior to 2.3 might have had some other means of getting transport information from a destination URI. |
| 15:19.01 | putnopvut | browses changesets in sip_util.c |
| 15:19.33 | file | I traced it back and the function was originally private |
| 15:19.53 | file | or at least an implementation of it was |
| 15:20.42 | putnopvut | ah, yeah, I see it in revistion 4888 |
| 15:21.23 | putnopvut | I have to say, the commit message was not very helpful in finding that :) |
| 15:21.31 | file | truth |
| 15:23.01 | skrusty | afternoon |
| 15:23.08 | file | skrusty, hola |
| 15:25.32 | putnopvut | file: looking at pjsip_get_dest_info, it appears that what pjsip_get_dest_info does is to parse the URI, then use the transport param to determine the transport type, and then determine the secure transport flag based off that transport type. So it's possible that Asterisk could just do that instead of calling pjsip_get_dest_info() if pjsip_get_dest_info is not defined. |
| 15:26.26 | file | I'm fine with that - we may want to just do that all the time |
| 15:26.48 | putnopvut | Eh, I figure use the built-in helper if it exists. |
| 15:27.26 | file | my issue with that is if it changes somehow then we could have a disparity |
| 15:28.04 | putnopvut | Yep, and that's why I specifically want to use the built-in function instead of having to update our home-rolled version if a bug is fixed in the built-in one. |
| 15:28.47 | file | then why have the home-rolled at all? we'd still have to fix the bug there |
| 15:29.10 | putnopvut | Fair point, I DO SUPPOSE |
| 15:31.04 | putnopvut | file: is there an issue filed for this yet? |
| 15:31.10 | file | no |
| 15:31.25 | putnopvut | goes for it. |
| 15:31.36 | file | I got pushed over the edge and decided to look further |
| 15:41.34 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-cgvbucftgvadcjtq) |
| 15:44.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:47.06 | jsmith | file, leifmadsen: Go Canada! http://i.imgur.com/PYFZV6J.jpg |
| 15:47.21 | jsmith | Sorry, just had to through that out there... |
| 15:47.37 | sgalarneau | And now I am hungry. |
| 15:47.50 | skrusty | :) |
| 15:47.53 | file | truth |
| 15:48.15 | jsmith | sgalarneau: Time for second breakfast! |
| 15:49.01 | jsmith | can't decide between the box of "Cheez-Its" next to his desk and a hot bowl of oatmeal |
| 15:49.07 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ghthuivtqgaigzxf) |
| 15:49.11 | sgalarneau | jsmith: the hobbit life is truly best |
| 15:49.24 | jsmith | sgalarneau: Especially if you have hairy toes... |
| 15:50.35 | file | putnopvut, that change wasn't in 13.1.0, which is probably why it hasn't crept up more |
| 16:12.29 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-rxlhdrdlnkbmxswy) |
| 16:23.39 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 17:01.54 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:28.30 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-cmozizjymfmsenbj) |
| 18:59.43 | *** join/#asterisk-dev Navion (~Navion@rivendell/users/navion) |
| 19:00.42 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:11.29 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-ryqirdtkdupkxyph) |
| 19:43.01 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:54.00 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 19:54.30 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 20:11.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:11.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:05.14 | gtjoseph | cool, it's not often I get a bamboo email with a green SUCCESSFUL. :) |
| 21:12.24 | leifmadsen | jsmith: lol |
| 21:12.37 | leifmadsen | jsmith: someone said that on one of the news shows I was listening to and I was wondering wtf they were talking about :) |
| 21:12.38 | leifmadsen | now I know |
| 21:12.51 | jsmith | leifmadsen: :-) |
| 21:19.31 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 21:20.19 | Dovid | When using the announce option in meetme where does it play vm-msgsaved? I wasnt able to fidn that in the code. customer wants it to play something else. using 1.8.X |
| 21:27.23 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 21:27.23 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:28.50 | [TK]D-Fender | show us a call with it |
| 21:31.23 | [TK]D-Fender | oops, checkout time here... BBIAB |
| 21:34.24 | ipengineer | I am having an issue in 13 where restarting the asterisk services causes all device subscriptions to be lost. I dont remeber this being a problem in earlier versions of Asterisk. Is there a way to make subscriptions persist across a restart? I saw this issue on reviewboard and I am using PJSIP. Not sure if it is related to my problem or not⦠https://reviewboard.asterisk.org/r/4261/ |
| 21:35.53 | mjordan | that's persistent subscriptions, but not the last known device state |
| 21:36.10 | mjordan | Hm... although that's what you mentioned :-P |
| 21:36.44 | mjordan | ipengineer: you may want to try from the 13 branch |
| 21:36.49 | mjordan | as that patch will go into 13.2 |
| 21:37.34 | mjordan | Dovid: It is in app.c |
| 21:38.20 | mjordan | Dovid: app_meetme calls ast_record_review |
| 21:38.20 | Dovid | mjordan: Thanks. and it' a specific function that is called by both app_meetme and app_voicemail ? |
| 21:38.28 | Dovid | mjordan: Thanks |
| 21:38.29 | *** join/#asterisk-dev superscrat (~asanders@nat/digium/x-chnnwsgqwhacciww) |
| 21:38.56 | mjordan | interestingly enough, ast_record_review is only called by app_meetme. That being said, it is in the 'shared' stuff in app.c - which means you'll probably want to double check that modifying that file name in that location doesn't impact anything else you are using |
| 21:38.58 | ipengineer | mjordan: Right. The issue is anytime asterisk crashes (which is becoming less frequent!) or we have to restart due to my last open issue with stuck channels (very frequent) we have to reboot all 400 devices to get their BLF subscriptions to work again. |
| 21:39.38 | ipengineer | I can test that with branch tomorrow and report back if you think that will be of some value. |
| 21:39.47 | Dovid | to be safe I can create a patch that has ast_record_review_meetme and then change the message played |
| 21:43.17 | mjordan | ipengineer: I'd test with the branch, if not, let's get a log and an issue opened please |
| 21:43.25 | ipengineer | mjordan: Will do |
| 21:43.32 | mjordan | thanks! |
| 21:44.11 | ipengineer | mjordan: While I am thinking about it⦠Do you happen to know when this could be fixed? Within the next couple weeks/months/etc? I guess it is linked to an internal sprint. https://issues.asterisk.org/jira/browse/ASTERISK-24624 |
| 21:45.42 | gtjoseph | mjordan: ipengineer 4261 doesn't fix this specific issue. I just tested it. |
| 21:47.39 | ipengineer | Ok I will get a log together. What would be the best info to nail this down? pjsip debug with verbose output, register the phone, restart asterisk and keep verbose output and pjsip debug on? |
| 21:50.08 | gtjoseph | ipengineer: a 'database show subscription_persistence' from the cli would also help. |
| 21:52.46 | file | indeed |
| 21:52.55 | ipengineer | gtjoseph: So a very quick pass since I am fixing to walk out the door. On my dev box I ran that, it had 9 subscriptions. Once restarted it still showed 9 I ran the command again and it was at 0 |
| 21:53.29 | gtjoseph | hmmm |
| 21:53.30 | ipengineer | https://gist.github.com/zconkle/30512473511e3a013b7a |
| 21:53.40 | gtjoseph | ok, i'll take a look |
| 21:57.33 | ipengineer | I have got to run for a meeting.. I will jump back on here tomorrow to see what I can do to help get yâall more info |
| 21:57.41 | gtjoseph | no worries |
| 22:01.13 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:02.29 | gtjoseph | putnopvut: every time asterisk restarts it looks like astdb gets cleaned of subscription_persistence entries. Does something need to be configures specially for persistence? |
| 22:03.10 | file | shouldn't need to be |
| 22:03.28 | gtjoseph | hmmm. |
| 22:04.08 | Dovid | forgive my ignorance but what is the difdeence between include/asterisk/app.h and main/app.c ? |
| 22:04.28 | putnopvut | gtjoseph: nope, the astdb is intended to actually persist the subscriptions between loads. Now, if the subscriptions are past their expiration, then they'll get wiped on startup. |
| 22:04.59 | gtjoseph | looks like all mine expire immediately. :) |
| 22:05.51 | putnopvut | heh, I did some recent testing with MWI persistent subscriptions and had to patch res_pjsip_pubsub.c since it was leaving persisted subscriptions in the NULL state. I believe that fix has been committed to the 13 branch already though. |
| 22:06.03 | putnopvut | That was a "works for me" scenario, at least. |
| 22:06.10 | gtjoseph | putnopvut: yeah I have that applied |
| 22:06.35 | gtjoseph | putnopvut: if the subscription expires is it auto-deleted during normal operation? |
| 22:06.58 | putnopvut | Yes, PJSIP informs us that the subscription expired and we destroy it. |
| 22:07.02 | mjordan | Dovid: app.h is the header file that provides the declarations of functions accessible outside of some particular source file; app.c is the implementation of those declarations. (https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html) |
| 22:07.35 | file | I just did a core restart now and mine successfully restored |
| 22:07.37 | Dovid | mjordan: Thank you |
| 22:08.02 | file | same for a core stop now and a fresh start |
| 22:08.05 | gtjoseph | uh oh. i think it's a timezone thing |
| 22:08.23 | mjordan | everyone, look away! It's a heisenbug! |
| 22:08.54 | gtjoseph | my digium phone is creating expires = now |
| 22:10.13 | putnopvut | phones represent the expiration in relative terms, so I don't really understand that. For instance, a phone will say "Expires: 3600" to mean "expires in one hour" |
| 22:10.31 | gtjoseph | yeah, i just realized that. it's pubsub |
| 22:10.39 | gtjoseph | or the expires is = |
| 22:10.41 | putnopvut | But the persistent subscription will generate a timestamp for when the expiration is. |
| 22:10.42 | gtjoseph | 0 |
| 22:10.51 | putnopvut | ah, 0 means "unsubscribe" |
| 22:11.09 | gtjoseph | well, i'm still looking but the astdb says "expires":"1420582376" |
| 22:11.23 | gtjoseph | which was 20 minutes ago which is when the subscription was created |
| 22:11.55 | gtjoseph | well, expires says 600 |
| 22:12.09 | gtjoseph | i'm going to test again |
| 22:13.46 | gtjoseph | putnopvut: ok, so i did a core restart gracefully and there were no subscriptions... |
| 22:14.03 | gtjoseph | i did a reconfig all on my phone and saw the subscription |
| 22:14.22 | gtjoseph | with a expires: 600 and a expires of 10 monites from now |
| 22:14.32 | gtjoseph | then did a restart and the subscription disappeared |
| 22:18.26 | putnopvut | is looking at persistence code. |
| 22:19.06 | file | I'd rather see a debug log and SIP traffic before hypothesizing... |
| 22:20.11 | putnopvut | Yeah, I was just looking at expiration calculations to see if there was any inconsistency. Both creating and checking the expiration uses ast_tvnow(), so even time zone stuff shouldn't affect anything. |
| 22:20.27 | gtjoseph | i'm looking at the entry in the database which is the subscribe packet |
| 22:21.58 | gtjoseph | it looks correct |
| 22:27.03 | gtjoseph | putnopvut: are you ready for this... if I do a restart now, the subscription stay, if I do a restart gracefully, they don't. Something in the shutdown code is clearing them. |
| 22:27.17 | mjordan | hm. |
| 22:33.37 | putnopvut | ooh |
| 22:35.14 | Qwell | mjordan: FYI, wiki is sending out emails with a time set to like 8 hours ago. |
| 22:35.20 | putnopvut | gtjoseph: I might have an idea of what's up... |
| 22:35.38 | gtjoseph | ok |
| 22:35.51 | gtjoseph | is it sorcery/astdb related? |
| 22:36.14 | putnopvut | I think that on shutdown, the PBX code sends a message to extension state subscribers stating that the extension has been removed, and so we kill the subscriptions as a result. Killing the subscription kills the persistent subscription as well. |
| 22:36.27 | gtjoseph | ah |
| 22:38.14 | putnopvut | Emphasis on the word "might" btw :) |
| 22:42.46 | mjordan | Qwell: weird. |
| 22:42.51 | mjordan | Qwell: I'll take a look |
| 22:44.08 | mjordan | ew. Alembic got messy with those user_eq_phone backports. |
| 22:52.22 | russellb | backporting db migrations is complicated. |
| 23:21.20 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 23:21.20 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 23:22.56 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:22.56 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 23:22.56 | *** mode/#asterisk-dev [+o leifmadsen] by card.freenode.net |
| 23:26.50 | *** join/#asterisk-dev tonyclewis (sid6025@gateway/web/irccloud.com/x-psmjqgotyyqkpklo) |
| 23:28.35 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 23:28.35 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 23:32.42 | gtjoseph | putnopvut: looking at the subscription thing... the only time we don't want the subscription to delete is if subscription_persistence_remote is called at shutdown right? |
| 23:50.24 | putnopvut | gtjoseph: that sounds correct to me. |
| 23:50.49 | gtjoseph | so if I test for shutdown and not call ast_sorcery_delete, that should do it, right? |
| 23:51.03 | gtjoseph | rhetorical question... it does. |
| 23:53.06 | putnopvut | Yep that would work. |
| 23:53.45 | gtjoseph | ok, just need to test some more. |
| 23:54.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.50) |
| 23:55.40 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
