RE: [Asterisk-Dev] Potential debuggin patches for chan_sip.c
I second this, and I think that I may even be capable of using my meager skills to help along with this. I think it would be useful to have a debug info for just a certain peer in channels, as well as more straightforward debug information as far as PRI's and T1's are concerned. Anyone else have any input? Also, just as a sidenote, some minor changes in how some info is outputted would be useful. For instance, for parsing purposes, it would be easier if at the end of show channels, rather than outputting X active channels, it outputted Active Channels: X Simple things like that tend to make parsing easier if your playing with managing Asterisk. Comments? Flames? Additional Input? Derek Samford -Original Message- From: Bill Moran [mailto:[EMAIL PROTECTED] Sent: Fri 5/28/2004 1:33 PM To: [EMAIL PROTECTED] Cc: Subject:[Asterisk-Dev] Potential debuggin patches for chan_sip.c We had a lot of trouble getting a ZyXEL phone to work with Asterisks ... it turned out to be a configuration problem on our part, but using the debugging information to track it down was beyond difficult ... it was impossible. The only way I finally figured it out was to add a bunch of additional debugging statements to chan_sip.c Unfortunately, chan_sip.c has already been updated in CVS, so it's gonna be a PITA for me to post a patch. Thus my first question: I assume I'm not the only one who thinks there's not enough debugging info ... is the team interested in my patches? If so, I'll get the latest from CVS and figure out how to get good patches made. My second question is related: I added a few ast_log() statements to find_peer(), yet they never show up when asterisk is started with -vvv. Any hints as to why this is? Is find_peer() somehow unable to log? -- Bill Moran Potential Technologies http://www.potentialtech.com ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev <>
Re: [Asterisk-Dev] Time to lock down v1.1?
On Fri, 2004-05-28 at 19:33, Steven Critchfield wrote: > I think from watching the -cvs list, some of the patches can't be > brought backwards without also bringing back some of the major changes. Very true > As version numbers are just arbitrary pointers at a point in source code > time, don't get too worried about the label. To make all those that are > currently making noise happy, maybe it should be put forth that current > stable has a version number and is abandoned. Then you place a new > feature freeze on -head and fork a new -head off and go from there. I would second that notion - let's get 1.0 released so that we can move on from it asap. There have been a significant number of bugfixes since 0.9.0 (e.g. IAX timestamps) so at least a 0.9.x release seems due > It will not address software quality, but it will make some people > happier to see version increments. Also it might get some of those who > wouldn't run a cvs version ever to install a more recent tagged release. > At this point it is easier to diagnose some of those problems. This is the reason why: packagers rarely package CVS releases. Most users prefer packages. Personally this is the first project I've got into where I've had to get really dirty with CVS...previously there have only been short periods where I've had to run a CVS snapshot for a very specific new feature & then it was back to a formal release... > I might feel better about my pending upgrade to -head on a production > machine if I knew for sure that x% of the list was running it and had > experienced no trouble in their test environment where the value of x > was sufficiently large. As I know that isn't a true identifier of > quality or thoroughness of testing, I'll just have to add myself to the > x when I get there. Personally I'm very happy with HEAD - updates only break it occasionally. However, my system is fairly simple right now... F ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Time to lock down v1.1?
On Fri, 28 May 2004, Steven Critchfield wrote: > As version numbers are just arbitrary pointers at a point in source code > time, don't get too worried about the label. To make all those that are > currently making noise happy, maybe it should be put forth that current > stable has a version number and is abandoned. Then you place a new > feature freeze on -head and fork a new -head off and go from there. > > It will not address software quality, but it will make some people > happier to see version increments. Also it might get some of those who > wouldn't run a cvs version ever to install a more recent tagged release. > At this point it is easier to diagnose some of those problems. Why not simply mirror the Linux development method? -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Time to lock down v1.1?
On Fri, 2004-05-28 at 12:39, Linus Surguy wrote: > > 1.1 (today's head) is more of a "let's try if this works' release. > > Please spend time testing it. Remember, CVS HEAD, is not meant to be > > stable. Now and then, it might not even compile cleanly. It's > > a developer's release, at some point in future aimed to be stable. > > Surely this is the reason of most peoples complaints today, all of us who > are using Asterisk in real world, commercial environments get extremely > frustrated when 'key' issues get fixed in the 'head' release, for example, > recent fixes for IAX and SIP voice quality, and are not back ported to the > stable/release/whatever version. > > It leaves us in a very difficult position, as commercially we are placing > our users at unnecessary risk by using the 'head' version to get a specific > bug fix, but also giving them poor service if we stick with the 'broken' > version. I'm current;y in a similar position, so I feel some of this exact pain. > Please can those responsible have some understanding of this, as a rule > would it not make sense that all (or at least all major) 'fixes' go into > both after being appropriately tested, and keep 'head' for the more > 'bleeding edge' new features and more radical changes etc? I think from watching the -cvs list, some of the patches can't be brought backwards without also bringing back some of the major changes. As version numbers are just arbitrary pointers at a point in source code time, don't get too worried about the label. To make all those that are currently making noise happy, maybe it should be put forth that current stable has a version number and is abandoned. Then you place a new feature freeze on -head and fork a new -head off and go from there. It will not address software quality, but it will make some people happier to see version increments. Also it might get some of those who wouldn't run a cvs version ever to install a more recent tagged release. At this point it is easier to diagnose some of those problems. I might feel better about my pending upgrade to -head on a production machine if I knew for sure that x% of the list was running it and had experienced no trouble in their test environment where the value of x was sufficiently large. As I know that isn't a true identifier of quality or thoroughness of testing, I'll just have to add myself to the x when I get there. -- Steven Critchfield <[EMAIL PROTECTED]> ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Time to lock down v1.1?
> 1.1 (today's head) is more of a "let's try if this works' release. > Please spend time testing it. Remember, CVS HEAD, is not meant to be > stable. Now and then, it might not even compile cleanly. It's > a developer's release, at some point in future aimed to be stable. Surely this is the reason of most peoples complaints today, all of us who are using Asterisk in real world, commercial environments get extremely frustrated when 'key' issues get fixed in the 'head' release, for example, recent fixes for IAX and SIP voice quality, and are not back ported to the stable/release/whatever version. It leaves us in a very difficult position, as commercially we are placing our users at unnecessary risk by using the 'head' version to get a specific bug fix, but also giving them poor service if we stick with the 'broken' version. Please can those responsible have some understanding of this, as a rule would it not make sense that all (or at least all major) 'fixes' go into both after being appropriately tested, and keep 'head' for the more 'bleeding edge' new features and more radical changes etc? Linus ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Potential debuggin patches for chan_sip.c
We had a lot of trouble getting a ZyXEL phone to work with Asterisks ... it turned out to be a configuration problem on our part, but using the debugging information to track it down was beyond difficult ... it was impossible. The only way I finally figured it out was to add a bunch of additional debugging statements to chan_sip.c Unfortunately, chan_sip.c has already been updated in CVS, so it's gonna be a PITA for me to post a patch. Thus my first question: I assume I'm not the only one who thinks there's not enough debugging info ... is the team interested in my patches? If so, I'll get the latest from CVS and figure out how to get good patches made. My second question is related: I added a few ast_log() statements to find_peer(), yet they never show up when asterisk is started with -vvv. Any hints as to why this is? Is find_peer() somehow unable to log? -- Bill Moran Potential Technologies http://www.potentialtech.com ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Users] Re: [Asterisk-Dev] Time to lock down v1.1?
On Fri, 28 May 2004, Olle E. Johansson wrote: > Rich Adamson wrote: > > It's a known fact that bugs are not being fixed in Stable, and even Mark > > has suggested no one should be running Stable in a production environment. > > > On the other hand, there's not many bugs open in the bug tracker. Feature > requests and patches, but not bugs. > > If you are aware of bugs in stable or head, please report them a.s.a.p. > so we can start fixing them. > > Life as a bug marshal has been quite easy for a while, with Mark fixing > bugs like crazy and not many new bugs being reported. I guess you do not > want the bug marshals to fall asleep and live a bug-free life :-) > > 1.0 will be the stable release. There hasn't been many fixes to that > one lately, only MAJOR bug fixes has been applied. It will not be relased > according to any plan, remember - this is Open Source. It will be released > when considered stable with no open bugs. Wew.. after reading the last post, I had to stop and think if I was going crazy or not! Just for the record and to make sure that my understanding is correct, 1.0 is frozen and no NEW features are being added to that tree, correct? Aside from Major fixes, 1.0 is very near a release candidate. I might suggest that some of the IAX2 and SIP bugs (RTP Timestamps, etc..) be applied to Stable (for all I know they already might be) but otherwise, we start moving towards a 1.0-rc1 archive. I'll RPM up whatever you guys decided to drop, and continue to run 1.0_stable on my production boxes and provide feedback to the Bug Marshalls. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Time to lock down v1.1?
Rich Adamson wrote: It's a known fact that bugs are not being fixed in Stable, and even Mark has suggested no one should be running Stable in a production environment. On the other hand, there's not many bugs open in the bug tracker. Feature requests and patches, but not bugs. If you are aware of bugs in stable or head, please report them a.s.a.p. so we can start fixing them. Life as a bug marshal has been quite easy for a while, with Mark fixing bugs like crazy and not many new bugs being reported. I guess you do not want the bug marshals to fall asleep and live a bug-free life :-) 1.0 will be the stable release. There hasn't been many fixes to that one lately, only MAJOR bug fixes has been applied. It will not be relased according to any plan, remember - this is Open Source. It will be released when considered stable with no open bugs. 1.1 (today's head) is more of a "let's try if this works' release. Please spend time testing it. Remember, CVS HEAD, is not meant to be stable. Now and then, it might not even compile cleanly. It's a developer's release, at some point in future aimed to be stable. And, as always, when reporting, don't forget to report which version you are running, on which platform. /O ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Time to lock down v1.1?
Isn't it about time to lock down added functionality to v1.1 and fix the remaining bugs? There has been a significant amount of traffic on the cvs list, the irc and other channels with folks spending time adding new functionality to Head. Think its time to lock it down, fix the bugs that have been introduced, and get to "something" that the _majority_ can agree to call v1.1 Stable in real production terms. It's a known fact that bugs are not being fixed in Stable, and even Mark has suggested no one should be running Stable in a production environment. There has been a number of postings in the last few days relative to bugs in sip, iax2, zaptel, codecs, etc. The add-on folks are obviously also having problems keeping up with modifying patches to a constantly moving target, and applying those to Stable is fruitless. I'd even suggest that no v1.2 Head be created until such time as the majority of bugs are fixed, and that souce _then_ copied to whatever the next version is going to be called. All in favor? ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Callingcard (again, sorry!)
Hi again, Sorry for the late reply (not that anyone was necessarily waiting for one) - and thanks as well for all the replies to my original query. I went away on a short trip, hence my disappearance. Using the CDR is a good idea, so I went and toyed around with this. Using the time stamp made by my AGI application isn't feasible since the problem at hand is the time stamp being made irrespective of whether the user actually continues with the call or not (hence billing them even though they bailed out before continuing). I have two comments regarding the CDR however, which perhaps someone can comment on : 1. I notice AGI documentation saying that calls should be 'Answered'. Doing this results in the call duration and bill seconds being exactly the same - rendering it useless since I want the bill seconds of the call only, not the speech output of the calling card itself. Turning off the 'answer' seems to still work (so it's not really needed then is it?) , and also fixes this problem. 2. In the newer versions of Asterisk one is warned to use DeadAGI and not AGI when hanging up. So I did. And as a result the CDR changes all the logged calls to having dialed extension 'h', rather than the original number dialed. Which is stupid. I want the original number dialed. So now I ignore the warning and continue to use AGI on hangup instead of DeadAGI and this addresses my problem. Can someone tell me again what DeadAGI is actually supposed to achieve? Seems pretty useless to me. And yeah, doing it in C is definitely better than running a PHP script every time but... well... I know know PHP :-( - Terence On 19 May 04, at 7:44 PM, Apollon Koutlides wrote: Terence Parker wrote: app_agi.c:1511 agi_exec: If you want to run AGI on hungup channels you should use DeadAGI! I'm developing a prepaid platform myself on asterisk (will be in a release-able state soon enough, I hope) and encountered the charge-on-termination dilemma myself. Initially I tried to go for the hangup extension, but ended up using the CDRs which I would have to consult anyway. I am currently checking two different approaches: a) use csv CDRs, open the file in pipe mode, capture new records, charge customer and store charging record to database. b) use postgres CDRs and triggers to implement charging. The second approach has some extra merit, since you can host the charging engine outside the asterisk box. I intend to experiment with the radius application too, at some point in time. I am also using pretty complex tariffs, and have created a daemon to do tariff lookups - this helps a whole lote to improve redundancy and offload the * box. Just my Eu 0,02 :) Apollon Koutlides ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
