| 00:19.05 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 00:19.05 | *** 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:30.32 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-240-195.try.wideopenwest.com) |
| 02:30.32 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 04:38.24 | *** join/#asterisk-dev joshelson (~joshelson@l136.denver.dsl.forethought.net) |
| 06:53.19 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:53.42 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:54.16 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:55.19 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:55.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:00.07 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:02.01 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:20.16 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 10:03.10 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 11:10.29 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:06.43 | tsearle | hello all |
| 12:06.51 | tsearle | ref https://gerrit.asterisk.org/#/c/5909/ |
| 12:07.07 | tsearle | richard Mudget suggests invoking session refresh |
| 12:07.31 | tsearle | but in my use case I see changing the dtmf mode before call establishment so refresh isn't required |
| 12:08.15 | tsearle | so I was thinking, should I test if dialog is established & then send refresh if established |
| 12:08.16 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:08.16 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:08.33 | tsearle | or I can make the command simply fail channel is in an established state |
| 12:10.20 | file | I don't think having it fail is good from a user experience perspective, it should send a refresh if it is needed |
| 12:10.23 | file | seanbright: !!! |
| 12:10.57 | seanbright | ohai |
| 12:11.06 | file | seanbright: welcome to Monday |
| 12:11.12 | seanbright | thanks. it's great to be here. |
| 12:11.26 | tsearle | waves to seanbright |
| 13:10.55 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:40.24 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-sjkeweigwpskurkn) |
| 13:40.24 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:42.09 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 13:42.09 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 13:47.13 | tsearle | is it safe to call ast_sip_push_task_synchronous while having the channel lock? or should I only invoke it after an unlocking the channel? |
| 13:47.53 | gtjoseph | by itself, should be fine |
| 13:48.02 | gtjoseph | does the tasdk require the channel lock?> |
| 13:48.49 | tsearle | yeah, it's pjsip_acf_dtmf_mode_write, and the code review says I need to lock before changing the dtmf mode of a channel |
| 13:49.00 | tsearle | now at the end I want to send a session refresh if needed |
| 13:49.09 | tsearle | just wondering if I should unlock before or after |
| 13:49.46 | file | it shouldn't be held while calling it, if a task preceeds it that requires the channel lock then it'll encounter a deadlock |
| 13:54.30 | tsearle | ok, works for me |
| 13:57.06 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 13:57.06 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 14:03.40 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-bklondlgoymbbtzm) |
| 14:03.40 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:05.01 | tsearle | https://gerrit.asterisk.org/#/c/5909/10/channels/pjsip/include/dialplan_functions.h@113 |
| 14:05.18 | tsearle | anybody know what's changed on 113? it appears to be some sort of whitespace change |
| 14:12.24 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:15.18 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-urpoixidwgvxuzoe) |
| 14:17.29 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:21.41 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-jvtyfzqbgoeaoztk) |
| 14:21.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:24.07 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-ppsdfrlnddpfcjsj) |
| 14:24.07 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:24.40 | tsearle | nvm |
| 14:33.10 | file | nods to bford and others |
| 14:40.58 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:40.58 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:41.09 | tsearle | waves at cresl1n |
| 14:41.28 | cresl1n | !!!!! |
| 14:41.33 | cresl1n | tsearle: !!!! |
| 14:41.38 | tsearle | :-) |
| 14:41.59 | tsearle | how's it going? |
| 14:44.06 | cresl1n | good! |
| 14:44.08 | cresl1n | thanks for asking |
| 14:44.12 | cresl1n | how're things for you? |
| 14:44.52 | tsearle | allright, getting ready to be what I hope to be my last gerrit push for 5909 |
| 14:50.31 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-iwaudfwpwckkiseq) |
| 14:50.31 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:16.51 | rmudgett | file: gtjoseph The app_queue QueueStatus priority patch missed the 13.17.0 cutoff so its CHANGES needs to be updated |
| 15:17.11 | gtjoseph | yeha i'll fix it in a minute |
| 15:18.59 | gtjoseph | @rmudgett: done |
| 15:19.00 | rmudgett | Would we want to wait until Torrey Searle's patch goes in since there is going to be a merge conflict because of it. |
| 15:19.36 | gtjoseph | yeah probably |
| 15:20.33 | rmudgett | It's also the same with 14.6 |
| 15:27.21 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:31.14 | gtjoseph | @rmudgett: fixed |
| 15:34.54 | coreyfarrell | I have a custom module that uses config_options.h, I need a timelen config value (like ast_app_parse_timelen). is there a way to make it so I pass an enum ast_timelen to aco_option_register_custom or would the custom handler need to be hard-coded to a specific default time unit? |
| 15:35.37 | gtjoseph | hasn't looked at the aco code in years |
| 15:36.23 | file | hasn't either |
| 15:38.12 | coreyfarrell | is aco a thing of yesteryear? should I be using sorcery instead? |
| 15:38.12 | gtjoseph | sorcery if you can |
| 15:39.19 | file | sorcery uses aco underneath mind you... so some of the same limitations apply |
| 15:39.24 | gtjoseph | If it's something simple, I'd go for the base ast_config_load stuff. Anything more complex, I'd go straignt to sorcery |
| 15:40.21 | coreyfarrell | it's simple but I used aco over ast_config_load to get atomic reloads.. |
| 15:42.39 | gtjoseph | You could write an aco handler for enums. :) |
| 15:42.58 | gtjoseph | a generic one that is. |
| 15:44.52 | coreyfarrell | the enum ast_timelen determines default parsing of a bare number, TIMELEN_SECONDS would tell it that "5" is seconds. the actual result is an integer (number of milliseconds). |
| 15:45.19 | gtjoseph | ah |
| 15:46.42 | gtjoseph | basically you want to tell aco to multiply the value by 1000 if there's no qualifier right? |
| 15:48.55 | coreyfarrell | well the ACO handler_fn would pass the appropriate enum value to ast_app_parse_timelen (TIMELEN_SECONDS, TIMELEN_MILLISECONDS, etc) |
| 15:49.07 | gtjoseph | I think you're on your own |
| 16:53.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 16:57.45 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.167) |
| 17:00.43 | seanbright | i would like to have a PIDF discussion |
| 17:01.00 | file | uh oh |
| 17:01.37 | seanbright | https://tools.ietf.org/html/rfc3863#section-4.1.4 |
| 17:02.25 | seanbright | my reading of that, ignoring the fact that it is discussing "INSTANT MESSAGES," is that if the contact is available, we should be 'open' |
| 17:02.25 | seanbright | and 'closed' otherwise |
| 17:02.33 | seanbright | so in terms of device state, everything but "unavailable" should be "open" |
| 17:04.52 | seanbright | https://github.com/asterisk/asterisk/blob/13/res/res_pjsip/presence_xml.c#L84 |
| 17:05.25 | file | I think the use of "available" is where it gets complicated... |
| 17:05.32 | file | if a device is in use, are they available or not? |
| 17:05.53 | file | to me if the end result mirrors chan_sip, then we're no better off and that behavior has existed for quite a long time |
| 17:06.21 | seanbright | well, just because it has existed for a long time doesn't mean it is correct |
| 17:06.36 | seanbright | i am primarily basing my observations on the way that bria is behaving |
| 17:06.49 | file | you are factually correct, however it is behavior that end users have seen for countless years from chan_sip |
| 17:07.06 | seanbright | well they are free to continue using chan_sip |
| 17:07.16 | seanbright | well, let me rephrase |
| 17:07.49 | seanbright | how do we move towards correct behavior over backwards compatability? |
| 17:07.58 | file | if you believe that it is incorrect though and the logic makes sense then that's fine |
| 17:08.13 | file | it's just the fact that cramming device state into these messages gets a bit... complicated due to interpretation |
| 17:08.27 | seanbright | yes, i agree |
| 17:09.51 | seanbright | so for https://gerrit.asterisk.org/#/c/5749/ |
| 17:10.11 | seanbright | dan_j: ^^^ |
| 17:10.35 | seanbright | if the commit message is updated to say something along the lines of "feature parity with chan_sip" |
| 17:10.43 | seanbright | i would remove my -1 |
| 17:11.01 | seanbright | but if we're going for correctness, than this isn't the right patch |
| 17:11.38 | seanbright | given that dan_j's bandwidth might be limited, i may take a crack at fixing. |
| 17:12.01 | seanbright | file: do you envision the need for some kind of configuration to enable/disable correct behavior? |
| 17:12.25 | file | hum, my gut says probably not? |
| 17:13.26 | seanbright | i agree with your gut |
| 17:28.26 | *** join/#asterisk-dev joshelson (~joshelson@c-73-34-214-163.hsd1.co.comcast.net) |
| 17:48.22 | *** join/#asterisk-dev joshelson (~joshelson@c-73-34-214-163.hsd1.co.comcast.net) |
| 17:56.11 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-lmrvclhxsokfkszw) |
| 17:56.11 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:25.47 | *** join/#asterisk-dev tsearle (~torrey@2a02:2788:1004:636:aeb5:7dff:feca:81d6) |
| 19:35.08 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 19:35.08 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 19:53.50 | dan_j | seanbright: whats up? |
| 19:55.25 | dan_j | Im planning on finishing off that code on thursday/friday. But struggling with the testsuite test modifications. |
| 19:56.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 19:56.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:04.33 | seanbright | dan_j: should all be in your scrollback |
| 20:04.38 | seanbright | https://pastebin.com/raw/CZABUugL |
| 20:06.08 | dan_j | Yep. It was a mistake to leave 'onhold' as 'closed'. |
| 20:08.25 | seanbright | and AST_EXTENSION_BUSY as well it appears |
| 20:08.39 | seanbright | at least according to my reading of RFC3863 |
| 20:11.26 | seanbright | and anywhere we are setting pidfnote to "On the phone" |
| 20:11.38 | seanbright | we should set pidfstate to "on-the-phone" instead of "busy" |
| 20:12.03 | seanbright | "busy" in rpid land does not mean "busy" in the phone-line sense |
| 21:07.15 | dan_j | Ill come back to this on thursday when im sitting in front of bria and asterisk code. |
| 21:28.24 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:28.24 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:28.57 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:28.57 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:43.06 | tm1000 | Hey all, I'm getting this error using PJSIP and Websokets: Rx buffer overflow (PJSIP_ERXOVERFLOW) [code 171062] |
| 21:43.12 | tm1000 | I found this post. https://stackoverflow.com/questions/39275328/asterisk-13-10-pjsip-webrtc-rx-buffer-overflow-pjsip-erxoverflow |
| 21:43.25 | tm1000 | I dont want to recompile pjproject... is there anything better I can do?? |
| 21:45.28 | tm1000 | http://lists.digium.com/pipermail/asterisk-users/2016-March/288789.html |
| 21:45.32 | tm1000 | gtjoseph: ^? |
| 21:45.45 | gtjoseph | looks |
| 21:46.11 | tm1000 | I pinged you because it looks like someone referenced something you might have done in bundled pjsip (which we use) |
| 21:46.45 | file | it has to be recompiled (and Asterisk too), PJSIP has a fixed size buffer for packets |
| 21:46.52 | gtjoseph | exactly |
| 21:47.02 | gtjoseph | we've upped it a few trimes for webrtc but need to again |
| 21:47.23 | tm1000 | yeah I thought maybe it wasn't updated but basically you are saying I need to go even higher |
| 21:47.27 | tm1000 | like to 11 instead of 10 |
| 21:47.31 | gtjoseph | but we're also trying to think of a way to make it dynamic so we don't have to continue to increate the fixed buffer |
| 21:47.43 | gtjoseph | yep |
| 21:47.55 | tm1000 | which https://github.com/asterisk/asterisk/tree/d2b32cd00938ed2717565c14395f10cc90875a14/third-party/pjproject/patches is it in |
| 21:48.08 | tm1000 | Content-Length: 10576 |
| 21:48.12 | tm1000 | for us at least |
| 21:48.24 | file | config_site.h |
| 21:48.24 | gtjoseph | it's in config_site.h |
| 21:48.32 | gtjoseph | currently 6000 |
| 21:49.03 | tm1000 | yup found it |
| 21:49.04 | gtjoseph | go to 16K and see how that works :) |
| 21:49.17 | tm1000 | I think we will end up patching your patch |
| 21:49.21 | tm1000 | PATCH ALL THE THINGS |
| 21:50.15 | tm1000 | gtjoseph: file could this ever be an issue in chansip as well (not through the pjproject library) but are there limits like this |
| 21:50.20 | gtjoseph | if i get a few spare minutes in teh next few weeks, i'll add the ability to provide a custom config_site.h that doesbn't need to be checked into the source tree |
| 21:50.40 | gtjoseph | disavows all knowledge of chan_sip |
| 21:50.44 | tm1000 | lol |
| 21:51.27 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 21:51.35 | file | chan_sip has a limit of like 65k |
| 21:52.27 | file | checks |
| 21:53.02 | file | websockets have a fixed max size of 32k actually, so that'd be the limit on chan_sip I do believe |
| 21:54.05 | tm1000 | nice |
| 21:54.09 | tm1000 | well 16k it is for now |
| 21:54.12 | tm1000 | (for us) |
| 22:56.27 | coreyfarrell | gtjoseph: not sure if you're the person to tell, but it looks like the gerrit <-> jira connector failed at some point during the 13.16 - 13.17 cycle. I just manually closed ASTERISK-27100. |
| 22:57.12 | gtjoseph | hmmm |
| 22:57.32 | file | yes |
| 22:57.55 | gtjoseph | does it have a target release? |
| 22:58.38 | gtjoseph | I know a bunch of others worked |
| 22:58.49 | coreyfarrell | no, but it's listed on http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13.17.0-rc1-summary.html under "list of all open issues from the issue tracker that were referenced by changes that went into this release" |
| 22:59.58 | gtjoseph | I'm trying to remember if I had to dreary the script at some point |
| 22:59.58 | gtjoseph | restart |
| 23:04.19 | rmudgett | coreyfarrell: JIRA issues have to be manually closed for the time being. It got broke when we updated gerrit. |
| 23:05.26 | file | they rewrote the plugin and it became... not great |
| 23:07.18 | coreyfarrell | fun |
| 23:07.23 | gtjoseph | yeah i forgot it's the gerri tplugin not the release scripts that close the issues. |
| 23:07.41 | gtjoseph | we have an internal issue open to look at it |
| 23:08.45 | coreyfarrell | cool.. |
| 23:11.44 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:8422:6d4d:e1c8:679d) |
| 23:11.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:12.03 | coreyfarrell | unrelated question, does anyone have a suggestion for how to make a dialplan app that will wait for a signal from AMI? |
| 23:14.04 | coreyfarrell | so the channel would run the app which would spawn an AMI event, the management server would run an AMI command to acknowledge the channel, then the wait app would set a status var to success and exit. |
| 23:20.34 | rmudgett | You sort of get that effect implicitly by doing AsyncAGI. |
| 23:25.07 | coreyfarrell | hmm I'll check it out.. |
| 23:31.37 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-bklondlgoymbbtzm) |
| 23:58.21 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 23:58.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |