| 00:14.03 | *** join/#asterisk-dev newtonr_ (~newtonr@173-21-147-197.client.mchsi.com) |
| 00:14.03 | *** mode/#asterisk-dev [+o newtonr_] by ChanServ |
| 00:19.16 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:19.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 |
| 05:12.10 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-235-230.w90-32.abo.wanadoo.fr) |
| 05:59.15 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:49.45 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:51.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:11.13 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.40) |
| 07:25.24 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:49.03 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:53.37 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 10:24.47 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 12:41.26 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-kelfiebqiuyghmso) |
| 12:41.26 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:04.11 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:04.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:13.35 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-63-12.dialup.adsl.anteldata.net.uy) |
| 13:18.36 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-edlvjcnsuythdcuc) |
| 13:18.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:35.33 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 13:42.06 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:44.53 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:44.53 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:48.27 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 13:48.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:56.03 | tsearle | hello, I just noticed that dtmf_mode=auto seems to have been fully dropped in pjsip |
| 13:56.31 | tsearle | is there a reason for this? and if so is there a way to get the same effect? |
| 13:58.08 | file | noone ever implemented it, I don't think there's anything equivalent currently |
| 13:58.41 | tsearle | ok |
| 13:58.50 | tsearle | but there is nobody philosophically against it right? |
| 13:58.59 | file | I don't think so |
| 13:59.09 | tsearle | ok, so then it can be implemented and pushed upstream |
| 13:59.16 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 14:08.17 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 14:16.27 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dzvuxxefgubdpgwl) |
| 14:16.27 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:26.36 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-zonjgyixyqolnktv) |
| 14:26.36 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:33.51 | cresl1n | Question |
| 14:34.02 | cresl1n | https://gerrit.asterisk.org/#/c/5484/3/res/res_pjsip_dialog_info_body_generator.c |
| 14:34.34 | cresl1n | well, that code review in general, not just that portion of it |
| 14:35.18 | cresl1n | the new behavior in https://gerrit.asterisk.org/#/c/5484/3/res/res_pjsip/presence_xml.c assumes a behavior in chan_sip which is optional right now |
| 14:35.33 | cresl1n | from chan_sip: |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:35.34 | cresl1n | <PROTECTED> |
| 14:36.37 | cresl1n | should we let this go in as a new default behavior? |
| 14:39.38 | cresl1n | Also, for https://gerrit.asterisk.org/#/c/5484/3/res/res_pjsip_dialog_info_body_generator.c |
| 14:39.48 | cresl1n | shouldn't this go into the other botdy generators as well? |
| 14:39.54 | cresl1n | s/botdy/body/ |
| 14:40.07 | cresl1n | if we decided to accept it |
| 14:41.02 | file | hum |
| 14:41.18 | file | a new default behavior in all branches? |
| 14:42.14 | cresl1n | that's my beef |
| 14:42.35 | cresl1n | seems problematic |
| 14:42.41 | file | I'm not particularly fond of changes like that in a branch |
| 14:42.45 | cresl1n | me too |
| 14:43.14 | cresl1n | not without the behavior being flagged at the very least |
| 14:43.19 | cresl1n | (behind a flag) |
| 14:43.21 | file | aye |
| 14:53.03 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-cpmqvisvwehzxudx) |
| 15:22.17 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 15:37.53 | rmudgett | seanbright: Have you noticed that you get a warning for nearly every sound prompt now? The coded/format patch you recently did gives a warning for the last partial frame in the file. |
| 15:39.00 | rmudgett | Probably should reduce the level to a debug message. |
| 16:00.10 | file | gtjoseph: where is the current infrastructure configuration kept? |
| 16:00.32 | gtjoseph | From a source perspective? |
| 16:00.36 | file | yes |
| 16:00.44 | gtjoseph | in the jenkins2 branch of the infrastructure project |
| 16:00.57 | file | should that become master? |
| 16:01.21 | gtjoseph | yeah it's probably a good time |
| 16:01.40 | gtjoseph | will need a config change to rename it though since jenkins pulls from thjat branch |
| 16:01.49 | gtjoseph | i can do it tonight |
| 16:02.25 | file | k |
| 16:02.30 | gtjoseph | it's also on my list to write up the new stuff and post on asterisk-dev and the public wiki |
| 16:02.51 | gtjoseph | i should be able to do that tomorrow |
| 16:25.31 | seanbright | rmudgett: partial frames? which files? |
| 16:25.41 | seanbright | sounds like the prompts are broken |
| 16:26.38 | rmudgett | Just about any sound prompt file. They don't contain exact 20ms increments of samples |
| 16:26.45 | seanbright | huh... |
| 16:26.47 | seanbright | ok |
| 16:27.03 | rmudgett | Should just demote the warning to a debug message. |
| 16:27.09 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00b5b97a93f3129615.ipv6.abo.wanadoo.fr) |
| 16:27.19 | seanbright | yes, you said that |
| 16:27.20 | seanbright | :-) |
| 16:28.10 | seanbright | i guess i should have tested my patch before submitting |
| 16:46.43 | seanbright | so if there is less than a frames worth of data we just throw it away? that seems wrong |
| 16:47.25 | rmudgett | We throw it away now we used to send a partial frame. |
| 16:47.43 | rmudgett | Sending a partial frame seems wrong anyway. |
| 16:48.00 | seanbright | you could silence pad |
| 16:48.03 | rmudgett | It's also only 20ms of sound. |
| 16:48.11 | seanbright | is it always 20ms? |
| 16:48.47 | seanbright | if it's always 20ms i agree with you |
| 16:48.48 | rmudgett | Padding would be codec specific if you could. |
| 16:48.52 | seanbright | right |
| 16:50.17 | rmudgett | G.723 reads frames from the file. ulaw/alaw reads the specified number of samples into a buffer. |
| 16:50.29 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-fwfkbytflhcipbdd) |
| 16:53.19 | rmudgett | I'm not sure if the frame size is really specified as a parameter to the file read. Not all codecs know how much to read out of the file. (opus for one) |
| 18:09.42 | seanbright | do you guys use some git magic to clean up your feature branches? |
| 18:09.58 | seanbright | or is 'git branch -d' just part of your manual workflow? |
| 18:10.08 | cresl1n | that's usually what I do for local branches |
| 18:11.32 | file | 'tis part of my normal workflow |
| 18:12.43 | seanbright | kk |
| 18:13.11 | seanbright | my monthly housekeeping is getting tedious |
| 18:13.28 | gtjoseph | i even have a little script that deletes all of my stale "review/" branches. |
| 18:19.13 | seanbright | fancy |
| 18:19.29 | seanbright | i might just write a script to delete all branches i haven't committed to in 30 days |
| 18:19.38 | seanbright | i'm sure that will end up screwing me though |
| 18:20.34 | coreyfarrell | I use 'git review -f' then if I need to update the review I just download it again |
| 19:13.56 | seanbright | what can we do about CaptainPants? |
| 19:14.02 | seanbright | and by "we" i mean "you" |
| 19:15.57 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-246-146.w2-14.abo.wanadoo.fr) |
| 19:23.26 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-246-146.w2-14.abo.wanadoo.fr) |
| 19:45.50 | gtjoseph | seanbright: CaptainPants is on my punch list. |
| 19:51.30 | seanbright | gtjoseph: well, if he's not back soon, you're on MY punch list |
| 19:51.33 | seanbright | :P |
| 19:52.31 | gtjoseph | checks about the witless protection program |
| 19:53.09 | dan_j | Hi. Any idea which release this will be included and when the release will land? https://gerrit.asterisk.org/#/c/5341 |
| 19:54.05 | gtjoseph | shoul dbe the next release |
| 19:54.38 | gtjoseph | i would say end of may |
| 19:55.12 | dan_j | thanks |
| 19:55.22 | gtjoseph | seanbright: the other thing on my punch list is that if you revise a commit message gerrit removed the verified +1 but jenkins ignores non-code changes. |
| 19:55.36 | gtjoseph | so the verified never goes back to +1. |
| 19:56.05 | rmudgett | It can tell the difference? |
| 19:58.23 | gtjoseph | yep |
| 19:58.32 | gtjoseph | i thought i was being smart and set the flag. |
| 19:58.51 | gtjoseph | i was hoping to avoind unneeded builds |
| 19:59.22 | gtjoseph | really heads to lunch now |
| 20:04.40 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:32.08 | file | gtjoseph: I did a +2 on a testsuite change and it also failed to do ... anything |
| 20:32.31 | gtjoseph | hmmm |
| 20:33.45 | gtjoseph | I may have forgot to enable merges on that project. will look in a bit. |
| 20:39.39 | gtjoseph | file: yeah there's no gate to run for testsuite. I can just add a job that triggers on a CR +2 and responds with a V +2. That'll trigger the merge. |
| 20:40.27 | file | I forget what it used to do |
| 20:41.07 | gtjoseph | it was something unusefull. |
| 20:41.19 | gtjoseph | tthat's why i didn't copy it over. |
| 20:41.24 | gtjoseph | i'll double check though |
| 20:43.20 | seanbright | i really wish we could use anonymous functions |
| 20:43.27 | seanbright | stupid executable stack |
| 20:43.34 | gtjoseph | in C ? |
| 20:43.39 | seanbright | yes |
| 20:43.41 | seanbright | it's a gcc extension |
| 20:43.53 | gtjoseph | closures FTW |
| 20:44.16 | seanbright | https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html |
| 20:44.19 | gtjoseph | is it supported by clang? and how far back is it supported? |
| 20:44.34 | seanbright | not sure |
| 20:44.52 | seanbright | we switched a lot of stuff over to them, and then had to switch them back because they require the stack to be executable |
| 20:45.03 | seanbright | which apparently is "bad" for "security" |
| 20:45.07 | seanbright | or some other nonsense |
| 20:46.17 | gtjoseph | i can also imagine running out of stack space if folks aren't careful about the size of the functions |
| 20:48.08 | seanbright | rewrites asterisk in node |
| 20:48.22 | file | seanbright: god no |
| 20:48.28 | file | no, just no, no no no |
| 20:48.32 | seanbright | heh |
| 20:48.37 | gtjoseph | just think. no threading problems :) |
| 20:49.28 | gtjoseph | file: all the testsuite gate did was run the unit tests again, which is what the check job did. |
| 20:49.50 | file | k |
| 20:53.14 | gtjoseph | ok, there's a gate-testsuite job now |
| 21:01.01 | kharwell | regarding stream echo app and requesting renegotiation to 'n' streams - what 'n' stream types do we create? |
| 21:01.12 | cresl1n | Video streams |
| 21:02.20 | file | kharwell: remember - video killed the radio star |
| 21:02.23 | file | this phrase will guide you |
| 21:02.28 | cresl1n | will it though? |
| 21:02.46 | file | cresl1n: doesn't matter - there's no warranty or return period so even if it doesn't pfft |
| 21:05.29 | kharwell | okay so video only echo. So if a stream comes in with only audio and in the dialplan something like: STREAM_ECHO(4) that will what? Create a new topology with 4 video streams and then send a request back to see if the initiator can handle that? |
| 21:05.52 | file | yes |
| 21:08.19 | kharwell | and the renegotiation takes place through SIP? Is the mechanism already in place for that? I'm assuming after creating the new topology the app will then request a topology update on the channel requesting it to be set to the new topology. I don't recall that code being written yet? The update/renegotiation? |
| 21:08.35 | cresl1n | the topology change request should start that process |
| 21:08.52 | cresl1n | you wait for it to be confirmed by the channel driver |
| 21:09.09 | cresl1n | I think there's a unit test for it |
| 21:09.21 | cresl1n | that show's how it works from a channel api perspective |
| 21:09.34 | kharwell | Right okay that is what I was thinking. I don't think that has been written yet though? Maybe it has been or is that part of what I need to do? |
| 21:09.34 | cresl1n | Richard's working on the pjsip parts of it so that it works with that channel driver |
| 21:09.40 | kharwell | aaah okay |
| 21:09.50 | cresl1n | but from an Asterisk API perspective it should be about there |
| 21:09.54 | cresl1n | (channel API rather) |
| 21:10.25 | kharwell | ya the request change stuff is there and the frame indicators are in place for the events. |
| 21:10.58 | kharwell | I wasn't sure about the actual channel driver side, but sounds like I don't need to worry with that |
| 21:11.14 | cresl1n | yeah, it should be handled by the code Richard's working on |
| 21:16.39 | file | indeed |
| 21:16.46 | file | the interface exists, that's all you have to code to |
| 21:22.01 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-13-160.dialup.adsl.anteldata.net.uy) |
| 22:32.58 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-13-160.dialup.adsl.anteldata.net.uy) |
| 23:15.49 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dzvuxxefgubdpgwl) |
| 23:30.54 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:30.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |