| 00:24.39 | *** join/#asterisk-dev snuff-work (~aaa@144.135.29.76) |
| 00:24.39 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:27.47 | *** part/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 00:33.02 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:33.02 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:53.01 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 01:10.53 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 02:18.11 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 02:58.33 | *** join/#asterisk-dev moy_ (~moy@70.31.14.144) |
| 05:02.05 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 06:20.41 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-116-81.ptld.qwest.net) |
| 07:22.25 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3967775.cpe.net.cable.rogers.com) |
| 07:24.17 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:25.49 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:25.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 08:04.00 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:04.00 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:11.26 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:12.00 | *** join/#asterisk-dev schmidts (~schmidts@213.235.212.193) |
| 08:12.01 | schmidts | good morning |
| 08:17.38 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:21b:63ff:feb5:e13b) |
| 08:34.12 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 09:11.17 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:11.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:13.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 09:13.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 09:33.42 | schmidts | leifmadsen good morning, a little bit early today? |
| 09:39.36 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-103-152-61.cinci.res.rr.com) |
| 10:21.56 | wedhorn | oej: are you planning on putting M18585 up for review as it seems to impact all branches (I can confirm 1.4 and trunk) |
| 10:21.58 | MuffinMan | [confirmed] [Asterisk] Channels/General 0018585: [patch] AMI redirect from meetme - calls fail reported by oej https://issues.asterisk.org/view.php?id=18585 |
| 10:22.25 | oej | I will do that. Or you can - you have an account too. |
| 10:22.27 | oej | :-) |
| 10:22.33 | oej | Extremely busy today |
| 10:22.41 | oej | Life |
| 10:23.44 | wedhorn | happy to leave that to you when you get some time. I actually don't use ami, so don't know to much of what to test or what else it will impact on |
| 10:34.46 | *** join/#asterisk-dev guilhermebr (~Guilherme@187.58.35.34) |
| 10:35.34 | *** join/#asterisk-dev snuff-work (~aaa@120.156.55.92) |
| 10:35.34 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:08.24 | *** join/#asterisk-dev atommat (~atommat@pushbutton.plus.com) |
| 11:08.27 | *** part/#asterisk-dev atommat (~atommat@pushbutton.plus.com) |
| 11:49.42 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:49.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:14.11 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.50.117.126) |
| 12:24.58 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 12:35.52 | vrban | hello, how do i do a activ waiting, to check if ast_do_masquerade is finished? becuase i run into the pit, that i grab the new channel, while the ast_do_masquerade si not finished. |
| 12:37.29 | schmidts | vrban you could try locking the channel cause AFAIK in a masquerade all channels have to be locked. |
| 12:49.53 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 12:50.28 | vrban | it seem i need to check chanl->masq to see if ast_do_masquerade is still in progress. that's ok |
| 12:50.40 | vrban | chan->masq |
| 12:58.44 | vrban | <PROTECTED> |
| 13:04.01 | asterisk-learner | Hi, is this the correct way to play a sound file in a channel ? http://pastebin.com/YpyqrTyU |
| 13:06.31 | schmidts | asterisk-learner maybe it would be safer to use the playback app directly with pbx exec |
| 13:07.28 | asterisk-learner | schimdts: really ? do u know what potential problems i could run using this code ? |
| 13:07.36 | asterisk-learner | into* |
| 13:08.09 | schmidts | asterisk-learner no but you have to trace every change to this part of code, when you use a find app and pbx_exec you dont have to care about ;) |
| 13:09.26 | asterisk-learner | what do you mean by "trace every change" ? u mean when upgrading from one version of asterisk to another ? |
| 13:09.27 | schmidts | asterisk-learner http://pastebin.com/CbVV8vHp thats all you will need for this IMO |
| 13:09.33 | schmidts | yes |
| 13:12.03 | asterisk-learner | schimdts: thx but is it ok to execute "pbx_exec" for just "beep" ? also I have a big multi threaded application that might call beep more than once in a second... |
| 13:15.35 | schmidts | asterisk-learner why not? in fact i would prefer pbx_exec which is designed to be called several times instead of doing it byself. the whole dialplan execution is build on pbx_exec ;) |
| 13:16.14 | schmidts | asterisk-learner the beep was only an example the 3. parameter are only the parameters you normaly use in the () brackets of an application |
| 13:16.17 | asterisk-learner | schimdts: ok thx, i will try it |
| 13:16.38 | asterisk-learner | yes, in my case i want to use the beep :-) |
| 13:16.44 | schmidts | :D |
| 13:17.34 | schmidts | my tests with SIPP could handle 590 calls per second to beep with normal dialplan usage, so pbx_exec can handle this ;) |
| 13:17.45 | asterisk-learner | the issue that i am facing at a client site is that i have this custom playfile() followed by some more instructions |
| 13:18.11 | asterisk-learner | normally the following instructions are executed in the same second as playfile |
| 13:18.26 | asterisk-learner | but in some rare cases they get to execute some minutes after it !!! |
| 13:18.42 | asterisk-learner | (i can see that from the full file the client sent me) |
| 13:19.14 | asterisk-learner | also i can see these warning : NOTICE[28115] channel.c: No/unknown event '0' on timer for 'SIP/3822-1ea9bd60'? |
| 13:19.27 | asterisk-learner | so i suspected it might be caused by my playfile.... |
| 13:20.01 | asterisk-learner | schimdts: waw 590 simultaneous calls on 1 asterisk ? :-) |
| 13:20.27 | schmidts | asterisk-learner 595 concurrent call PER SECOND ;) |
| 13:20.52 | asterisk-learner | :-D |
| 13:20.59 | asterisk-learner | what's ur box specs ? |
| 13:21.14 | schmidts | asterisk-learner we have talked about this problem earlier this week and i have said this comes from the zaptel timing source ;) |
| 13:21.50 | asterisk-learner | schimdts: yes, true :-$ |
| 13:22.01 | schmidts | not so heavy, a HP DL 360 with one quad xeon cpu at 2GHz and 4gb ram |
| 13:22.32 | asterisk-learner | but i didnt understood what i should do / investigate about zaptel ... |
| 13:22.40 | schmidts | wait for asterisk 1.10 or try out trunk. all of my patches which makes this possible are allready submitted |
| 13:23.02 | asterisk-learner | also are u suggesting that using pbx_exec() will not matter in that case |
| 13:23.04 | asterisk-learner | ? |
| 13:23.09 | schmidts | in fact this only happens with your self written startstream and not with normal playback i dont know |
| 13:23.38 | schmidts | give it a try. IMO playback in dialplan works without any problems you will not have any problem with pbx_exec |
| 13:24.44 | asterisk-learner | schimdts: ok thx a lot |
| 13:24.46 | asterisk-learner | :-) |
| 13:24.53 | schmidts | your welcome ;) |
| 13:47.12 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 14:12.06 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 14:43.47 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 14:45.01 | pabelanger | Started playing around with: 'core show channel variable' and 'core show channel variables' last night. I was tired going to google to get information |
| 14:51.19 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:51.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:54.17 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-gedkbjrlagoalbro) |
| 14:56.32 | *** join/#asterisk-dev russellb (~russell@asterisk/digium-open-source-team-lead/russellb) |
| 14:56.32 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:57.08 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 15:06.29 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:06.29 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:06.40 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 15:06.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:14.58 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:14.59 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:07.22 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:55.17 | Kobaz | hmm |
| 16:55.25 | Kobaz | kpfleming: you around? |
| 16:56.33 | kpfleming | nope :-) |
| 16:57.29 | Kobaz | heh |
| 16:57.41 | Kobaz | so i'm playing with this hold/unhold stuff in ast_read |
| 16:58.13 | Kobaz | it doesn't seem like ast_read gets AST_CONTROL_UNHOLD or AST_CONTROL_HOLD |
| 17:01.26 | kpfleming | they are delivered to channel drivers via their indicate() callbacks, so that may be true |
| 17:01.37 | russellb | well, depends where you're trying to catch it |
| 17:01.47 | russellb | are you trying to catch it on the channel putting someone on hold, or the channel being put on hold? |
| 17:02.06 | Kobaz | either one |
| 17:02.24 | Kobaz | well, i guess it should only send out one event |
| 17:02.34 | russellb | you should see it in ast_read() on the channel initiating hold |
| 17:02.54 | russellb | you should see it in ast_write(), which will call ast_indicate(), on the channel being put on hold |
| 17:03.02 | Kobaz | in ast_read there's the big switch inside of if (f) |
| 17:03.11 | russellb | mhm |
| 17:03.26 | Kobaz | i added a AST_CONTROL_UNHOLD and AST_CONTROL_HOLD cases |
| 17:03.28 | russellb | f->frametype == AST_FRAME_CONTROL, f->subclass == AST_CONTROL_HOLD |
| 17:03.44 | Kobaz | oooooh |
| 17:03.46 | Kobaz | that would do it |
| 17:03.48 | russellb | you may have accidentally tried to catch frametype == AST_CONTROL_HOLD which isn't right |
| 17:03.48 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 17:03.50 | russellb | :-) |
| 17:03.52 | Kobaz | yeah |
| 17:03.58 | kpfleming | russellb: enums FTW :-) |
| 17:08.12 | russellb | yeah... |
| 17:08.31 | Kobaz | so you'll get it in ast_read only if you're the channel on hold |
| 17:08.51 | russellb | other way around |
| 17:09.00 | russellb | you'll get it in ast_read if you're the channel putting someone on hold |
| 17:09.05 | Kobaz | oh right yeah |
| 17:09.13 | Kobaz | <@russellb> you should see it in ast_read() on the channel initiating hold |
| 17:09.16 | Kobaz | yeah |
| 17:09.30 | Kobaz | i scrolled up, looked at what you wrote, scrolled down, and promptly misremembered what you said |
| 17:09.34 | Kobaz | heh |
| 17:09.49 | russellb | nice |
| 17:13.24 | Kobaz | this is going to be so awesome |
| 17:16.46 | seanbright | i doubt it |
| 17:16.50 | seanbright | heh |
| 17:16.54 | seanbright | trolling ftw! |
| 17:17.01 | russellb | there's seanbright with a seanbright comment |
| 17:26.05 | Corydon76-home | licks seanbright |
| 17:29.20 | Kobaz | heh |
| 17:29.35 | Kobaz | i've wanted on hold notification for years |
| 17:31.06 | russellb | Corydon76-home: wtf? |
| 17:31.39 | Kobaz | Corydon76-home: taste like chicken? |
| 17:34.23 | seanbright | oh dear |
| 17:37.08 | Corydon76-home | Kobaz: tastes like beer, actually |
| 17:40.52 | Kobaz | hah |
| 18:29.08 | JunK-Y | lo guys |
| 18:32.17 | Corydon76-home | Afternoon, JunK-Y |
| 18:34.38 | JunK-Y | how are ya? |
| 18:50.18 | Corydon76-home | Not too bad, yourself? |
| 18:55.36 | JunK-Y | not that great, im sick (cold) |
| 18:55.50 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 19:05.11 | *** join/#asterisk-dev moy_ (~moy@CPE003048b11058-CM0026f396812d.cpe.net.cable.rogers.com) |
| 19:07.08 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:12.19 | *** join/#asterisk-dev citywok (~kvirc@67-134-194-33.dia.static.qwest.net) |
| 19:12.23 | citywok | join #asterisk-social canada |
| 19:13.04 | tzafrir_laptop | Should I? |
| 19:13.12 | citywok | typo |
| 19:13.13 | tzafrir_laptop | Is there such a channel? |
| 19:13.16 | citywok | no |
| 19:28.42 | jsmith | Social Canadians? |
| 19:28.45 | jsmith | What a concept! |
| 19:29.03 | jsmith | taunts file, pabelanger, and leifmadsen |
| 19:30.32 | jdoe | there are enough social asterisk users to deserve a canada-specific channel? |
| 19:34.09 | pabelanger | jdoe: If you include Terrance and Phillip, yes |
| 19:35.58 | jdoe | haha. |
| 19:36.18 | jdoe | "*ring*" "Hello?" "*pffffffffffffffffffffffffffffffffffffffffffffffffffffft*" |
| 19:36.52 | tzafrir_laptop | sruffell, I'm trying to understand where the dahdi_device stuff is heading to |
| 19:37.43 | tzafrir_laptop | So basically instead of low-level drivers registering spans with dahdi and getting "first available channel numbers" |
| 19:38.06 | tzafrir_laptop | they now register "dahdi devices", those devices become available to userspace |
| 19:38.13 | tzafrir_laptop | (e.g. generate a udev event) |
| 19:38.28 | tzafrir_laptop | and udev registers spans and chanenls |
| 19:38.32 | tzafrir_laptop | right? |
| 19:39.05 | tzafrir_laptop | So we'll have some /etc/dahdi/channels.conf where devices will have channel numbers allocated to them? |
| 19:39.14 | sruffell | In a nutshell, yes, although udev will use the sysfs interface for the devices to have the driver actually register the individual spans and specify a beginning channel number for the spans that are registered that way. |
| 19:39.48 | sruffell | yes, and if there is a span plugged in for which there is no definition, it will be automatically registered in a otherwise unallocated range. |
| 19:40.26 | sruffell | But there will be a module parameter for dahdi that will force the first come, first-serve style for people who don't want to update *anything* in user space. |
| 19:41.23 | sruffell | (in addition to a time-outâ¦if a device was registered, and the spans weren't slottedâ¦dahdi can assume user space isn't going to help it, and go ahead and switch to first-come, first-serve) |
| 19:41.44 | tzafrir_laptop | the driver specifiy a beginning channel number? or udev? |
| 19:42.34 | sruffell | udev will get the uevent, look in the configuration file to see what span number should be assigned, and the base channel number for each span, and give that information back to dahdi.ko for registration of the spans. |
| 19:45.31 | sruffell | Something I wanted to ask you about the byname branch of asteriskâ¦how did you handle conferencing? Since byname is where we want to be for people who are willing/able to update asterisk, it seems we need new ioctls to allow conferencing to happen based in file descriptors instead of numbersâ¦.. |
| 19:45.50 | sruffell | s/based in/based on/ |
| 19:46.26 | tzafrir_laptop | never really looked into this |
| 19:47.22 | tzafrir_laptop | but after initial resolution, you end up with a channel number, as a file descriptor. Why should things be different? |
| 19:48.48 | sruffell | the file descriptor number won't match that channel numberâ¦. |
| 19:49.23 | sruffell | and dahdi_confinfo wants channel numbers. |
| 19:50.33 | tzafrir_laptop | after the translation they should match |
| 19:51.02 | sruffell | In the dahdi_monitor case, I'm thinking that dahdi could allow multiple processes to open a channel (just only the first one can read/write/ioctl to it) and then the ioctls could change to allow file descriptor to be passed in. Then fget/fget_light could be used in the driver to map descriptor to the actual file object... |
| 19:51.09 | tzafrir_laptop | 'channel' in the dahdi_pvt is the channel number |
| 19:51.17 | *** join/#asterisk-dev jeansch (~jeansch@bureau.ubity.com) |
| 19:51.57 | sruffell | ahhâ¦.so you need the minor number to always be equal to the channel number. |
| 19:52.27 | sruffell | So the TRANSCODE/CTL etc.. have to be moved off major 196? |
| 19:52.37 | sruffell | so you don't have wholes in those channel numbers? |
| 19:52.41 | sruffell | s/wholes/holes/ |
| 19:53.08 | tzafrir_laptop | at open time we translate names to channel numbers |
| 19:53.25 | tzafrir_laptop | and from that point everything should be as before |
| 19:53.47 | tzafrir_laptop | open, and channel generation |
| 19:54.49 | sruffell | Ahhâ¦okâ¦I was thinking that was a problem when I was thinking that we wanted to be able to renumber channels. Now that I've realized that a two stage registration is better, I see how that's not a problem anymore. |
| 19:55.15 | sruffell | since a cached channel number in asterisk stays constant. |
| 19:59.28 | sruffell | tzafrir_laptop: do you have any thoughts about how you might teach asterisk how to handle hot plugged spans at runtime? |
| 20:00.11 | tzafrir_laptop | "send an event". Nothing more specific |
| 20:00.52 | tzafrir_laptop | A good start would be the ability to configure without 'dahdi restart' |
| 20:01.24 | sruffell | Okâ¦just curious. That's about as far as I thought down that path too. |
| 20:01.55 | tzafrir_laptop | If that were in place, it would be a simple issue of updateing the config files and hinting asterisk to reload |
| 20:03.41 | sruffell | I guess, at the very least, even with current versions of asterisk a udev script could update the configs and issue "asterisk -rx 'restart when convenient'" |
| 20:59.55 | *** join/#asterisk-dev Corydon76-home (gold@c-69-137-80-31.hsd1.tn.comcast.net) |
| 20:59.55 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 21:32.27 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 21:32.27 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 21:56.28 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 21:56.28 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:43.23 | *** join/#asterisk-dev snuff-work (~aaa@144.135.29.76) |
| 22:43.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:41.55 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:41.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:49.25 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |