| 00:49.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 01:41.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 01:47.27 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 01:47.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:41.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:16.15 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 05:41.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:19.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:37.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:38.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:45.35 | *** join/#asterisk-dev oej (~Adium@host86-148-69-26.range86-148.btcentralplus.com) |
| 06:45.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:30.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a06f:c885:889f:73f4) |
| 07:54.46 | *** join/#asterisk-dev oej (~Adium@host86-148-69-26.range86-148.btcentralplus.com) |
| 07:54.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:10.56 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:39.18 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 09:13.20 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 10:06.16 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:06.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:54.51 | *** join/#asterisk-dev sammoers (~root@2.191.126.75) |
| 10:56.38 | sammoers | Hi, I have a question in creating a custom module |
| 11:18.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 12:27.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:40.13 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:50.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 13:04.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 13:19.40 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 13:25.33 | *** join/#asterisk-dev etc5000 (4d7f91c2@gateway/web/freenode/ip.77.127.145.194) |
| 13:34.47 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 13:34.47 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:36.31 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-141-181.user.veloxzone.com.br) |
| 13:42.17 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 14:01.00 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:01.21 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jbuyrxctgkybyngd) |
| 14:02.52 | etc5000 | Hi. I have Linux/Asterisk11.8 and a SoC that is capable to do DSP processing and RTP/SRTP streaming. I have full sources of the linux kernel-level driver and I know how to handle the chip from userspace. |
| 14:03.07 | etc5000 | The problem is how to attach the driver API to Asterisk. |
| 14:03.16 | etc5000 | What is the better way? I tried to look at DAHDI but it seems not be applicable to my case. |
| 14:03.24 | etc5000 | Maybe I must write own RTP engine on base of the res/res_rtp_asterisk.c where I change network/socket operations to ioctl with my chip? |
| 14:03.39 | opticron | is this a DSP that does media codec conversion? |
| 14:03.55 | etc5000 | yes |
| 14:04.16 | etc5000 | it is AudioCodes 5014 |
| 14:04.34 | opticron | take a look in codecs |
| 14:04.41 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 14:04.41 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 14:04.42 | etc5000 | I asked AudioCodes but they answered that they have channel driver for 1.6 Asterisk only |
| 14:04.43 | opticron | you'll likely want to write a codec module |
| 14:04.59 | opticron | oh... |
| 14:05.23 | opticron | you might be able to port the channel driver to newer versions of asterisk |
| 14:05.35 | etc5000 | It is I am trying now |
| 14:05.47 | opticron | but if it's only a DSP, I don't know why it would need a whole channel driver |
| 14:06.04 | etc5000 | but the RTP stack is completely different between the old A and the current |
| 14:06.07 | opticron | I'm not that familiar with audiocodes devices |
| 14:07.58 | opticron | ok, it's a network DSP |
| 14:08.16 | opticron | that makes things more complicated and would explain why it needs a channel driver |
| 14:08.40 | opticron | that said, porting the channel driver up to 1.8 shouldn't be too bad |
| 14:08.53 | opticron | most of the changes in the RTP stack were toward modularization |
| 14:10.03 | opticron | if you want some examples of how things were changed, look at how the existing channel drivers were modified when the API changes took place |
| 14:15.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 14:16.12 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@212.34.52.66) |
| 14:16.54 | etc5000 | I examined these changes. I worked on this channel driver for two weeks, and realized that I need to modify RTP engine again as it was done in the old Asterisk. So I have the choice: either write own RTP engine or modify/patch current res/res_rtp_asterisk.c |
| 14:24.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:24.05 | opticron | I wouldn't recommend writing your own RTP engine for this since it would still have to conform to the RTP engine API |
| 14:24.33 | opticron | unless the channel driver was already implementing its own RTP engine... |
| 14:28.21 | etc5000 | No, the old version hadn't own RTP engine. Authors of it modified *new and *write functions to implement operations with chip instead of network socket. But this way requires full access to RTP engine structures and therefore I must modify one of the RTP core files since the engine functions are defined as static and invisible outside |
| 14:28.37 | etc5000 | Okay, I'll go this way |
| 14:28.47 | etc5000 | Thank you |
| 14:31.32 | etc5000 | The thing is wondering me. Do really no network DSP drivers exist already? So I would take them as a template. |
| 14:33.48 | opticron | so the answer is yes, you will need to write a RTP engine to interface with the chip |
| 14:39.12 | opticron | as far as RTP engines for network DSP chips, I've heard of them but never seen one |
| 14:39.21 | opticron | maybe someone else in here is more familiar with the subject |
| 14:39.43 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:16.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:32.12 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:32.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ejwyoqvtlillrvtr) |
| 15:32.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:32.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.219) |
| 16:19.24 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:37.33 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-dwlfmcgcporhksax) |
| 16:38.02 | jrose_atDigium | mjordan/jcolp: So wdoekes was saying I should have the same privacy rules going for P-Asserted-Identity get applied to Remote-Party-ID (at least in trunk). Is this something I should deal with in 1.8? Currently there is no expectation of privacy with Remote-Party-ID going by the code. |
| 16:38.02 | jrose_atDigium | The review he linked provides privacy for it though, so it's not something that is hard to do... I'm just worried about it being a potential cause of regressions. |
| 16:38.13 | jrose_atDigium | file: ^ |
| 16:38.34 | mjordan | jrose_atDigium: well, there's no risk for regression really if it is only enabled when an option is set |
| 16:38.46 | jrose_atDigium | mjordan: In this case the default behavior would change |
| 16:38.50 | mjordan | jrose_atDigium: and this is why you should also have a test for the behaviour before the patch, and for after. |
| 16:38.52 | jrose_atDigium | Because the default is to not trust. |
| 16:39.13 | mjordan | jrose_atDigium: at no point should the default be changed. If anything it should be "don't trust, and also change how we send it if this is enabled" |
| 16:39.15 | file | the behavior by default has to match the way it was |
| 16:39.32 | jrose_atDigium | Ok, so I should probably just leave Remote Party ID alone then? |
| 16:40.01 | mjordan | that's not what I said :-) If sendrpid needs an additional setting (sendrpid=rpid,really_hide_things) that's fine |
| 16:40.51 | jrose_atDigium | ok, so throw another option into the mix for it that defaults to non-private |
| 16:42.36 | mjordan | jrose_atDigium: here's where I'd start. Write tests that verify the behavior today. That behavior doesn't change. |
| 16:42.54 | mjordan | jrose_atDigium: then, move towards making it so that we actually respect the RFC with the correct application of whatever parameters are needed. |
| 16:43.14 | mjordan | jrose_atDigium: I think if we have tests that verify how Asterisk currently sends that information, we'll be pretty well covered. |
| 16:43.27 | jrose_atDigium | alrighty then |
| 16:43.33 | jrose_atDigium | I'll do the tests first |
| 16:44.12 | mjordan | TDD FTW when you have a risk of breaking stuff and things |
| 16:44.36 | file | mjordan, I live to break ALL THE THINGS |
| 16:45.19 | mjordan | I live to cry about the broken things. Do I win? |
| 17:25.36 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 17:32.09 | jameswf | changes mjordan's diaper and gives him a bottle |
| 17:32.15 | jameswf | carry on :) |
| 18:03.52 | *** join/#asterisk-dev ipengineer_ (~zconkle@static-71-252-134-64.dllstx.fios.verizon.net) |
| 18:42.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 18:45.37 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:45.37 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:48.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 18:55.13 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 18:55.13 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:27.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 19:29.59 | *** join/#asterisk-dev otherwis_ (~otherwise@172.56.11.219) |
| 19:31.02 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-64.dllstx.fios.verizon.net) |
| 19:46.21 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 20:23.44 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 20:39.56 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 21:05.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:35.37 | coreyf1513 | does asterisk participate in coverity scan? who should I talk to about gaining access to current scan reports? |
| 21:37.39 | file | the answer is no |
| 21:40.02 | coreyf1513 | are you saying it just isn't being done or that it isn't wanted? |
| 21:40.39 | file | isn't being done afaik |
| 21:41.19 | Qwell | it was done at one point, wasn't it? |
| 21:41.52 | Qwell | There was a pretty large effort to get some of the things resolved. |
| 21:42.32 | Qwell | I retract my statement. |
| 21:43.19 | coreyf1513 | some years ago there were a few tickets based on coverity results |
| 21:43.59 | pabelanger | IIRC russellb had access to a report |
| 21:59.37 | jrose_atDigium | I don't think Russellb is at liberty to give that out. |
| 22:04.27 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:04.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:16.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 22:22.56 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:46.07 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jbuyrxctgkybyngd) |
| 23:12.17 | mjordan | coreyf1513: yeah, so... the Coverity report that was run on Asterisk last time was, completely unknowingly, not supposed to happen. It was an honest "whoops, shouldn't have done that". No harm, no foul - but also unlikely to happen again. |