Re: [asterisk-dev] rel eng suggestion: -current tgz
- Marc Blanchet [EMAIL PROTECTED] wrote: for all tar files in http://ftp.digium.com/pub/asterisk/releases/ such as: ln -s asterisk-1.2.9.1.tar.gz asterisk-current.tar.gz same for other tgz... Already done :-) -- Kevin P. Fleming Senior Software Engineer Digium, Inc. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Zaptel Bug in today's trunk?
Checked out Zaptel trunk yesterday and today. Recompiled libpri and asterisk with both. Ztcfg shows 31 channels configured (TE405P with 1 span configured). Starting asterisk fails with: ... Jun 21 14:52:06 DEBUG[7216] chan_zap.c: Updated conferencing on 23, with 0 conference users Jun 21 14:52:06 VERBOSE[7216] logger.c: -- Registered channel 23, PRI Signalling signalling Jun 21 14:52:06 ERROR[7216] chan_zap.c: Channel 24 is reserved for D-channel. Jun 21 14:52:06 ERROR[7216] chan_zap.c: Unable to register channel '17-31' Jun 21 14:52:06 WARNING[7216] loader.c: chan_zap.so: load_module failed, returning -1 Jun 21 14:52:06 VERBOSE[7216] logger.c: == Unregistered application 'ZapSendKeypadFacility' ... Jun 21 14:52:06 VERBOSE[7216] logger.c: -- Unregistered channel 22 Jun 21 14:52:06 WARNING[7216] loader.c: Loading module chan_zap.so failed! Reverting to an earlier zaptel trunk version solves the problem. Almost seems like it got hardcoded for a T1. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] The app_lock mutex in chan_agent.c
Short of a dev conference call earlier this week to discuss, based on JackEStorm's posts in #asterisk-bugs about his research into deadlock issues with chan_agent/app_queue I've now also taken a harder look at chan_agent.c this past week and I'm coming up with blanks at this point trying to understand why we need to make use of the app_lock mutex at all on a chan_agent channel when the agent is working in callback mode. When not in callback mode, we definitely need this to forego competition between the login app and the owning channel, but in callback mode, the login app has already long ago exited the scene and there seems to already be adequate protection that exists today within the code that prevents a second call from getting built on top of an agent_pvt that already has an active call up. With the ever changing ways that we're trying to manage transfers and other complex operations within the channel technologies, it seems like it's becoming more common place that the thread handling agent_hangup(...) for a given agent channel is not always going to be the same thread that locked the app_lock mutex within agent_request(...). That being the case, I'm seeking advice/comments on doing away with the use of the app_lock mutex with agent channels when in call back mode. Comments greatly appreciated. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Including external C++ Module
Hi all, Already i posted one question in one forum, could you please guys reply my questions, actually i did not post here because in forum i found some user friendly to describe as a code etc... http://go4calls.com/viewtopic.php?t=21 Thank You _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
