| 02:33.02 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 02:54.49 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 02:54.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:08.33 | tzanger | any insights on how to debug why asterisk DSP is not getting engaged on a DAHDI channel? |
| 03:08.50 | tzanger | DTMF detection isn't occuring (my hardware has no DTMF detection capability) |
| 03:08.55 | tzanger | DAHDI_FLAG_DTMF is not set |
| 03:09.07 | tzanger | I do have a loadzone/tonezone |
| 04:04.56 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 04:04.56 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 05:11.04 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:11.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:21.13 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:21.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:25.22 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 05:25.22 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 05:34.10 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 05:34.10 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:03.40 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 06:03.40 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 07:52.25 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:52.26 | schmidts | good morning |
| 08:01.09 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:04.51 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:34.50 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:34.50 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:45.51 | luka12345 | hi guys |
| 09:46.11 | luka12345 | i'm developing a new channel driver for embedded board |
| 09:46.25 | luka12345 | i have managed to compile and load it |
| 09:46.31 | luka12345 | only minimal stuff for now |
| 09:47.02 | luka12345 | i was wondering do you know any good tutorials or pointers when developing a new channel? |
| 11:12.56 | schmidts | luka12345 as usual doxygen is a good point to start but imho there is no real tutorial about developing a new channel |
| 11:35.46 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:35.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:58.18 | snuff-home | there are some 'simpler' channels i just can't remember :) |
| 12:10.04 | luka12345 | i have been looking at the other code |
| 12:11.00 | luka12345 | only thing that i dont how to implement for now is this |
| 12:11.33 | luka12345 | i have to bind with kernel driver to recive events |
| 12:11.47 | luka12345 | and i get the events via callbacks |
| 12:11.52 | luka12345 | for example |
| 12:12.09 | luka12345 | phone is off hook - a function gets called |
| 12:13.34 | luka12345 | this is example from alsa channel http://pastebin.com/hys63174 |
| 12:15.28 | luka12345 | obviously the "phone events" like hangup come from somwhere inside asterisk |
| 12:15.52 | luka12345 | but i have a situation where "phone event" will come from kernel... |
| 12:15.59 | luka12345 | this is what is confusing for me |
| 12:16.20 | luka12345 | i have not yet started to code this part |
| 12:16.58 | luka12345 | yesterday i only compiled dummy moduled linked with kernel to see if it will get loaded |
| 12:17.05 | luka12345 | and it did... |
| 12:23.07 | luka12345 | maybe i should be using sig_analog.[c,h] stuff |
| 12:32.23 | *** join/#asterisk-dev frawd (~francois@221.red-80-28-139.adsl.static.ccgg.telefonica.net) |
| 12:32.23 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:32.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:36.38 | tzafrir_laptop | luka12345, you can also write your own DAHDI driver |
| 12:37.00 | tzafrir_laptop | that is: a kernel module |
| 12:37.13 | tzafrir_laptop | and use the existing chan_dahdi |
| 12:46.59 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:46.59 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:47.12 | luka12345 | tzafrir_laptop: i'll look into that |
| 12:49.21 | snuff-home | sounds more like what u'd want vs most other chan drivers which are network based |
| 13:09.29 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:09.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:10.47 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-krepfygqbsqyrifr) |
| 13:10.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:13.29 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qkloawddnjbcmzbj) |
| 13:19.50 | tzanger | morning |
| 13:20.58 | tzanger | is there any secret sauce involved in getting a dahdi channel (I'm writing a driver) to allocate a DSP in asterisk for tone detection? It's an FXS port, it's got clean audio in both directions, but "dahdi show channel 1" shows that no DSP is active on it |
| 13:21.13 | tzanger | and of course DTMF isn't seen by asterisk |
| 13:21.52 | tzanger | I see DAHDI_FLAG_DTMF but I'm pretty sure that that should only be set if the hardware can do tone detection |
| 13:22.23 | opticron | hmmm...it's been long enough since I've been through that code that I don't quite remember |
| 13:23.05 | tzanger | I'm comparing with existing drivers such as the te1xxp or wctdm |
| 13:24.32 | tzanger | actually lt looks like the proslic on wctdm *can* do tone detect, but it's not used (just going by indirect reg names) |
| 13:24.53 | luka12345 | tzanger: i'm also in the process of doing asterisk - fxs integration |
| 13:25.07 | luka12345 | do you have your dahdi code somewhere on git or svn? |
| 13:25.35 | luka12345 | btw. i'm doing it for lantiq tapi... |
| 13:25.57 | tzanger | luka12345: I do, but not on a public svn server |
| 13:26.13 | tzanger | the driver will be GPL though, just not much use to anyone without the hardware |
| 13:26.41 | luka12345 | well, i'm just trying to see how all this stuff works |
| 13:27.05 | luka12345 | we have working POC made with pjsip but we are swithcing to asterisk now |
| 13:29.29 | tzanger | *nods* |
| 13:39.44 | opticron | tzanger, you'll want to look at the DAHDI_TONEDETECT ioctl |
| 13:40.03 | opticron | and the dahdi_new function in chan_dahdi.c |
| 13:40.32 | tzanger | opticron: hmm |
| 13:40.38 | tzanger | shouldn't asterisk be doing that already though? |
| 13:40.53 | opticron | yes, but does your driver respond properly to the ioctl? |
| 13:42.45 | opticron | I haven't looked into dahdi yet |
| 13:44.17 | opticron | or avoid dealing with that ioctl as the case may be... |
| 13:45.14 | tzanger | oh I see |
| 13:46.10 | opticron | that one in particular is passed directly to the individual device driver and needs to return non-zero to activate the DSP |
| 13:50.01 | tzanger | opticron: nice catch on that |
| 13:50.15 | tzanger | my ioctl handler is very efficient. -ENOTTY. :-) |
| 13:50.23 | opticron | heh |
| 13:50.45 | tzanger | thank you, that would have driven me nuts trying to find it |
| 13:50.58 | opticron | no problem :) |
| 13:51.07 | tzanger | hm, the wct1xxp driver just returns -ENOTTY as well |
| 13:51.37 | opticron | that could very well be a bug that no one has caught |
| 13:51.49 | opticron | because that driver is _ANCIENT_ |
| 13:51.53 | tzanger | I would have thought that'd become very apparent very fast |
| 13:52.02 | tzanger | yes, but te12xp is the same |
| 13:52.04 | tzanger | checking some others |
| 13:52.14 | opticron | hmmm |
| 13:52.50 | tzanger | wctdm also does not handle it |
| 13:53.42 | *** join/#asterisk-dev ggtest (~ggtest@c207.134.154-241.clta.globetrotter.net) |
| 13:54.45 | *** part/#asterisk-dev ggtest (~ggtest@c207.134.154-241.clta.globetrotter.net) |
| 14:05.38 | tzanger | opticron: you were ont he right track |
| 14:05.47 | tzanger | I was misreading my ioctl (stuff was stubbed out) |
| 14:05.59 | opticron | all working now? |
| 14:06.00 | tzanger | I was not returning -ENOTTY, I was returning 0 |
| 14:06.05 | opticron | that would do it |
| 14:06.13 | tzanger | well the DSP is turned on now, yes |
| 14:06.34 | tzanger | but it's not seeing my dtmf. but at least I'm going in the right direction now :-) |
| 14:09.54 | tzanger | weird |
| 14:10.24 | tzanger | if I place a call (sip -> asterisk+te405 < PRI > asterisk+my_hw -> fxs -> telephone |
| 14:10.28 | tzanger | and I hit DTMF on the telephone, asteirsk sees digits very well |
| 14:10.34 | tzanger | and on the fxs chan too |
| 14:10.54 | tzanger | but if I just pick up the telephone, the simple switch doesn't see anything |
| 14:11.30 | file | without knowing your hardware are you actually setting stuff up at that point for a full audio path? |
| 14:12.35 | tzanger | the fxs port passes audio in both directions when it goes offhook |
| 14:12.38 | tzanger | I can verify with dahdi_monitor and recording the tx/rx streams separately on asterisk then playing them back |
| 14:12.53 | tzanger | I can hear the dtmf in the rx (from the DAHDI chan) audio stream |
| 14:13.08 | opticron | so it says dsp is enabled, but doesn't detect and mute properly? |
| 14:13.44 | tzanger | in simple switch |
| 14:13.56 | tzanger | when a call is up, channel.c is spitting out all kinds of nice dtmf detect information |
| 14:15.30 | file | interesting! I haven't looked at that stuff in ages |
| 14:19.26 | opticron | can you verify that the dsp is being setup before the simple switch actually starts? |
| 14:24.54 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:24.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:26.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:26.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:27.15 | tzanger | that would be an unusual failure |
| 14:27.25 | tzanger | I'm pretty sure it's still screwy in my own driver |
| 14:43.18 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:43.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:54.02 | pabelanger | Still looking for people to review https://reviewboard.asterisk.org/r/1796/ it's for the testsuite. Looking for some feedback about how we currently skip tests |
| 14:59.37 | opticron | looks |
| 14:59.37 | russellb | pabelanger: posted a comment |
| 15:02.17 | pabelanger | looks |
| 15:17.42 | pabelanger | heh, Today I learned voicemail.conf has a setting call passwordlocation=spooldir |
| 15:28.50 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:35.00 | Kobaz | putnopvut: ah, there you are |
| 15:35.11 | putnopvut | Kobaz: how's it going? |
| 15:35.14 | Kobaz | putnopvut: yeah i saw the messages |
| 15:35.15 | Kobaz | good good |
| 15:36.02 | Kobaz | pabelanger: oh, so it'll store the passwords separately? |
| 15:36.40 | pabelanger | Kobaz: apparently so, however not much information about it. Looking at the code now |
| 15:36.54 | Kobaz | putnopvut: i remember a conversation a while back with russell and lief about what needs a ship it, and there wasn't really a lot of info on that |
| 15:37.25 | Kobaz | so the conclusion they had was it's better to ask for forgiveness later |
| 15:37.26 | leifmadsen | I don't think a policy has been agreed upon |
| 15:38.15 | Kobaz | pabelanger: if you want some background or design reasonings let me know |
| 15:38.51 | pabelanger | haha, nice. Just cause asterisk to crash |
| 15:39.02 | putnopvut | Kobaz: Yeah, we can tolerate smallish changes going in without a review, but any sort of new feature or large bug fix needs to go on review board, and anything that goes on review board needs to get a ship it. |
| 15:39.04 | Kobaz | heh, what did? |
| 15:39.12 | Kobaz | ah okay |
| 15:39.15 | Kobaz | makes sense |
| 15:39.26 | Kobaz | pabelanger: my stuff? :( |
| 15:39.53 | pabelanger | <PROTECTED> |
| 15:39.56 | Kobaz | oh okay |
| 15:39.58 | Kobaz | phew |
| 15:40.26 | Kobaz | i was gonna say, i really hope there are no crashes, i've been using my predial code for like a year in production |
| 15:41.48 | pabelanger | okay, got it working |
| 15:45.50 | Kobaz | here goes |
| 15:46.08 | Kobaz | first allergy pill of the season |
| 15:46.11 | opticron | pabelanger, did you have any further comments for https://reviewboard.asterisk.org/r/1761/ ? All of the issues you mentioned should now be addressed |
| 15:46.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:46.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:02.07 | Kobaz | putnopvut: you know what you can do |
| 16:02.20 | Kobaz | putnopvut: or someone who is on this part of the product... |
| 16:02.50 | Kobaz | putnopvut: is have a precommit hook that checks for ship it in reviewboard, when you paste a reviewboard link in the commit (or if the jira referenced has a reviewboard link) |
| 16:05.28 | putnopvut | Yep, that is certainly something that can be done. taking the time to actually do it is another thing altogether though ;) |
| 16:06.15 | russellb | or you could get crazy and have something automatically merge patches once they get a ship it |
| 16:06.28 | Kobaz | hehe |
| 16:06.34 | Kobaz | i don't like automerge |
| 16:06.41 | Kobaz | i've seen the horrors |
| 16:06.53 | russellb | well, this wouldn't be related to automerge ... |
| 16:11.10 | kpfleming | pabelanger: there's no need for that guy reporting the typo in chan_iax2.c to open a JIRA issue and post a patch. just go fix it. |
| 16:32.10 | pabelanger | opticron: nope, looks good |
| 16:35.24 | opticron | sweet, thanks :) |
| 17:40.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:40.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:40.44 | Corydon76-home | kpfleming: don't you think that typo fix, if it's in a release, needs the AMI version bumped? |
| 17:40.58 | kpfleming | hmm |
| 17:41.01 | kpfleming | good question |
| 17:41.31 | kpfleming | one option would be to emit *both* the broken and non-broken headers, and documenting the broken one as broken but preserved for compatibility |
| 17:41.38 | Corydon76-home | If people are coding to 'Post', and it suddenly changes to 'Port', we will break them on minor version upgrade |
| 17:44.55 | kpfleming | but i really think that if anyone has written code consuming that event and *not* reported that Port was misspelled, something is seriously wrong |
| 17:45.16 | Corydon76-home | Stranger things have happened. |
| 17:46.05 | file | I dunno 'bout that |
| 17:46.33 | Corydon76-home | Like 'signaling' vs 'signalling' |
| 17:46.43 | pabelanger | mjordan: parallel testing! AWESOME |
| 17:46.54 | opticron | super speed! |
| 17:46.58 | pabelanger | I'm working on testing the stuff now |
| 17:47.41 | Corydon76-home | file: or people telling someone and never bothering to actually file an issue. |
| 17:48.00 | Corydon76-home | Like... with voicepulse service, there's a slow sip channel leak in 1.8... |
| 17:48.12 | Corydon76-home | which isn't resolved by turning on session timers |
| 17:48.23 | Corydon76-home | I need to file that one |
| 17:48.43 | kpfleming | so i'd go back to my proposal above.. emit both headers in release branches, and only the proper one in trunk, with an AMI version increase in trunk |
| 17:49.20 | Corydon76-home | I'm good with that |
| 18:11.10 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 18:20.56 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 18:21.45 | kpfleming | seanbright: please change the summary of 359983 to "Correct spelling of 'Port' header in...". you didn't remove the header, you fixed its name. |
| 18:25.51 | *** join/#asterisk-dev bkruse (~bkruse@75.76.105.124) |
| 18:38.07 | *** join/#asterisk-dev bkruse (~bkruse@75.76.105.124) |
| 18:54.50 | Corydon76-home | kpfleming: as a point of annoyance, could we change that bump of 1.2 to 1.3, instead move to 1.2001? Lots of people use float comparison, and when we go from 1.9 to 1.10, it means people changing a lot of code. |
| 18:55.46 | kpfleming | such questions should be posted on the mailing list; that's not a decision a single person should make |
| 18:55.52 | Corydon76-home | Okay |
| 18:57.07 | Corydon76-home | My last such email to the -dev list got exactly 0 replies |
| 18:57.22 | kpfleming | ok, let's never ask again then :-) |
| 18:57.28 | Corydon76-home | Subject: "Permit/deny with negation patch" |
| 18:57.46 | Corydon76-home | No, I'm suggesting that somebody go reply to that one. ;-) |
| 19:01.47 | seanbright | kpfleming: i removed the header. |
| 19:02.07 | kpfleming | seanbright: was 'Port' already there? |
| 19:02.23 | seanbright | kpfleming: i added Port in 10 (so there was Post and Port) and then i removed Post from trunk (so only Port was left) |
| 19:02.44 | kpfleming | but prior to that commit, Port was not in trunk at all. |
| 19:03.38 | seanbright | i'm not sure i see the problem |
| 19:03.48 | seanbright | but i'll change the commit message to make you happyu |
| 19:03.54 | seanbright | s/yu/y/ |
| 19:04.16 | kpfleming | if i read the summary of that commit, it looks like you removed a header. that's not the purpose of your commit. the purpose of your commit, in trunk, was to rename Post to Port. |
| 19:04.33 | kpfleming | and if you read the diff, that's exactly what you did, in trunk. |
| 19:05.38 | seanbright | updated |
| 19:05.47 | kpfleming | thanks! |
| 19:05.51 | seanbright | you're welcome! |
| 19:34.50 | *** join/#asterisk-dev alexoc (~alexoc@187.106.48.119) |
| 19:37.09 | seanbright | jrose_atDigium: awesome idea - make pluggable call ID implementations... annnnnd GO |
| 19:39.56 | file | eh? |
| 19:40.10 | seanbright | res_callid_integer |
| 19:40.13 | seanbright | res_callid_uuid |
| 19:40.17 | seanbright | etc |
| 19:41.17 | mjordan | seanbright: I could be wrong, since I haven't seen the latest work he's done, but I'm not sure that's what the intent is |
| 19:41.46 | seanbright | admittedly i haven't looked that closely |
| 19:41.48 | mjordan | keeping in mind that "call ID", in the context that he's working on, is not a call ID as you would normally define it |
| 19:41.50 | mjordan | :-) |
| 19:42.17 | seanbright | well it's an atomically incrementing integer |
| 19:42.34 | mjordan | currently, yes |
| 19:42.45 | seanbright | ok, i should probably look more closely before firing off b.s. |
| 19:42.49 | mjordan | it could be anything, so long as its unique (for some definition of unique) |
| 19:43.01 | mjordan | he even has a wiki article: https://wiki.asterisk.org/wiki/display/AST/Unique+Call-ID+Logging#UniqueCall-IDLogging-CallIDAPI |
| 19:43.04 | seanbright | oh snap |
| 19:44.31 | seanbright | well that is helpful |
| 19:50.05 | seanbright | neat idea |
| 19:50.20 | seanbright | uuids wouldn't be too friendly for logs or the cli i suppose |
| 19:50.22 | kpfleming | it's an AstriDevCon idea |
| 19:50.32 | seanbright | well i don't get invited to those |
| 19:50.38 | kpfleming | lol |
| 19:50.45 | seanbright | :D |
| 19:53.23 | mjordan | seanbright: I invite you |
| 19:53.52 | mjordan | alas, my text has no implications beyond the fact that "you're invited" |
| 19:56.26 | opticron | app_echo's documentation states that it echoes audio, video, and DTMF (not including #) but really echoes all frames including control frames except for DTMF # |
| 19:56.35 | kpfleming | true |
| 19:56.43 | kpfleming | it shouldn't |
| 19:56.51 | opticron | should I correct it to the description? |
| 19:57.04 | opticron | because I've bumped up against this in the testsuite |
| 19:57.16 | kpfleming | i would vote for that |
| 19:59.40 | seanbright | mjordan: nice. i'm in. |
| 19:59.48 | opticron | actually, I'd say echoing any media is fair game, just not control frames |
| 19:59.54 | seanbright | i'll probably show up for astricon this year |
| 19:59.59 | kpfleming | opticron: agreed |
| 20:00.01 | seanbright | grace you with my presence |
| 20:00.16 | kpfleming | opticron: well... no. modem frames should not be echoed, that's not useful. |
| 20:06.43 | opticron | adds null frames to the list as well |
| 20:18.33 | bkruse | always echoes modem frames, much go patch self |
| 20:32.35 | opticron | you would, bkruse |
| 20:32.36 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 20:32.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:40.07 | jrose_atDigium | seanbright: I'm glad you are interested. |
| 20:42.18 | jrose_atDigium | It's probably some of the most elaborate code I've written for Asterisk... |
| 20:47.27 | jrose_atDigium | For the record though, the name 'call id' is subject to change since it is a confusing name. I just haven't come up with anything to change it to. (If anyone does know a good name for it, by all means, comment in the wiki article or on the review) |
| 22:37.07 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 22:37.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:46.06 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-krepfygqbsqyrifr) |
| 22:47.17 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 22:47.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |