[asterisk-dev] What to do with RTCP ????
The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? /Olle ___ --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
RE: [asterisk-dev] What to do with RTCP ????
The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? I don't mind how it's reports, als long as it's relatively easy to correlate RTCP data to users. So adding some information to a CDR is fine. -- Andreas Sikkema BBned NV Software EngineerPlaneetbaan 4 +31 (0)23 70743422132 HZ Hoofddorp ___ --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
Re: [asterisk-dev] multithreaded IAX
that'll surely increase scalability, when the bugs are ironed out. well done, mark ! Bugs? We've been beating it up for like 3 hours now and it seems to be dealing with things quite nicely. Is the impact of this change primarily oriented toward the registration process, or will it also have an impact on established sessions when multiple iax links are involved? ___ --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
Re: [asterisk-dev] multithreaded IAX
Hello, in case of stable working, is there any changes to backport into the stable 1.2 branch? Yes, I know, 1.2 is feature freezed, however such change could solve head-ache of many people running 1.2 in production (I don't know how it is bounded to the trunk version, if it is easy to backport or even impossible). I would be very happy to see such thing in a stable version [or is 1.4 release planned for the very near future?] Kind regards, Tamas Mark Spencer wrote: I just multithreaded IAX on the way back from Brussels. You can now specify a number of backend threads to handle processing of requests. It's rather likely that *something* if not everything broke (of course, it worked on my box), so I would appreciate any input from people on IAX performance. This should eliminate drop-outs with IAX calls and substantially increase the number of registrations permitted simultaneously. Thanks! Mark ___ --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
Re: [asterisk-dev] What to do with RTCP ????
On 2/27/06, Andreas Sikkema [EMAIL PROTECTED] wrote: The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? I don't mind how it's reports, als long as it's relatively easy to correlate RTCP data to users. So adding some information to a CDR is fine. Some integration with the CDR is fine, but I'd rather we make it available via a function so people can grab the data and do what they want with it. To have an RTCP logging channel via the existing logger facility might be an interesting thing too. I'd proably use that to throw it to some facility that throws up mrtg type graphs,etc. -- 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
Re: [asterisk-dev] Channel Bridging
It will probably require lots of changes, but ... What if there are few bridging engine threads (configurable to handle the load of the system with regards on available resources). When there is a new call to be bridged it should subscribe for bridging to the least loaded engine, which will handle it from that point. The engine should not do the actual frame exchange/mixing in any of the methods, but based on the number of channels, channel flags, features and received frame type may decide which bridging method to call (attach), to actually exchange the data or not to do so, when muted or suspended. This way, even in a conference, when there are just 2 channels to bridge, it will simply pass frames. If it's FAX/DTMF frame may process or pass it. Even local services (parking, MOH, VM, Echo, milliwatt ...) could be treated as a normal call leg in this case, so there could be just one instance for each MOH class used instead of one per channel on hold. The engine may check regulary if there is a new data in the channel, which should be OK even with silence suppression. The data may be passed to/from an independent from the channel configurable jitter-buffer, echo canceler and/or CNG, then to the other channel(s). As the bridge will create its config upon subscription for each channel, the features (as timeout and forward being enabled/disabled) won't be lost and may keep them until the last channel is closed or even some time afterwards (may also keep the data until all registered CDR engines have successfully stored their records so no record will be lost even if the database wasn't available for few minutes) The engine will not be closed even if there are no calls to bridge, but will wait for the next call. just my 0.02 On Sat, 25 Feb 2006 09:56:43 -0500, SteveK wrote Hello Folks, I thought I'd give a nice email to the list about some stuff I've been pondering/mucking with in regards to channel bridging. As it is right now, channel bridging is spread out across a few places -- enough that it gives me a headache just to think about it. We've got native bridges happening, generic bridges happening, and bridges with features, and who knows what else. In order to advance we need to come to a conclusion on how exactly we want bridges to work and what features they need to have. The rest of this post is my thoughts and ideas (some of which have already been implemented in my own testbed). 1. A bridge is a method of combining channels (even more then 2) together in order to exchange or mix frames. For a bridge consisting of more then 2 channels we can use zaptel pseudo channels to do audio mixing, while we would need to find another method of exchanging other frames for things such as DTMF. Personally, if you're going to do this inside asterisk, I'd do multi- party bridging the same way I do it in app_conference, and _not_ with zap pseudo channels. This works with complete frames, and can be much more efficient. But, I wouldn't use the exact same mechanism for mixing multiple parties that is used for mixing just two channels, because there is necessarily a latency penalty for doing so (this applies mainly to VoIP channels): A 2 party bridge can simply pass frames across as they are received, with no need for synchronization or proper ordering: A conference requires that the mixing be done synchronously, with frames in-order (i.e. a jitterbuffer needs to be present on incoming channels, and the mixing must be synchronous). I do agree that it would be good if the API for two-party and multiparty bridges were the same, though, but two-party bridges are such a common case that it makes sense to perform them optimally, and not use the lowest-common denominator for multi-party conferences. ___ --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 ___ --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
Re: [asterisk-dev] multithreaded IAX
On Sun, 2006-02-26 at 18:10 -0600, Mark Spencer wrote: I just multithreaded IAX on the way back from Brussels. You can now specify a number of backend threads to handle processing of requests. It's rather likely that *something* if not everything broke (of course, it worked on my box), so I would appreciate any input from people on IAX performance. This should eliminate drop-outs with IAX calls and substantially increase the number of registrations permitted simultaneously. Thanks! Look out Critch, this should spark off a few Why is * creating so many processes questions :) -- Dave Cotton [EMAIL PROTECTED] ___ --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
Re: [asterisk-dev] What to do with RTCP ????
27 feb 2006 kl. 13.00 skrev BJ Weschke: On 2/27/06, Andreas Sikkema [EMAIL PROTECTED] wrote: The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? I don't mind how it's reports, als long as it's relatively easy to correlate RTCP data to users. So adding some information to a CDR is fine. Some integration with the CDR is fine, but I'd rather we make it available via a function so people can grab the data and do what they want with it. A function is a good idea, but not a replacement for variables. We can do a function too, but the end report is only available at the end of the call, so a function would be of no use. The function can deliver the current data mid-call, but would be of limited use. To have an RTCP logging channel via the existing logger facility might be an interesting thing too. I'd proably use that to throw it to some facility that throws up mrtg type graphs,etc. -- Well, that would imply that we can log quality for other channels as well, so we need to come up with generic stuff to have a log that can handle both IAX2 and rtp-based channels. /O ___ --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
Re: [asterisk-dev] Long boring weekend ahead?
24 feb 2006 kl. 16.39 skrev Dave Cotton: On Fri, 2006-02-24 at 15:47 +0100, Olle E Johansson wrote: Dear Asterisk user and developer, I am sorry, but I have to tell you that there is a long boring weekend ahead of you. Nothing to do, bad weather and boring sports on TV. What to do? I have the solution for you: * TEST THE TEST-BRANCH OF ASTERISK !!! Tested. Doesn't compile :) Incomplete #ifndef line 123 channels/chan_zap.c needs an extra #endif ? Fixed. Run svn update and continue testing !!! Thanks for reporting it. /Olle ___ --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
Re: [asterisk-dev] What to do with RTCP ????
On Mon, Feb 27, 2006 at 10:48:06AM +0100, Olle E Johansson wrote: The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? /Olle Would love to see RTCP stats in a CDR. Currently have SER parsing RTCP reports out and doing things with them instead. Ray ___ --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
Re: [asterisk-dev] What to do with RTCP ????
On Mon, Feb 27, 2006 at 10:48:06AM +0100, Olle E Johansson wrote: The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? /Olle Would love to see RTCP stats in a CDR. Currently have SER parsing RTCP reports out and doing things with them instead. Ray 1) As far as how Asterisk presents information (regardless of this SIP-specific method) I would suggest that the data is available via channel variables. Functions and variables are equally useful as far as I'm concerned - is there a reason why one method would be preferred over another? 2) How difficult would it be to put the RTCP stats into the new SNMP structure? I'm not sure how useful this would be, since whatever SNMP query system existed would have to walk the tree (or be notified via a Manager link of some type) to obtain call lists and then monitor the calls. 3) Would a Manager-accessible method make sense here? I think that having the call quality data available to external Asterisk-compatible tools would be pretty interesting, and ultimately the most useful method to obtain real-time quality information for a NOC. (sorry if this is already in place; I've tested this patch a few times, but never tried to see what happens on the manager interface.) 4) If the variables were accessible in the dialplan at hangup, then something like my CQDR log could be created by a System call within the dialplan... http://lists.digium.com/pipermail/asterisk-dev/2004-May/004180.html 5) While not directly relevant to how Asterisk implements RTCP stats, this may be of interest as a method for many devices in a SIP call chain to monitor RTP quality of a particular call: http://www.ietf.org/internet-drafts/draft-ietf-sipping-rtcp-summary-00.txt JT ___ --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
Re: [asterisk-dev] What to do with RTCP ????
Paul Cadach wrote: Hello, Olle E Johansson wrote: The RTCP branch includes improved support of RTCP, but also a reporting facility we do not use currently. Would it be useful to add this to a channel variable - or even better a CDR variable - so you can add it to CDRs and make reports based on it? Mostly RTCP information can be used to adjust jitter buffering algorithms, arrange clocks when peer stopped transmission, etc. ..and be used to make decisions about in-call codec changes, but that something we can do later. I will try to create some data for CDR variables in the meantime, and a dial plan function. I also want to add a special thank you to folsson and john martin that has done the development on this patch. I still look froward to more test reports in the bug tracker :-) /O ___ --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] Bug 0006563: Asterisk 1.2.4 fails to send request for RFC2833
Many thanks for Casper for finding the problem that I referenced in bug 6563. Is there any chance that this change will make it into the released Asterisk, or should I expect always to have to patch it? Thanks, /edg ___ --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
