IRC log for #asterisk-bugs on 20080201

02:47.08*** join/#asterisk-bugs jmls (n=jmls@81.138.42.77)
03:31.06*** join/#asterisk-bugs zobia (n=laurashr@222.212.64.63)
03:31.18zobiahello everyone
03:31.27zobiai got problem with sccp with 1.4.17
03:31.37zobiathe sccp phone kept registering over and over
03:46.18JunK-YJuggie: ive got another one.
03:46.27JunK-Yim in a HUGE process to upgrade everything to 1.4
03:59.18*** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
03:59.19*** mode/#asterisk-bugs [+o russellb] by ChanServ
05:45.41*** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com)
07:32.49*** join/#asterisk-bugs oej (n=olle@cust-IP-10.data.tre.se)
08:51.41*** join/#asterisk-bugs oej (n=olle@gw-sthlm01.rebtel.com)
09:14.56*** join/#asterisk-bugs oej (n=olle@gw-sthlm01.rebtel.com)
09:33.11*** join/#asterisk-bugs oej (n=olle@gw-sthlm01.rebtel.com)
10:14.52*** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it)
10:17.11*** join/#asterisk-bugs oej (n=olle@gw-sthlm01.rebtel.com)
10:25.39*** part/#asterisk-bugs jmls (n=jmls@81.138.42.77)
10:25.45*** join/#asterisk-bugs jmls (n=jmls@81.138.42.77)
10:42.42*** part/#asterisk-bugs jmls (n=jmls@81.138.42.77)
10:48.16*** join/#asterisk-bugs jmls (n=jmls@81.138.42.77)
11:17.48*** join/#asterisk-bugs ZX81_ (n=ZX81@202.20.97.211)
13:56.21*** join/#asterisk-bugs jmls (n=jmls@81.138.42.77)
14:43.29*** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1)
14:43.29*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
14:46.51*** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman)
14:48.52*** join/#asterisk-bugs miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net)
15:13.52*** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru)
15:14.17d1masfile: hello. that is me again :) have you looked at the t38 api patch?
15:14.45fileno, it is on my list but not presently high priority for other reasons
15:14.51fileit _will_ get looked at, that I can promise
15:15.15d1masin years? :) just kidding :)
15:28.46zobiahello  everyone.
15:29.08zobiaany asterisk develper here that can help me with sccp with 1.4.17?
15:29.17zobiai got some issue which never met in 1.2.24
15:29.26zobiai just upgraded to 1.4.17
15:47.23zobiano one can help?
15:47.44d1maszobia: you may ask on asterisk-users probably here on IRC
15:48.10zobiad1mas thanks
15:48.40zobiad1mas: asterisk-users is the channel name?
15:48.50d1maszobia: yes
15:49.46d1mashm... I believe it is #asterisk-users but it looks like there are only 2 people there
15:49.57*** part/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it)
15:50.32d1masah! it must be #asterisk
15:50.45d1masthere are a lot :)
15:51.31zobiayes. i go to #asterisk already no one help
15:52.24d1maszobia: developers usually are quite unhappy if your question fits into user category. That is does not relate to development or to some already opened bug
15:52.50d1maszobia: I personally cannot help you because neither using SCCP nor am a developer :)
15:53.39zobiad1mas: thank you. but one developer told me to come to here yesterday. that's why i come to here. his name is like @Russl or something like this.
15:54.04d1maszobia: it must be russellb. Ok, sorry then :)
15:54.10zobiacos i suffer deadlock yesterday and can not trace further. he asked to upgrade to 1.4 , but after i ugrade to 1.4 i found more problems.
15:54.19Qwellzobia: using chan_sccp?
15:54.29zobiayes. using chan_scc
15:54.30Qwellthat isn't part of asterisk.  we can't help you...
15:54.31d1masok-ok, so you really has a bug :)
15:55.31zobia@Qwell: do you know how can i get contact with @russellb?
15:55.54Qwellyou can wait for him to show up here, but if you're getting deadlocks with chan_sccp, nobody here can help you..
15:56.57zobia@Qwell:ok , i will wait for him. and can i ask you a question which does not cause deadlock?
15:57.08Qwellhuh?
15:58.27zobia@Qwell: does that mean any questions related to sccp here i could not get any answer?
15:58.38Qwellchan_sccp, yes...pretty much
15:58.50Qwellthat code is very very buggy..
16:02.36zobia@Qwell:i see
16:16.50*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
16:34.29*** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
16:34.29*** mode/#asterisk-bugs [+o russellb] by ChanServ
16:47.16d1maszobia: see him? :)
16:48.34d1masrussellb: by the way - have you lost any interes to 0011635 ? Can I do something to help?
17:11.50russellbM11635
17:11.51MuffinMan[assigned] [Asterisk] Core/Channels 0011635: [patch] multiple issues with autoservice reported by dimas  http://bugs.digium.com/view.php?id=11635
17:12.39russellbi haven't lost interest ... i couldn't decide how i wanted to fix it
17:12.41russellband then i kind of forgot :)
17:20.37*** join/#asterisk-bugs marioja (n=chatzill@modemcable078.64-70-69.static.videotron.ca)
17:24.50*** join/#asterisk-bugs flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br)
17:31.29d1masrusselb: but have you decided how you want to fix it? :)
17:52.16*** join/#asterisk-bugs agx (n=badpengu@81-174-47-16.dynamic.ngi.it)
17:58.42*** part/#asterisk-bugs agx (n=badpengu@81-174-47-16.dynamic.ngi.it)
18:04.22d1masout of curiosity - why there is a WaitMusicOnHold application? Isn't it better to add timeout parameter to MusicOnHold? Why to have separate application with such a small difference in functionality ?
18:12.56Corydon76-digd1mas: you should look at the history of that app
18:14.33d1mascorydon76: how? SVN log?
18:14.46Corydon76-dighttp://svn.digium.com/view/asterisk/trunk/res/res_musiconhold.c?revision=474&view=markup
18:15.07Corydon76-digd1mas: that app was created BEFORE we had multiple arguments to applications
18:15.37d1masCorydon76: i see. But there are no chances I could get this information from the history :)
18:16.10Corydon76-digSure you can
18:16.26Corydon76-digJust look at version 0.1.12, from downloads.digium.com
18:16.46Corydon76-digwhich is the earliest place the application can be found
18:16.48d1masCorydon76: I guess presence of set Congestion/Ringing/ets  instead of single Indicate or something has the same reason?
18:16.55Corydon76-digYes
18:17.17Corydon76-digThey are some of the earliest apps created
18:17.31Corydon76-digThis was before we even had dialplan variables
18:17.54d1masCorydon76: regarding the music on hold - do you think extending it with timeout parameter and depecating WMOH would be a good move?
18:18.26Corydon76-digSure
18:18.37Corydon76-digEspecially since SMOH is now gone
18:19.28d1masSMOH? I guess I need to look into history :)
18:20.10Corydon76-digSetMusicOnHold
18:20.22Corydon76-digIt's now Set(CHANNEL(musicclass)=foo)
18:21.14mvanbaakQwell: you borked app_authenticate
18:22.43Qwelleh?
18:23.19mvanbaakline 162
18:23.25Qwell1.4 or trunk?
18:23.32mvanbaakoh wait!
18:23.37mvanbaakit's russell I think
18:23.39mvanbaaklol
18:23.40mvanbaaktrunk
18:23.45Qwelllooking
18:23.53russellbQwell: did you test that thing?
18:23.59Qwellyep, see email
18:24.00Qwellfixed
18:24.14Qwellmvanbaak: oh, ha
18:24.16mvanbaaks/ = / == /
18:24.27QwellI can fix, I'm in it already
18:24.54Qwellfixed
18:24.58mvanbaaknice
18:25.06Qwellwell, if the commit ever goes through
18:25.20mvanbaakyeah, it's taking some time
18:25.21Qwell...
18:25.28mvanbaaknoticed this morning as well
18:25.35mvanbaaktook almost 10 minutes
18:25.38Qwellmy other commits were fast
18:25.42Qwellthere
18:25.47Qwell101869
18:26.43mvanbaakdoes svnmerge has a force flag ?
18:27.00Qwell-F
18:27.04mvanbaakthanks
18:27.10Qwellbut...it's nasty, don't do it :D
18:27.34d1masCorydon76: actually it doesn't look SMOH is gone - it is present in trunk and it looks like code does not have any deprecation warnings
19:03.49zobia@Qwell: do you know channel.c: Dropping duplicate answer! ?
19:23.42mvanbaakQwell: I wanted your fix in my branch so I could testcompile some cli patches
19:25.18mvanbaakand I have some .zshrc magic that forces ./configure --enable-dev-mode when current dir is inside /home/michiel/dev/personal/asterisk/*
19:38.05*** join/#asterisk-bugs miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net)
20:02.57d1masDoes anyone know why MusicOnHold lives in res/ instead of apps/ ?
20:03.50jsmithd1mas: Becaues it's a resource!
20:04.21jsmith(Now, before anybody yells at me, there is also a MusicOnHold application, but the functionality is in the resouce)
20:05.18russellbres is the dumping ground for things that don't make sense elsewhere ... musiconhold is much more than an app, so it sorta makes sense to have it in there
20:05.27d1masjsmith: I was talking exactly about application. But I've got the idea
20:10.44d1masbtw, it seems you need something like janitor project to convert all apps to use AST_DECLARE_APP_ARGS / AST_STANDARD_APP_ARGS
20:11.06d1masthere are still places not doing it
20:15.01d1masAlso, is there ANYONE who knows anything about DSP_DIGITMODE_MUTECONF + DSP_DIGITMODE_MUTEMAX ? I asked on developers list twice but got no feedback. I believe it is something ancient and outdated...
20:18.03putnopvutd1mas: I have this feeling that there are very few people who know what's going on with DSP-related code, which is why you haven't gotten much of a response.
20:21.18d1mashm... I can obviously remove is and check that nothing has broken. However it is obvious I will be able only test usecases I have while someone who added code may had something non-trivial in mind...
20:22.13d1masremove is = remove it
20:25.37Qwelld1mas: it has something to do with muting DTMF in app_meetme (and app_queue for some reason) on zap channels
20:26.35QwellI guess so they aren't just passed through to the conference?
20:26.52Qwellor, more likely, other zap channels that are in the conference
20:30.33mvanbaak21:10 <          d1mas> btw, it seems you need something like janitor project to convert all apps to use AST_DECLARE_APP_ARGS / AST_STANDARD_APP_ARGS
20:30.39mvanbaakthat's already there
20:31.08d1masqwell: I searched the sources for usage so I know about MeetMe. Hoewver my understanding is that DSP squelches DTMF tones from the voice data so they should not pass to MeetMe anyway
20:31.46Qwelld1mas: I suspect that it's because of how frames are passed between zap channels in a meetme conf
20:32.41d1masqwell: this can be true. Who knows how they are passed?
20:33.40d1masI mean does MeetMe in case of Zap channels behaves any differently compared to MeetMe for SIP channels ?
20:34.12Qwellyes, iirc, the frames don't come back into asterisk from zaptel...or something like that
20:34.20d1masomg
20:34.26Qwellbetween zap channels
20:34.34d1maswell,,,,
20:34.47QwellI don't recall exactly what it did, but it was a bit odd
20:35.03d1masbut in this case any conference muting _in the asterisk_ does not have any sense...
20:35.21d1masif frames do not go there
20:35.21Qwellit appears to mute that user in the conference
20:38.12d1masqwell: right but it will only mute user when it detects DTMF in the voice stream. if zap channel decides to distribute some voice frame to other participants of the conference obviously it should do it after passing to DSP (to properly mute user)
20:38.37d1masbut if frame was passed to DSP, there is no sense in muting because DTMF tone already removed from the frame by the DSP code
20:39.07d1mas(unless NOQUELCH option is set to DSP)
20:39.11Qwellright...
20:40.36d1masso I do not understand why muting is needed :)
20:42.42d1masqwell: by the way IF that MUTECONF is really needed - the current implementation is buggy. I have explained what is wrong to the -dev list some time ago
20:43.40Qwellbuggy how?  I must've missed that thread
20:44.24d1masone sec
20:45.41d1masqwell: http://lists.digium.com/pipermail/asterisk-dev/2008-January/031650.html  see PS
20:59.40d1masqwell: I have to go now, will try to catch you later. If you know how these things [should] work, please take a look on my email
21:16.37*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
21:36.26*** join/#asterisk-bugs mvanbaak_ (n=michiel@vanbaak.xs4all.nl)
22:40.59*** part/#asterisk-bugs jmls (n=jmls@81.138.42.77)
22:48.18*** join/#asterisk-bugs jmls (n=jmls@81.138.42.77)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.