| 02:23.16 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 02:30.41 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 03:08.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:08.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:48.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-38-140-211.ptld.qwest.net) |
| 06:19.34 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 07:43.54 | *** join/#asterisk-dev modsaid (~modsaid@82.201.210.162) |
| 07:44.33 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:44.33 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:02.37 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 09:06.28 | *** part/#asterisk-dev gamedna (~gamedna@cpe-70-125-155-74.satx.res.rr.com) |
| 09:09.03 | *** join/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 09:09.24 | Pitel | How to find out if there is some string stored in stringfield? |
| 09:12.38 | Pitel | my guess is strlen(struct->field) |
| 09:28.18 | modsaid | anyone tried jack_hook before? |
| 10:12.35 | modsaid | thought so :( |
| 10:57.50 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 10:59.36 | *** join/#asterisk-dev bkruse (~bkruse@75.76.105.124) |
| 10:59.36 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 11:25.55 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:25.55 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:31.59 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 11:54.43 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:54.43 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:06.04 | *** join/#asterisk-dev modsaid (~modsaid@196.218.219.102) |
| 12:19.49 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:27.16 | modsaid | russellb: r u there? |
| 12:27.47 | russellb | yes, but pretty busy at the moment ... |
| 12:27.55 | russellb | what's up |
| 12:28.28 | russellb | if I don't keep writing, leifmadsen will beat me with a stick |
| 12:28.49 | modsaid | just having some hard time getting my jack_hook to work with JACK server |
| 12:28.51 | modsaid | but it is ok |
| 12:29.02 | modsaid | i'll keep searching around |
| 12:29.03 | russellb | I tried it the other day and got it to work |
| 12:29.15 | russellb | are you getting an error from asterisk? |
| 12:29.47 | modsaid | actually it is a bit unclear to me... we have 3 different things: |
| 12:29.51 | russellb | I ran jackd from my command line ... $ sudo jackd -s asterisk -d dummy -r 8000 |
| 12:30.03 | russellb | and then I used something like JACK_HOOK(manipulate,ns(asterisk)) |
| 12:30.18 | russellb | and then I verified that the JACK ports got created using ... $ sudo jack_lsp -s asterisk |
| 12:30.31 | russellb | (commands from memory, so ...) |
| 12:30.34 | *** join/#asterisk-dev michael-i (~michael-i@141.41.40.118) |
| 12:30.43 | modsaid | ok |
| 12:31.04 | modsaid | so asterisk is the one that should create the jack ports |
| 12:31.08 | modsaid | right ? |
| 12:31.09 | russellb | correct |
| 12:31.15 | modsaid | great... |
| 12:31.21 | modsaid | one other thing |
| 12:31.22 | russellb | it creates an input port and output port for each channel |
| 12:31.38 | modsaid | and the channel name in ur example is asterisk |
| 12:31.41 | russellb | leifmadsen: I made a note to myself to consider documenting JACK in our book, heh |
| 12:31.53 | russellb | not channel name, server name |
| 12:31.58 | russellb | JACK server name |
| 12:32.03 | leifmadsen | shows russellb the stick |
| 12:32.12 | modsaid | oh ok... in my case localhost |
| 12:32.42 | russellb | no, i named by jack server with the -s argument to jackd |
| 12:32.59 | modsaid | i c |
| 12:33.14 | modsaid | i'll try it |
| 12:33.23 | modsaid | but i have one other thing that is related to jack itself |
| 12:33.36 | modsaid | i want to run a jack app.... like simple_client from jack examples |
| 12:33.43 | modsaid | how to I do that...? |
| 12:34.00 | russellb | I don't know what simple_client does |
| 12:34.18 | modsaid | it simple copies data from the input port to the output port as it is |
| 12:34.31 | modsaid | but i'll modify it now to make it copy the data twice |
| 12:34.39 | modsaid | to get familiar with it |
| 12:40.22 | michael-i | I know I'll have to sign my own agreement with polycom for the codecs, but are the asterisk wrapper modules for siren7/14 open sourced anywhere? |
| 12:41.09 | kpfleming | no, they are not |
| 12:41.25 | JunK-Y | good morning guys |
| 12:42.22 | michael-i | kpfleming: part of the license requirement? just curious if I should go through the effort of submitting a licensing request |
| 12:42.47 | kpfleming | no, the polycom license does not affect the wrapper code |
| 12:43.02 | kpfleming | to be honest, we've just never discussed releasing the wrapper modules |
| 12:43.50 | kpfleming | i don't even know what license they could be released under... certainly GPLv2 is not appropriate |
| 12:44.08 | michael-i | public domain ;) |
| 12:44.11 | michael-i | ouch |
| 12:44.27 | russellb | private domain |
| 12:44.52 | michael-i | I'm working on porting Askozia to also run on glibc but until then I'm always looking for work arounds to get these proprietary modules in |
| 12:45.29 | michael-i | just curious, thanks for the info |
| 12:46.03 | kpfleming | no, we'd never give up copyright :-) |
| 12:46.50 | michael-i | me neither, don't worry! |
| 12:48.42 | kpfleming | probably the Russell Bryant Gets Free Beer license would work |
| 12:49.13 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 12:49.13 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 12:49.37 | russellb | kpfleming: YES |
| 12:49.56 | russellb | I'll bring it to AstriCon and share it, I promise. |
| 12:50.10 | kpfleming | ... the containers |
| 12:50.18 | russellb | bazinga |
| 12:51.09 | michael-i | starts packing german beer... |
| 13:10.12 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:11.22 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:18.57 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:19.57 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 13:19.57 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 13:21.02 | *** part/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:22.39 | *** join/#asterisk-dev frawd (~francois@83.34.200.195) |
| 13:24.37 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:24.51 | *** part/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:34.28 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:38.26 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 13:47.19 | *** part/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:49.41 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 13:49.41 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:55.12 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 13:55.54 | *** part/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 14:12.51 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:28.33 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:28.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:35.25 | *** join/#asterisk-dev moy (~moy@bas1-toronto47-1177731847.dsl.bell.ca) |
| 14:40.15 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 14:45.59 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 14:45.59 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:56.20 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:56.20 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:13.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:13.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:19.38 | sruffell | tzafrir_laptop: FYI I looked at sysfs more again last night....and reworked it again after realizing (I think accurately) that we can't embed the objects in the channels unless we make the act of registration bump the board driver refcount. Which means that we would never just be able to "modprobe -r" again. So I've switched it over to using glue objects. |
| 15:21.50 | tzafrir_laptop | sruffell, not able to modprobe -r while the module is in use? |
| 15:22.07 | tzafrir_laptop | that is: while there's a userspace program using it? |
| 15:22.41 | sruffell | even when it wasn't in use. Because in order to handle the release we need to keep the release function around in memory. The alternative would be to always force a "dahdi_cfg -s", but, eck..that doesn't sound good to me. |
| 15:23.48 | kpfleming | i would not object to requiring an explicit shutdown before modules could be unloaded. it's completely logical. |
| 15:24.19 | sruffell | hmm.... |
| 15:30.40 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:31.03 | sruffell | actually, I don't know if dahdi_cfg -s would do it...since we can't force unregistration that way (I was thinking of how the dynamic spans work...that does actually unregister the span). |
| 15:31.11 | tzafrir_laptop | ordering from userspace probably opens the door to all the races the reference counting was trying to avoid in the first place |
| 15:31.56 | sruffell | I haven't even gotten to that point. I'm still putting my proposal for the sysfs relationships. |
| 15:32.05 | sruffell | it's all still numbered in order. |
| 15:32.46 | sruffell | although I am trying to add another 292 bytes (the struct device) to the channel data structure which is already over bloated at ~2.5K. |
| 15:33.07 | sruffell | but....anyway....just letting you know I'm still working at it..I still hope to have a patch series soon for you to review. |
| 15:35.19 | sruffell | but basically....I'm trying to make sure that the sysfs represenation of spans doesn't implicitly depend on global dahdi channel numbering...that they are all based on board/span/chan then that way, the spanno and channo fields aren't needed in order to expose the spans in sysfs. All that's needed is a parent device, and *that* is the device that is in the class. |
| 15:37.12 | sruffell | (as an aside...I will accept that I may be wrong on this...but I feel compelled to try and find out if I am) |
| 15:38.00 | tzafrir_laptop | from what I understand, there board driver should already have a refernce count up by now, |
| 15:38.18 | tzafrir_laptop | because the chans array in dahdi points to its channels, right? |
| 15:41.18 | sruffell | it doesn't....the board driver only has it's reference count bumped when there is an open channel. |
| 15:41.40 | sruffell | (with the exception of the dynamic spans) |
| 15:43.10 | sruffell | but...when a driver is unloaded...it can completely unlink it's spans and channels currently. When there is an embedded device or kobject, that might not be the case. |
| 15:43.57 | tzafrir_laptop | Another small point is that the DAHDI ioctl interface allows specifying the channel number explicitly |
| 15:44.13 | sruffell | (if we want to allow the board drivers the embed struct dahdi_chans in their specific channel structures. I guess another alternative would be to require spans and channels be allocated by the board drivers with "allocate" functions...then the core owns that memory). |
| 15:44.14 | tzafrir_laptop | That is: using ioctls explicitly on different channels |
| 15:44.48 | sruffell | yeah....that's why I couldn't get rid of the unit in the issue-17669 patch. |
| 15:44.54 | sruffell | not without more thought. |
| 15:45.19 | kpfleming | tzafrir_laptop: i think we already discussed that and i agreed that it could go away... i don't think anything legitimately uses that ability to operate on a different channel than it opened |
| 15:46.42 | sruffell | but not the DAHDI_SPECIFY ioctl, right? |
| 15:46.46 | sruffell | or am I mistaken? |
| 15:46.51 | kpfleming | correct |
| 15:47.02 | sruffell | since supporting that ioctl is a big motivator for what I'm trying to allow. |
| 15:47.03 | sruffell | ok. |
| 15:47.11 | kpfleming | but DAHDI_SPECIFY shouldn't/can't be used on an fd that was opened directly on a channel |
| 15:47.19 | sruffell | ok...sounds good. |
| 15:49.35 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-jzoxpbbqtkhlbhvd) |
| 15:58.20 | *** part/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 16:11.10 | mnicholson | Is anyone successfully using app_transfer to send REFER messages with 1.8 or trunk? |
| 16:13.38 | anonymouz666 | how can I see the commit (the code added) for a feature? In my case, I want to see all code added to Asterisk to make the function CHANNEL enable/disable the EC from the dialplan |
| 16:14.54 | anonymouz666 | with that, I can see if it is possible to add this feature to 1.4 (or someone right now can say if it is) |
| 16:15.39 | mnicholson | anonymouz666, you can use 'svn annotate' to see the last time that code was changed, then you can use svn diff |
| 16:16.10 | mnicholson | anonymouz666, (accidentally pressed 'enter') then you can use 'svn diff' to view the changes made in that revision |
| 16:20.01 | anonymouz666 | Revision 191411 the author was kpfleming |
| 16:20.22 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 16:20.36 | mnicholson | anonymouz666, so run 'svn log -c191411' to see the commit message and 'svn diff -c191411' to see the changes |
| 16:21.11 | mnicholson | so... I think asterisk's handling of the response to REFER requests it sends out is broken in 1.8 and trunk. Stand by. |
| 16:22.44 | anonymouz666 | mnicholson: I got the diff |
| 16:23.33 | mnicholson | anonymouz666, that is what you wanted right? |
| 16:24.17 | anonymouz666 | lol haha there's a var called 'int blah = 0;' very descriptive :D |
| 16:25.10 | anonymouz666 | mnicholson: yes... but that diff compares to 191410... I need to compare with DAHDI for version 1.4... but that is another case |
| 16:25.35 | mnicholson | anonymouz666, you can check out that rev and make a diff yourself |
| 16:26.16 | anonymouz666 | mnicholson: you mean the latest 1.4 with the 191411, right? |
| 16:29.56 | mnicholson | yes, you would diff those two versions |
| 16:30.46 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 16:31.30 | anonymouz666 | that function is very very useful, since without it you can break modem communication... |
| 16:31.48 | anonymouz666 | so it's better to be sure that EC won't return |
| 16:43.31 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 16:57.01 | michael-i | google and system wide search reveals nothing: anyone seen "asterisk: can't resolve symbol 'g_tone_rx'"? |
| 16:57.22 | michael-i | my blackfin builds just started exploding after updating dahdi, asterisk, libpri, etc... |
| 16:57.59 | russellb | no idea what uses that |
| 16:58.03 | russellb | it's not in the asterisk source that isee |
| 16:58.28 | michael-i | i'm clueless...it's not showing up anywhere |
| 17:01.47 | russellb | use the force! |
| 17:03.16 | michael-i | honestly though...how many short strings can you type into google and get ZERO results?! Is this a sign to call it a night? |
| 17:10.17 | michael-i | there's a sig_tone_rx in spandsp. nice symbol error I think |
| 17:10.50 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:10.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:17.14 | *** join/#asterisk-dev fenlander (~fenlander@82.152.81.57) |
| 17:21.21 | michael-i | giving up...power pc worked fine. Blackfin is the black sheep again! Bye everyone |
| 17:21.45 | Deeewayne | michael-i, sure its g_tone_rx ? spandsp has sig_tone_rx |
| 17:21.51 | Deeewayne | oh well |
| 17:22.11 | *** join/#asterisk-dev bkruse (~bkruse@76.73.216.184) |
| 17:22.11 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 17:53.56 | *** join/#asterisk-dev bkruse (~bkruse@75.76.105.124) |
| 17:54.03 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 18:44.11 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-52-237-137.dhcp.embarqhsd.net) |
| 18:58.24 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:58.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:01.33 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 19:45.16 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 19:58.45 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 19:58.45 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:03.44 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 20:04.41 | tzafrir | sruffell, still around? |
| 20:09.47 | *** join/#asterisk-dev bkruse (~bkruse@76.73.216.184) |
| 20:09.47 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 20:11.35 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-52-237-137.dhcp.embarqhsd.net) |
| 20:15.57 | *** join/#asterisk-dev bkruse (~bkruse@76.73.216.184) |
| 20:15.57 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 20:18.50 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 20:29.18 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 20:33.12 | sruffell | tzafrir: here |
| 20:34.11 | tzafrir | I had some more thoughts about what you said |
| 20:34.28 | tzafrir | wrote |
| 20:35.20 | sruffell | ? |
| 20:35.27 | tzafrir | Suppose we go for userspace unregistration, |
| 20:36.00 | tzafrir | Does this mean drivers need to figure out how to behave after being registered to DAHDI? |
| 20:36.12 | tzafrir | short time, typically, but still |
| 20:36.59 | tzafrir | For instance, suppose you unregistered one span, but not the other (had open files) |
| 20:42.00 | sruffell | if a span is unregistered wouldn't that be the same as just unbinding just that span? |
| 20:42.09 | sruffell | so then the open files would all just become dissasociated? |
| 20:44.10 | tzafrir | it's the same, I guess |
| 20:50.37 | tzafrir | sruffell, but potentially just one span of the card, or just one card of two |
| 20:52.03 | sruffell | yeah....I still think it is probably worth doing our best to not require explicit unregistration. Either with glue objects, or by putting chan/span allocation functions in the core and then going back to having pvt members on the spans/channels for the board specific stuff. Not sure thought... |
| 20:52.08 | sruffell | s/thought/though/ |
| 21:32.52 | *** join/#asterisk-dev janinges (j@ninge.net) |
| 21:33.55 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 21:33.55 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 21:43.45 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 21:43.45 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. |
| 21:53.15 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:53.16 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:55.56 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 22:31.53 | Qwell | I assert that if extensions.conf has a syntax error, that the CLI commands (e.g., dialplan reload) should still work. That isn't currently the case. Thoughts? |
| 22:32.40 | Qwell | It shouldn't require an unload/load of pbx_config.so once you've fixed the config. |
| 22:35.31 | Kobaz | yeah |
| 22:35.40 | Kobaz | yeap |
| 22:47.54 | russellb | Qwell: +1 |
| 22:52.37 | Qwell | and done |
| 22:59.50 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 22:59.51 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:32.43 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |