Re: [asterisk-dev] Real-time call control for Dial app
> Original Message >From: Gaspar Zoltan <[EMAIL PROTECTED]> >To: Asterisk Developers Mailing List >Sent: Friday, 6 July, 2007 5:16:17 AM >Subject: Re: [asterisk-dev] Real-time call control for Dial app > >Hi, > >Why don't you URL escape the special chars in the agi://? > >Zoltan Hi Zoltan, I could do that ok for the FastAGI app URL parameters but I couldn't do it for the colon in agi://. Or if I wanted to use NoOp(test) as the application I need to somehow escape the closing bracket so it doesn't get interpreted as the end of the L options. Regards, Greyman. Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. http://au.docs.yahoo.com/mail/unlimitedstorage.html ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] SIP library question
Hello, My apologies if this is a bit off-topic... I need to generate some SIP messages in code, in particular ACKs with SDP session parameters. Can anyone recommend a light-weight, open-source library that I can use for this purpose? Thanx! ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Real-time call control for Dial app
Hi, Why don't you URL escape the special chars in the agi://? Zoltan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man Sent: Friday, July 06, 2007 6:25 AM To: asterisk-dev@lists.digium.com Subject: [asterisk-dev] Real-time call control for Dial app Hi, I need to implement real-time call control within asterisk i.e. rather then just setting a time limit at the start it needs to be preiodically checked in case the caller has run out of credit due to simultaneous calls or such. Thankfully KNK has submitted a patch that does most of the work http://bugs.digium.com/view.php?id=6335 (without that I'd be struggling). I have a modified patch working pretty well but have a question regards the way it can be implemented with the Dial command. KNK used some global variables in the dial plan to set the real-time call control application (or recheck application) however I don't think that's an ideal way to do it as it will affect every call of the Dial appication and it's most likely that there will be cases where the check isn't required. As such I've changed the patch to accept the application as a parameter of the Dial command along the lines of: "L(x[:y][:z][:rtccapp]) - Limit the call to 'x' ms. Play a warning when 'y' ms are\n" " left. Repeat the warning every 'z' ms. Call real-time call control applciation 'rtccapp'\n" Initially I was thinking: L(x[:y][:z][:rtccapp[:rtccfreq]]) where rtccfreq is a period in milliseconds at which the rtccapp should be called but since the application I will be using is FastAGI the colon after agi://... made that tricky. The other problem with having the rtcapp as a parameter is that the first instance of a closing bracket ) indicates the end of the L options. So my question is would anyone have any ideas about a good approach to be able to use "difficult" strings as parameters? Should there be an option to enclose a parameter in quotes of some kind and allow them to get passed in that way? The ideal string for what I need is: L(108000:6:3:Agi(agi://192.168.1.10:4573?app=rtcc):6) To allow that I'd need to write some custom parameter handling code which would deviate from the utility methods already in Asterisk and I thought I'd check here first in case there was a better idea. Regards, Greyman. Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. http://au.docs.yahoo.com/mail/unlimitedstorage.html ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Real-time call control for Dial app
Hi, I need to implement real-time call control within asterisk i.e. rather then just setting a time limit at the start it needs to be preiodically checked in case the caller has run out of credit due to simultaneous calls or such. Thankfully KNK has submitted a patch that does most of the work http://bugs.digium.com/view.php?id=6335 (without that I'd be struggling). I have a modified patch working pretty well but have a question regards the way it can be implemented with the Dial command. KNK used some global variables in the dial plan to set the real-time call control application (or recheck application) however I don't think that's an ideal way to do it as it will affect every call of the Dial appication and it's most likely that there will be cases where the check isn't required. As such I've changed the patch to accept the application as a parameter of the Dial command along the lines of: "L(x[:y][:z][:rtccapp]) - Limit the call to 'x' ms. Play a warning when 'y' ms are\n" " left. Repeat the warning every 'z' ms. Call real-time call control applciation 'rtccapp'\n" Initially I was thinking: L(x[:y][:z][:rtccapp[:rtccfreq]]) where rtccfreq is a period in milliseconds at which the rtccapp should be called but since the application I will be using is FastAGI the colon after agi://... made that tricky. The other problem with having the rtcapp as a parameter is that the first instance of a closing bracket ) indicates the end of the L options. So my question is would anyone have any ideas about a good approach to be able to use "difficult" strings as parameters? Should there be an option to enclose a parameter in quotes of some kind and allow them to get passed in that way? The ideal string for what I need is: L(108000:6:3:Agi(agi://192.168.1.10:4573?app=rtcc):6) To allow that I'd need to write some custom parameter handling code which would deviate from the utility methods already in Asterisk and I thought I'd check here first in case there was a better idea. Regards, Greyman. Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. http://au.docs.yahoo.com/mail/unlimitedstorage.html ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Violent Objections? CDR dst/dco ntext probs in 1.4+ when a macro is involved.
On Thursday 05 July 2007 16:31, Steve Murphy wrote: > On Tue, 2007-07-03 at 16:38 -0500, Tilghman Lesher wrote: > > The core is adequate at this point. What needs to happen is for > > the backends (finally) to take advantage of the CDR core features > > that have been there since 1.2 was released. > > which core CDR features are you referring to here? Arbitrary CDR variables. Until cdr_custom and cdr_adaptive_odbc, they have been completely unused, unless you built your own cdr backend (as I have done in the past). -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Violent Objections? CDR dst/dcontext probs in 1.4+ when a macro is involved.
On Tue, 2007-07-03 at 16:38 -0500, Tilghman Lesher wrote: > The core is adequate at this point. What needs to happen is for the > backends (finally) to take advantage of the CDR core features that have > been there since 1.2 was released. Tilghman-- which core CDR features are you referring to here? murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vsAddQueueMember
> "SC" == Steven Critchfield <[EMAIL PROTECTED]> writes: SC> That statement isn't exactly correct. Just because you "CAN" write SC> the code doesn't give you a vote. Think about the monkeys and SC> typewriters quote. The vote only counts when code has been SC> written, disclaimed, and presented for review. The merit is in the SC> code, not the ability to code. Also, I bet votes are for sale by several asterisk developers. You don't actually have to write the code yourself, bribing someone else works too. /Benny ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Increasing AST_PBX_MAX_STACK
On Thursday 05 July 2007 12:11, Wolfgang Alper wrote: > I just saw that the filed bug request was closed without fursther > actions and think that this is wrong. > > It seems that Asterisk does not allow a nesting of contextes with a > stacksize defined in AST_PBX_MAX_STACK (defaults to 128) > > However it might be, that this value defines the number of includes > of contextes instead, which is not the same thing. > > So i wonder wether this issue still exists. > With respect to AST_PBX_MAX_STACK, maybe someone can clarify what the > meaning of this constant really is. If you had read the bugnotes, you would have seen that my original estimation on what the constant was for was in error. There is no bug, and the reporter requested that it be closed. -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] app_queue behaviour
Hello, I'm struggling to understand the source code of app_queue in * 1.4.2 in the situation when all agents are replying SIP 486 busy here to incoming calls. I want to add a config option (strategy value == ringallnonbusy?) so that in this situation the call will leave the queue and will continue with the dial plan. Any suggestions please? Thanks Vadim ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users]AgentCallBackLogin vs AddQueueMember
- Original Message - From: "Russell Bryant" <[EMAIL PROTECTED]> To: "Asterisk Developers Mailing List" Sent: Thursday, July 05, 2007 5:21 PM Subject: Re: [asterisk-dev] [asterisk-users]AgentCallBackLogin vs AddQueueMember While we have retained the everything aspect, we are certainly throwing away the simple part. We have had some discussions of building an entirely new Queue system for Asterisk 1.6. Whether this happens or not, I would like to see at least a new built-in way of implementing callback agents, which satisfies the common use case and works for a vast majority of the call center installations. :-) Russell for president! And a new callbacklogin for asterisk! ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vsAddQueueMember
On Thu, 2007-07-05 at 10:45 -0500, Tilghman Lesher wrote: > On Thursday 05 July 2007 08:56, Senad Jordanovic wrote: > > Alex B. wrote: > > > 2007/7/5, Martin Vít <[EMAIL PROTECTED]>: > > >> Martin Schrott - thinking:systems wrote: > > >>> you are right, acting now is not needed, when callbacklogin will > > >>> be removed anywhere in future... But thinking how to realice > > >>> alternatives can't be so wrong. > > >> > > >> i'm voting to bring callbacklogin back! :-) > > > > > > So do I! :-) > > > > One more vote... > > I wasn't aware this was a democracy. My understanding is that this is a > meritocracy: if you can write the code to make it better, your vote > counts. That statement isn't exactly correct. Just because you "CAN" write the code doesn't give you a vote. Think about the monkeys and typewriters quote. The vote only counts when code has been written, disclaimed, and presented for review. The merit is in the code, not the ability to code. -- Steven Critchfield <[EMAIL PROTECTED]> ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vsAddQueueMember
On Thursday 05 July 2007 08:56, Senad Jordanovic wrote: > Alex B. wrote: > > 2007/7/5, Martin Vít <[EMAIL PROTECTED]>: > >> Martin Schrott - thinking:systems wrote: > >>> you are right, acting now is not needed, when callbacklogin will > >>> be removed anywhere in future... But thinking how to realice > >>> alternatives can't be so wrong. > >> > >> i'm voting to bring callbacklogin back! :-) > > > > So do I! :-) > > One more vote... I wasn't aware this was a democracy. My understanding is that this is a meritocracy: if you can write the code to make it better, your vote counts. The problem with AgentCallBackLogin was that the code was full of race conditions and it was abandoned because the functionality it provided could be done better in the dialplan. If you can fix AgentCallBackLogin to where it no longer has massive issues, then I think it would be welcomed. However, keeping buggy code around just so we can complain about it isn't a good way forward. -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vs AddQueueMember
Martin Vít wrote: > i'm voting to bring callbacklogin back! :-) Voting is nice and all, but it isn't going to get code fixed or new code written. :) Anyway, it's probably worth talking about why it was deprecated in the first place. I was never heavily involved in dealing with bugs related to callback agents. From what I can recall, the primary reason for deprecating this was because of the problematic implementation. Furthermore, people that had replaced this functionality with dialplan logic and dynamic queue members reported much better results. So, the easy way out of the situation was to deprecate the broken method and advocate the working one. I'm not terribly thrilled with removing callback agents unless we can replace it with something just as easy to use. I'm going to steal the quote that Tzafrir used in another thread: "make the common task simple, make everything possible." While we have retained the everything aspect, we are certainly throwing away the simple part. We have had some discussions of building an entirely new Queue system for Asterisk 1.6. Whether this happens or not, I would like to see at least a new built-in way of implementing callback agents, which satisfies the common use case and works for a vast majority of the call center installations. -- Russell Bryant Software Engineer Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vsAddQueueMember
Alex B. wrote: > 2007/7/5, Martin Vít <[EMAIL PROTECTED]>: >> Martin Schrott - thinking:systems wrote: >>> Hi Kevin, >>> Hi list, >>> >>> you are right, acting now is not needed, when callbacklogin will be >>> removed anywhere in future... But thinking how to realice >>> alternatives can't be so wrong. >>> >> i'm voting to bring callbacklogin back! :-) >> >> F > > > > So do I! :-) > > Alex One more vote... Senad ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vs AddQueueMember
2007/7/5, Martin Vít <[EMAIL PROTECTED]>: > Martin Schrott - thinking:systems wrote: > > Hi Kevin, > > Hi list, > > > > you are right, acting now is not needed, when callbacklogin will be removed > > anywhere in future... > > But thinking how to realice alternatives can't be so wrong. > > > i'm voting to bring callbacklogin back! :-) > > F So do I! :-) Alex ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vs AddQueueMember
Martin Schrott - thinking:systems wrote: > Hi Kevin, > Hi list, > > you are right, acting now is not needed, when callbacklogin will be removed > anywhere in future... > But thinking how to realice alternatives can't be so wrong. > i'm voting to bring callbacklogin back! :-) F ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] zaptel, menuselect and autoconf
Warning: long post follow. I have been looking at separating the kernelspace of zaptel from userspace: http://bugs.digium.com/view.php?id=7117 http://svn.digium.com/view/zaptel/team/tzafrir/kernelmove_14/ As you can see from the commits in that branch (rev. 2651), I ended up removing menuselect completely and using autoconf. Kevin and Russel did not like this idea. I'd like to point out here what problems I have encountered and suggest some solutions to the problems of menuselect. As I worked on cleaning up the build system of Zaptel I noticed that there are two major sources of mess: 1. Mixing userspace, kernel 2.4 and kernel 2.6 makefiles in the same file. Sorting that out has been the main focus of the branch. 2. menuselect: 2.1. Configuration still needs much parsing after inclusion (the common $(filter ) and even more common $(filter-out ) ). 2.2. A number of include files. 2.3. Configueration changes at make runtime This is why a fairly recent version of gnu make is needed, and also why 'make clean install' will try to build and install everything, regardless of the modules you have disabled in the menu. As there was great objection to simply removing menuselect, I tried figuring out what is it exactly that menuselect does. So following is my understanding as to the role of menuselect. Menuselect is mainly intended to allow the user to easily select the build-time configuration. Is build-time configuration really needed? " libpri and asterisk-gui don't use menuselect even today. And really, there's nothing to configure there. While asterisk-addons uses it, I believe that for the few options there the configuration through a configure script should do the trick. Zaptel is a borderline case. I like the configure syntax interface for in better: it makes the common cases (all, or just a specific module you need) easier and simpler than menuselect. But if folks really insisted on menuselect there, then whatever. Asterisk is really the application menuselect was designed for. However, is there really a point for the common user to disable building modules? Again: "make the common task simple, make everything possible". One problem with menuselect of today is that it makes it all too easy to accidentally building a module. Hence my standard instructions for building asterisk are "./configure; make", to avoid letting the builder shooting himself in the foot. Why is menuselect run from the Makefile? """ Menuselect is run after the configure script. It is run from the makefile. In the reverted commit above, all that logic has moved from the makefile to the autoconf script. What is the problem then? menuselect cannot apply its selection of modules. Menuselect can't even fix the lists of modules to satisfy dependencies. So I'll just run menuselect dependency checkingand be done with it, right? But this requires a built menuselect and mxml. And hence can only be run after ./configure . So I tried to rewite the dependency checking in an independent script I could run from the configure script. I played a bit with some XML parsers and realised that any of them will pull some non-standard libraries along the way. So the answer is: Because we store the configuration as XML and need to build the XML parser in order to read it. What does Menuselect do? In a default run of the makefile it is only used with the option --check-deps. In that case it will report if the configuration is OK or not. Alternatively it will run a menu and generate cinfiguration. It is not possible to ask it to just fix partial configuration. The main data file for menuselect is menuselect-tree which is a generated XML file. It is generated by a few simple shell scripts for a few "XML" files in the toplevel directories as well as data in modules. Those .xml files are not real XML files but rather snippers. In the process they are concatenated into the menuselect-tree XML file. Menuselect allows selecting items not to build. It will only generate a legal configuration: one in which all dependencies are satisfied. It also has an option to just go ever the current configuration and check of its configuration are satisfied. But then again, the XML data we use is not so complex. It is a tree with an exact depth of 3: a single toplevel menu, in it categories, an in each category there are members. So I would suggest selecting one of the following two alternatives: 1. Depend on some XML library to be available on the build system and use an existing parser program / module in the configure script, or: 2. Use simpler format for the data. (1) seems to me unrealistic. Hence I have opted for (2). Simpler Configuration Data Format " I have an initial implementation of this in the branch zaptel/team/tzafrir/kernelmove_conf . The data format I chose was to place each categor
