Re: [asterisk-dev] Call Specific MOH
Steve Murphy wrote: On Wed, 2007-03-28 at 18:08 +0200, Vadim Lebedev wrote: Hello, I'm attaching a trivial patch to app_queue.c allowing call-specific MOH. This functionality was needed to for our client who provides virtual secretary services, so it could implement DID-specific MOH messages I hope it can be integrated in mainline Is there anything you can't do here, that can't already be done in the dialplan? I have my home system play MOH based on the CID of the incoming caller, and ALSO, based on who they want to talk to. If I can do that in the dialplan, can't you also do your thing there? murf When i've tried to to this in dialplan, at the moment the call was assigned to a queue, the queue's MOH takes over. Hence the patch... Vadim P.S. Of course i'm not (yet) an Asterisk guru so maybe i've missed something, if you can send me your dialplan and queues.conf i'll be very grateful ___ --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 New CDR system
FYI-- I've been collecting all the CDR related bugs. I have a branch, team/murf/bug8221-1.4, where I've been testing out fixes to problems reported. I'm about to clean it up and commit it to 1.4 and trunk. If there's one thing I've concluded, it's that there are some problems with the CDR system, and something different is in order. And, after yesterdays Oldest 15 phone conference, with the CDR discussion afterwards, just what exactly the new CDR system should be, is beginning to gel. First of all, why a **new** CDR system? Well, to put it plainly, the old days of one call, and it's corresponding one CDR, are over. It might have been fine for Ma Bell to bill from when all that happened was, you dial a number, and two people talk, then you both hang up. But things aren't that simple any more! There's parking lots, 3 way conferences, conference rooms, transfers, blind and attended, call forwarding, findmefollowme, masquerading, queues, etc. etc., and the billing requirements can get quite tricky! 1. There will be a configuration file choice, as whether to use the OLD CDR system (the current one we all know and love), and the NEW config system, the one I'm about to describe. By default, in trunk, it will be OLD. Maybe in 1.8, it will default to NEW, and in 1.10, OLD will disappear, maybe. Maybe not. 2. The record format will change. Currently, each CDR has room for 3 events: start (usually channel creation), answer (from a dial operation), and end (usually when the CDR is to be closed and posted, usually a hangup, or transfer, etc.). The new CDR record will record only 1 event, and be immediately posted. For the sake of the database backends, these fields are currently output: calldate (date/time) (odbc, pgsql, mysql) start (date/time)(tds, radius, sqlite answer (date/time)(tds, radius, sqlite end (date/time)(tds, radius, clid (odbc, tds, pgsql, mysql) src (odbc, tds, pgsql, mysql) dst (odbc, tds, pgsql, mysql) dcontext (odbc, tds, pgsql, mysql) channel (odbc, tds, pgsql, mysql) dstchannel (odbc, tds, pgsql, mysql) lastapp (odbc, tds, pgsql, mysql) lastdata (odbc, tds, pgsql, mysql) duration (int) (odbc, tds, pgsql, mysql) billsec (int) (odbc, tds, pgsql, mysql) disposition (odbc, tds, pgsql, mysql) amaflags (int) (odbc, tds, pgsql, mysql) accountcode (odbc, tds, pgsql, mysql) uniqueid (odbc, tds, pgsql, mysql, sqlite(option), ) userfield (odbc, pgsql, mysql, sqlite(option), ) The calldate timestamp vs. start, answer, end timestamps was a bit of mystery to me, so I checked it out... in mysql,pgsql,odbc, it's the start time; my guess is that billsec/duration fields are the important ones, and the calldate maybe just serves to help sort the records. The new CDR output format will drop the start/answer/end/calldate fields, and instead have a single eventdate field instead. It will add an eventtype field that contains a standardized event name, START, HANGUP, ANSWER, APP, BRIDGE, for now, with possibilities like PARK, TRANSFER, CONF_START, CONF_END, and others, that we should nail down completely before beginning. Some of the other fields don't make sense any more in this sytem. dst might not be known until after a dial, say. lastapp and lastdata would most likely turn into just App and AppData, and only be meaningful if the event type is APP; duration and billsec would disappear, as the users would have to the calc themselves, based on their own criteria; disposition would probably only be meaningful with certain eventtypes; amaflags, accountcode, userfield would probably be output with every event-type. The software to generate billing data would probably get a little more complex, but should be able to generate the proper numbers from much more accurate and clear data. 3. CDR's would follow the life and activity of a channel in Asterisk. Each channel is assigned its uniqueid, and BRIDGE and CONF_START events, and similar, will record both channels so channel activity can be linked. The uniqueid field in the cdr records can be used to link all the events that happened on a channel for a particular call. When two channels are linked, the necessary uniqueid's will be available to link things up. A confID might be necessary to tie calls into conference rooms together. 4. Either we can assign events a level number, and allow the user to specify via the config file, at what level they wish to log, or we can allow the user to specify in the config file exactly what events they wish to track, and even restrict which apps they wish to track as well, if not all of them. Only those events specified in the config file would be logged, hopefully reducing storage requirements and clutter. For those interested in Deep Dialplan
Re: [asterisk-dev] 1.4 spanish sounds
I have a neighbor who grew up in Colombia and he insists that Colombians speak the purest form of spanish - maybe having a Colombian do the recordings is the solution? I don't think the colombian spoken spanish is the purest at all. Even in Argentina they pronounce the J letter much differently from chileans or people from Spain. It's better, and right, to ask a person native from Spain to do that. Just for the record, TV Shows and Movies translations for Latin American are made in Mexico City. Why? IMHO it's not about purity, I think is about entonationless, modismless thing. Spanish guys like to have all in their own language with their own modism, (In the same way they like fichero for file rather than archivo, or ordenador rather than computadora for computer..) -- Are you a turtle? ___ --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] Call Specific MOH
On Wednesday 28 March 2007 11:08, Vadim Lebedev wrote: I hope it can be integrated in mainline Why not just use the SetMusicOnHold application in the dialplan? -- Tilghman ___ --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] Feature request: SIP tx/rx gain
Manuel Wenger wrote: Hi everyone, there's a feature we are missing from chan_sip: the possibility to adjust a SIP peer's/user's TX/RX gain. The reason for this is that we have an upstream PSTN-to-SIP provider which converts their SS7 links directly to SIP without reducing gain on the line. The result is that PSTN calls are much louder than regular SIP-to-SIP calls. We would like to add, say, txgain=-10 and rxgain=-10 to the SIP peer configuration, so that all audio coming/going from/to that peer will be made quieter (or louder). I reckon that there would be some DSP programming involved in this, if I'm not mistaken... The PSTN provider is using a softswitch where rx/tx gain can only be adjusted on an SS7 trunk basis. The trunks are shared among several customers, therefore they won't adjust the gain for us. Is there anyone who would be willing to create this feature? Is this something for a bounty? Or should we plain forget about it? I've actually written two different patches for this to solve pretty much the same problem: 1. A SIP-channel only patch that works for alaw/ulaw (a bit of a kludge) 2. A technology independent patch that works for all codecs[1] that adds a SetGains(txgain,rxgain) function for adjusting incoming channels, and adds a V(txgain:rxgain) flag to Dial() for outgoing channels (much less of a kludge). Currently both patches are against the 1.2.x branch. Want me to send one/both through to you? Or should I wait until you offer a bounty... ;-) Cheers, Nic. [1] Although it'll add a transcode step to linear PCM and back in the middle, which if you're using expensive codecs will chew extra CPU and add delay (and if you're using G.729, will chew through your channel licenses). -- Nic Bellamy, Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/ ___ --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] The New CDR system
On Thursday 29 March 2007 18:27, Nicholas Campion wrote: Would it be possible to include the capability for channels to put out channel specific information? For example, it would be really nice if the SIP channel would put out the $RTPAUDIOQOS as you currently have to store this information in the userdata field in a CDR to get it to store with the CDR information. Essentially, I think we need a better way to extract the SIP (and hopefully other channels) quality of service information. It seems like the CDR is at least a semi-logical location for this to reside currently. I think the new scheme should try and make this, and other channel dependent information, more easy to access. Yes. We're considering an application along the lines of CDREvent(), to create a distinct event from the dialplan, in much the same way that UserEvent() creates a custom event from the dialplan to the Manager interface. -- Tilghman ___ --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] Call Specific MOH
On 3/29/07, Tilghman Lesher [EMAIL PROTECTED] wrote: On Wednesday 28 March 2007 11:08, Vadim Lebedev wrote: I hope it can be integrated in mainline Why not just use the SetMusicOnHold application in the dialplan? Because app_queue won't observe that. This patch is valid, but we need to follow protocol to get it in. -- 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] The New CDR system
I think this is an excellent idea. Both the CDREvent() and the new CDR method. -Jonathan -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-dev- [EMAIL PROTECTED] On Behalf Of Tilghman Lesher Sent: Thursday, March 29, 2007 8:16 PM To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] The New CDR system On Thursday 29 March 2007 18:27, Nicholas Campion wrote: Would it be possible to include the capability for channels to put out channel specific information? For example, it would be really nice if the SIP channel would put out the $RTPAUDIOQOS as you currently have to store this information in the userdata field in a CDR to get it to store with the CDR information. Essentially, I think we need a better way to extract the SIP (and hopefully other channels) quality of service information. It seems like the CDR is at least a semi-logical location for this to reside currently. I think the new scheme should try and make this, and other channel dependent information, more easy to access. Yes. We're considering an application along the lines of CDREvent(), to create a distinct event from the dialplan, in much the same way that UserEvent() creates a custom event from the dialplan to the Manager interface. -- Tilghman ___ --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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.20/737 - Release Date: 3/28/2007 4:23 PM ___ --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
