Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?
hw-- I see this kind of behavior when the certificate expires... you've probably checked this, but sometimes we miss little details like that. murf On Fri, Jul 5, 2019 at 1:14 PM hw wrote: > On 7/5/19 10:50 AM, Doug Lytle wrote: > > On 7/4/19 6:40 PM, hw wrote: > >> This has again, and for no reason, ceased to work again after > >> restarting asterisk. No matter what I try, I can't create a > >> certificate asterisk > >> would verify. > > > > Have you considered using LetsEncrypt for a valid certificate? > > > > Doug > > > > > > What would be the point in making this even more complicated? > > Today all of a sudden the certificate couldn't be verified anymore even > without restarting asterisk. How is it possible that a certificate > which was fine for 10 hours and 18 minutes suddenly can not be used > anymore? > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-0510 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Ports that voip hackers seem to be interested in
To any that might be interested, below is a list of ports, preceded by the frequency. Personally, I find it interesting that port 5038 is now of such interest to hackers. This data spans about a day of access attempts. A total of 67 systems (different source IP addresses) participated in this "survey". These were logged when we dropped their packets. 1 137 1 1521 1 161 1 2049 27 21 1 21007 25 22 1 23 1 29007 1 3044 1 3049 2 3128 1 3145 1 3306 1 3389 1 345 1 3496 1 3543 1 40007 1 4300 1 4337 1 4343 60 443 1 445 1 4451 1 447 1 4730 2 4786 1 4949 2 5000 1761 5038 2130 5060 1 5432 1 5911 1 5985 1 7000 1 7070 1 7547 1 7786 42 80 1 8000 3 8080 5 8088 1 8443 1 873 1 8889 1 9124 2 9191 I hope those of you with internet accessible systems are following best practices! murf -- Steve Murphy -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PJSIP Weirdness, or just my weirdness?
SOLVED! Many THANKS to George and Anthony! See at the very end, my comments... On Thu, Sep 8, 2016 at 5:58 PM, Anthony Joseph Messina < amess...@messinet.com> wrote: > On Thursday, September 8, 2016 1:12:36 PM CDT Steve Murphy wrote: > > Hello! > > > > Oh, wise ones, ponder with me over two of the surprises that > > populate the universe! > > > > > > I have a phone, that I sometimes cannot reach, connected via pjsip. > > It can call other extensions just fine, it can call out over a > > trunk to my cell, all is well, but getting a call? Forget it most of the > > time. > > > > Here is all the config relevant to that phone: > > > > > > [murftest12] > > type=aor > > qualify_frequency=1992 > > max_contacts=2 > > > > [murftest12] > > type=auth > > auth_type=userpass > > username=murftest12 > > password=SjU3 > > > > [transport-udp] > > type=transport > > protocol=udp > > bind=0.0.0.0:57969 > > > > > > [murftest12]; Cisco SPA514G mac=A4:93:4C:FE:1D:A2 > > type=endpoint > > auth=murftest12 > > transport=transport-udp > > aors=murftest12 > > moh_suggest=default > > force_rport=yes > > rewrite_contact=yes > > rtp_symmetric=yes > > dtmf_mode=rfc4733 > > disallow=all > > allow=ulaw ; from phonetype > > allow=g722 ; from phonetype > > allow=alaw ; from phonetype > > allow=alaw ; from phonetype (G.729 replaced with alaw) > > direct_media=no > > context=phone > > rtp_timeout=120 > > set_var=__phoneid=12 > > set_var=__contacttypeid=4 > > set_var=__phonelineid=78 > > callerid="Steve Murphy" <101> > > call_group=2 > > pickup_group=2 > > mailboxes=101@murftest > > language=en > > send_rpid=yes > > send_pai=yes > > > > OK, that completes the config (I hope). > > > > Now, when I run "pjsip show endpoints, I get: > > > > SFO02-HostedPBXPJSip-Dev03*CLI> pjsip show endpoints > > > > Endpoint: > > > > I/OAuth: .. > > ...> > > Aor: > > > > Contact: > > > > Transport: > > > >Identify: .. > > ...> > > Match: > > Channel: > > > > Exten: CLCID: > > === > > == > > > > Endpoint: murftest12/101 Not in > > use0 of inf > > InAuth: murftest12/murftest12 > > Aor: murftest12 2 > > Contact: murftest12/sip:murftest12@67.215.23.186:54 171a08228b > > Unavail 0.000 > > Contact: murftest12/sip:murftest12@67.215.23.186:21 d9a15f4e35 > > Avail50.514 > > Transport: transport-udp udp 0 0 0.0.0.0:57969 > > > > Note that there are TWO Contact: entries! one Avail, the other > Unavail... > > the show endpoints doesn't display all the URL, but the show contacts > does: > > > > Contact: murftest12/sip:murftest12@67.215.23.186:21800 d9a15f4e35 > > Avail50.514 > > Contact: murftest12/sip:murftest12@67.215.23.186:54004 171a08228b > > Unavail 0.000 > > > > None of my other phones have two contacts listed and this phone, a > > cisco-spa-514, has just one sip account... > > > > The trouble is, when I try to call it sometimes the INVITE is > directed > > to the "Unavail" entry, and the call never completes. The phone doesn't > > even ring then. Any ideas? I tried to get the "Unavail" entry out... I > > removed it from the db, I rebooted the phone, restarted asterisk, and it > is > > still there. > > > > MYSTERY #2: > > > > The above cisco-spa, when it calls out over the trunk, all is well, > > wonderful 2-way audio. > > But when I do the same operation from my yealink phones, I get my cell > with > > one-way audio. > > I just resolved a similar issue with a new Yealink phone and PJSIP. It > seems > that Asterisk (depending on many transcoding parameters and types of calls) > may send out a different codec on leg B than it receives on leg A. While > less > than optimal for the end user, this is allowed by the RFCs. Yealink > doesn't > seem to handle this well. The firmware referenced in this link fixed the > issu
[asterisk-users] PJSIP Weirdness, or just my weirdness?
Hello! Oh, wise ones, ponder with me over two of the surprises that populate the universe! I have a phone, that I sometimes cannot reach, connected via pjsip. It can call other extensions just fine, it can call out over a trunk to my cell, all is well, but getting a call? Forget it most of the time. Here is all the config relevant to that phone: [murftest12] type=aor qualify_frequency=1992 max_contacts=2 [murftest12] type=auth auth_type=userpass username=murftest12 password=SjU3 [transport-udp] type=transport protocol=udp bind=0.0.0.0:57969 [murftest12]; Cisco SPA514G mac=A4:93:4C:FE:1D:A2 type=endpoint auth=murftest12 transport=transport-udp aors=murftest12 moh_suggest=default force_rport=yes rewrite_contact=yes rtp_symmetric=yes dtmf_mode=rfc4733 disallow=all allow=ulaw ; from phonetype allow=g722 ; from phonetype allow=alaw ; from phonetype allow=alaw ; from phonetype (G.729 replaced with alaw) direct_media=no context=phone rtp_timeout=120 set_var=__phoneid=12 set_var=__contacttypeid=4 set_var=__phonelineid=78 callerid="Steve Murphy" <101> call_group=2 pickup_group=2 mailboxes=101@murftest language=en send_rpid=yes send_pai=yes OK, that completes the config (I hope). Now, when I run "pjsip show endpoints, I get: SFO02-HostedPBXPJSip-Dev03*CLI> pjsip show endpoints Endpoint: I/OAuth: Aor: Contact: Transport: Identify: Match: Channel: Exten: CLCID: === == Endpoint: murftest12/101 Not in use0 of inf InAuth: murftest12/murftest12 Aor: murftest12 2 Contact: murftest12/sip:murftest12@67.215.23.186:54 171a08228b Unavail 0.000 Contact: murftest12/sip:murftest12@67.215.23.186:21 d9a15f4e35 Avail50.514 Transport: transport-udp udp 0 0 0.0.0.0:57969 Note that there are TWO Contact: entries! one Avail, the other Unavail... the show endpoints doesn't display all the URL, but the show contacts does: Contact: murftest12/sip:murftest12@67.215.23.186:21800 d9a15f4e35 Avail50.514 Contact: murftest12/sip:murftest12@67.215.23.186:54004 171a08228b Unavail 0.000 None of my other phones have two contacts listed and this phone, a cisco-spa-514, has just one sip account... The trouble is, when I try to call it sometimes the INVITE is directed to the "Unavail" entry, and the call never completes. The phone doesn't even ring then. Any ideas? I tried to get the "Unavail" entry out... I removed it from the db, I rebooted the phone, restarted asterisk, and it is still there. MYSTERY #2: The above cisco-spa, when it calls out over the trunk, all is well, wonderful 2-way audio. But when I do the same operation from my yealink phones, I get my cell with one-way audio. It's a classic NAT situation: the phone system is in a droplet at digital ocean, but my phones are here at home behind a NAT. I see only 3 NAT related options: force_rport rtp_symmetric rewrite_contact and I set them all to "yes", and they can call each other, but as explained, in dialing out thru a trunk, the yealinks get one-way audio... Any more NAT options? many thanks... murf -- Steve Murphy ✉ murf at parsetree dot com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016 http://www.asterisk.org/community/astricon-user-conference New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 13 : SILK codec ?
On Wed, Oct 29, 2014 at 7:10 PM, sean darcy wrote: > On 10/29/2014 08:06 PM, Matthew Jordan wrote: > >> On Wed, Oct 29, 2014 at 5:16 PM, sean darcy wrote: >> >>> Can we expect a SILK codec for 13 ? Or does the one for 12 work for 13? >>> >>> >> codec_silk for Asterisk 12 will most likely not work in Asterisk 13. A >> number of performance improvements in the media handling in Asterisk >> required some codec compatibility changes. >> >> I would expect said modules to be available in the next few weeks. >> >> Great. Thanks. > sean > > I just checked at http://digium.com/en/products/asterisk/downloads, and of the "Add-On Voice Codecs", g.729 is the only one available for Asterisk 13. The Siren 7/14 and SILK codecs offer only 12.X selections, and I proved today that the 12.x codecs will not load on Asterisk 13. a "few weeks" has turned into almost half a year now. Are these codecs no longer going to be available for 13 and up? Or, were they just overlooked in the day-to-day rush called life? murf -- Steve Murphy ParseTree Corporation -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Interesting new hack attack
In the past little while, we've seen a wave of attacks on asterisk, via the provisioning. It goes something like this: A. scan for IP phones on the internet, either via spotting something on port 5060, or via the port 80 web interface for the phone. Or, use web sites that scan the internet, and classify the machines, to make your work shorter. B. Once you get into the web GUI, get the URL for provisioning. I haven't checked yet... do any phones actually allow you to set this, or do any display the current value? And, finally, how many phones publish their own MAC address in the GUI? Or, can you suck this out of the returned IP packets? C. Given the URL and the mac, fetch the phones provisioning info, including it's sip account info. Use to best advantage. D. Going further, set up a brute-force probe algorithm, to probe all possible mac addresses for a given phone manufacturer, via http requests. After all, those provisioning web servers are fast and efficient, aren't they? Collect all possible mac addresses and grab the provisioning, and now you have a LOT of sip accounts. Use to best advantage. And, professional hacking organizations seem to also follow these rules: a. wait several months for any history of the above activities to roll off the log files. Treat your phone systems like fine wine vintage. b. Use multiple (hundreds/thousands) of machines scattered over the earth to carry out the above probes, and also to use the accounts for generating international calls. In general, using the SIP account info gleaned from these kinds of efforts is a bit problematic. You see, to effectively use your phone system to place calls, they will have to set up their own phone system to act like a phone, and register to the phone system, and then initiate calls. Trouble is, your phone is usually already registered, but can be "bumped off". Your phone will re-register at intervals and bump the hackers, who will again register and bump your phone. This little game of "king of the hill" may show up in your Asterisk logs. So, these defenses can be employed to stop/ameliorate such hacking efforts: 1. Keep your phones behind a firewall. Travellers, beware! Never leave the default login info of the phone at default! 2. Never use the default provisioning URL for the phone, with it's default URL or password. 3. Use fail2ban, ossec, whatever to stymie any brute force mac address searches. 4. Use your firewalls to restrict IP's that can access web, ftp, etc, for provisioning to just those IP's needed to allow your phones to provision. 5. Keep your logs for a couple years. 6. Change your phone SIP acct passwords now, if you haven't implemented the above precautions yet. If I missed a previous post on this, forgive me. Just thought you-all might appreciate a heads-up. murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] stopping unwanted attempts
On Sat, Jan 18, 2014 at 3:59 PM, Steve Edwards wrote: > On Sat, 18 Jan 2014, Jerry Geis wrote: > > I see MANY of these in my log files: >> >> [Jan 15 03:06:12] NOTICE[14129] chan_sip.c: Registration from '"202" >> ' failed for '37.8.12.147:26832' - Wrong password >> >> What is the "correct" way to block these idiots so they >> don't even get this far. >> > > Use iptables to allow packets from your legitimate users, block everybody > else. > > If you are dealing with a mobile user base or an extensive geographic > area, at least block the countries where you do not expect traffic -- North > Korea, China, xxxistan, etc. > > Drop these at the front door (90% of the problem) and use fail2ban to pick > off the rest. > I see a problem here; firstly that it is no longer so simple to determine the IP ranges of countries. Things have been fractured quite a bit; you might have to hire out a service to determine true geographic origination. Even then, if your service is a little behind, you might occasionally feel the displeasure of users unable to talk to your servers. How will you handle this, with a white-list? How much effort will you end up committing to keeping your whitelist up to date? Nextly, the well-financed operations running such probes need not use machines in their native countries. There are plenty of US-based machines that can be ( and are ) compromised. In other words, don't forget the fail2ban part! Here's another idea! How about changing your port from 5060 to something different, maybe 7067 or some other number that is not popularly being used? You'll provision your phones to use this port, and the scanners will not find you. Seems a much simpler solution... but there are some drawbacks... can anyone think of them? And will these drawbacks matter to you? And, given this solution, will the odds that a scanner might find your machine be so low, that it is not worth using something like fail2ban to override them? Food for thought! murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] SaySentence update - CALL FOR HELP
I'm not going to bore you with all the stuff I've done since November here. I put it, and some examples, in the file update1.txt in the git archive. To read it, do a git clone of https://github.com/WyoMurf/SaySentence.git I a nutshell, I've upgraded the SayScript grammar to handle expressions in the file names, upgraded the current en, fr, it, hu, and some others, to use the same approach as say.conf. Upgraded the test suite. Finished converting Asterisk trunk (mostly) to use SaySentence internally. I'll make the Asterisk Community an offer. Somebody out there, I hope, would like to have Asterisk in his/her language, which is not yet coded into Asterisk. I offer to help you, whoever you are, to develop a soundpack for your language. Here's the steps: 1. Get the en.template file in my github project. Copy it to the translation/ example: rw_RW 2. Get the scripts that go with the trunk version for the sound files. (That's easy, just download any english core sound file set for Asterisk. It's in there, with the ending of ".txt".) 3. Translate the scripts for the various files. These are really a mixture of full sentences, and phrases (parts of a sentence). 4. Now, go to the translation file, with your scripts. Look for the non-trivial sentences, which usually involve stuff like '%' variable references, and more than one sound file. See if the sentence parts fit together acceptably. If not, rearrange under the [format] header for that utterance. Plan new files with corresponding sentence parts if necessary. 5. Now, Plan out the way your numbers, ordinal and cardinal, are spoken, and how the money for your locale is spoken. I will help you (for free) to generate a set of SayScripts for your language. We'll have to deal with issues like gender, or who-knows-what-else! 6. Run a bunch of tests to make sure the numbers, etc are generated properly. 7. Find a friend with a nice voice, and hand them the 400+ file scripts. If you can't find one, or can't afford one, find a quiet room, and record them yourself, as best you can. Edit the recording into separate files. Clean them the best you can. Get them in the best, highest quality format you can. 44+ kiloherz wav pcm files if possible. I'll get them into a good format; Asterisk trunk can handle sln32 or higher file formats. My intention is that the sound files in soundpacks will be a single best choice format. When installing sound packs, the files can be converted into any combination of formats you wish. We can use Asterisk itself to convert the files, or sox. All I know is that the higher quality the source sounds are, the better off you'll be converting them. 8. We'll form your sound files, scripts, and SayScripts into a single Sound Pack. Possibly the first one ever. I'll have to get busy and write some scripts to build sound-packs, and some scripts to install them. I'd like to help with at least one new language, if possible, to see what can be done to smooth the process. Interested? Write me! murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] A Question about Management/Control Protocol Licensing
On Wed, Dec 11, 2013 at 3:29 PM, Matthew Jordan wrote: > > On Wed, Dec 11, 2013 at 3:15 PM, Paul Belanger < > paul.belan...@polybeacon.com> wrote: > >> On 13-12-11 03:15 PM, Steve Murphy wrote: >> >>> I see the following paragraph in the Asterisk trunk LICENSE file: >>> >>> "In addition, Asterisk implements two management/control protocols: the >>> Asterisk Manager Interface (AMI) and the Asterisk Gateway Interface >>> (AGI). It is our belief that applications using these protocols to >>> manage or control an Asterisk instance do not have to be licensed >>> under the GPL or a compatible license, as we believe these protocols >>> do not create a 'derivative work' as referred to in the GPL. However, >>> should any court or other judiciary body find that these protocols do >>> fall under the terms of the GPL, then we hereby grant you a license to >>> use these protocols in combination with Asterisk in external >>> applications licensed under any license you wish." >>> >>> This probably originated some years ago, and I wonder if Digium or the >>> Asterisk >>> community might consider adding the OTHER management/control protocols to >>> this >>> list: ARI, and the ExternalIVR interface. >>> >>> If not, it might be instructive to learn why! >>> >>> Would also like to see this update to include ARI. We talked a little >> about it at astridevcon, and I think it is likely an oversight. >> >> > It isn't an oversight. It's on my ToDo list (and this item is an action > item on the wiki as well). We had the Thanksgiving holiday; then I was out > last week at AdhearsionConf (great conference!). The licensing file will > get updated before 12 is released. > > As an aside, we also had conversations about it on the asterisk-app-dev > list [1], where I responded that I would get answers to the licensing > questions. Granted, it has been much longer than a week or two - mea culpa > on a bad time estimate. > > [1] > http://lists.digium.com/pipermail/asterisk-app-dev/2013-October/000127.html > > Matt > > Many thanks, Matt for this info! -- Steve Murphy -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk Language Status
In putting together the SoundPack code, I am looking at the various language/locale specific code, and wondering how it all really stands... So, share with me, non-English speakers, what is your experience and impression? I heard a few comments during AstriDevCon, that some of the languages are not quite right; some said their language was understandable, but... Would anyone be willing to share with me, the problems they have with various translations? Do they pronounce numbers in a grammatically correct fashion? Any issues with gender/tense/whatever? Are the sound sets in other languages easily findable and downloadable? I see a good selection on http://www.voip-info.org/wiki/view/Asterisk+sound+files+international murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf att parsetree dott com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Language Coverage in Asterisk
I see that Asterisk distributes soundsets for English/English-AU/Spanish/French, and Russian. There is code for several other languages inside Asterisk; how does one obtain the other soundsets? Also, I noted that the source sound files don't seem to be publicly available for the sound sets that Asterisk distributes. I would assume that the source sounds are all 44khz (or more) cd quality sounds, probably in pcm wave format, maybe even in stereo. Are these source sound sets indeed withheld from the public? Or am I mistaken in my impression? murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf att parsetree dott com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] A Question about Management/Control Protocol Licensing
I see the following paragraph in the Asterisk trunk LICENSE file: "In addition, Asterisk implements two management/control protocols: the Asterisk Manager Interface (AMI) and the Asterisk Gateway Interface (AGI). It is our belief that applications using these protocols to manage or control an Asterisk instance do not have to be licensed under the GPL or a compatible license, as we believe these protocols do not create a 'derivative work' as referred to in the GPL. However, should any court or other judiciary body find that these protocols do fall under the terms of the GPL, then we hereby grant you a license to use these protocols in combination with Asterisk in external applications licensed under any license you wish." This probably originated some years ago, and I wonder if Digium or the Asterisk community might consider adding the OTHER management/control protocols to this list: ARI, and the ExternalIVR interface. If not, it might be instructive to learn why! murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dott com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] issue with speech in IVR
On Thu, Nov 28, 2013 at 8:36 AM, Salaheddine Elharit < salah.elharit...@gmail.com> wrote: > hi > i follow your dialplan but the issue still the same ican't stop the speech > and go to another context > > any other idea please > > best regards . > > My guess is that your DTMF tones are not reaching Asterisk. Seen it many times. Study the path whereby the DTMF is generated and recognized and processed by Asterisk. What kind of device are you using? Dahdi? SIP? You can use the rtp set debug to see if the DTMF is coming thru; look at your channel config, there may be something there that might prevent DTMF. Same with the phone settings. Best of Luck, murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dott com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] SaySentence/SoundPack Proposal
Hello-- Boy, it's been a long time since I posted to the user mailing list! Pardon me, I've posted this to dev also, but I thought the general users should also be aware of this. I'd like to announce a proposal to the Asterisk Community, that I introduced at Astridevcon last month. It is a new API for playing sound files (mainly speech). A pdf describing the Proposal in some detail is at: http://www.gmvoices.com/downloads/steve/sayscripts.pdf The end goal is to reduce the cost of making sound sets for new languages, IVR's, etc, and to extend the capabilities of the Say mechanism to allow more natural sound sets for Asterisk. It is a mix of GNU gettext features, a new way of thinking about, and how to organize playing sound files in asterisk, extends ideas introduced by Tilghman Lesher and Luigi Rizzo, and is meant to replace the expansive code in say.c, app_voicemail.c and other places. It is also meant to simplify, in many ways, how to play sound files in general. It moves the code in Asterisk, out into the soundpack. Now, the "soundpack" will contain everything necessary to play sounds at a high level thru Asterisk. It is hoped that "SoundPacks" can be standardized, so that they will not only work on Asterisk, but other phone systems as well. As a first pass at implementing the SaySentence/SoundPack, I have produced a SaySentence server in Java. I have diffs against asterisk-trunk that converts a large chunk of usage into the new regime, and uses the server to generate the file lists. I have begun a conversion to C, which will ultimately replace the Java server with an embedded library to provide the same functionality. I have tested the code in the dialplan and via app_voicemail. All this code is provided, with build instructions, via my project at github: https://github.com/WyoMurf/SaySentence.git I am looking for help from developers and translators. If you are interested in knowing more, have objections, ideas, etc, let me know! murf -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Play subscriber's recorded messages
On Sun, Sep 22, 2013 at 3:07 PM, Asmaa Ahmed wrote: > Hello, > > For the time being I am using the following line to play the original > saved message by Asterisk > exten => 7001,n,Playback(vm-nobodyavail) > > Now I am trying to use the other features for Asterisk's voicemail. I have > recorded a message, and I can see it saved on the system, but still > Asterisk keeps playing the original message... Is there something I can add > to let the subscriber plays his recorded message if he has a one? I > couldn't find a clear way in the wiki about that! > Also can I go more to play specific messages depending on the day/time, a > specific message for the holidays for example? > > Thanks. > > > Asmaa-- It's not entirely clear to me what the problem is, but it appears that you have recorded an unavailable message via the voicemail (comedian) app, and are not getting that message played back when someone is routed to voicemail for that user. If this is indeed the problem, you didn't show the Voicemail() app call in your dialplan. Don't forget to add the 'u' option to the call for unavailable: exten => 7001,n.Voicemail(7001,u) to actually get the voicemail unavailable message to be played. Use 'b' for busy. In asterisk, you can type "core show application voicemail" to get the documentation for that app. As to the message you can play, voicemail has absolutely no mechanisms to allow you to apply some time schedules to your IVR prompts. But, if you null out the plain/busy/unavail messages, you can use the dialplan to set up any kind of opening messages you want, and in that way, you can do almost anything imaginable. When you get done playing whatever you want, then call the Voicemail() app for that user. If you use a few milliseconds of silence in all the recorded message files, then you have effectively overridden its built-in sound file playing with your own introductory messages instead. murf -- Steve Murphy -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Followme Killing Asterisk
On Mon, Jan 14, 2013 at 9:36 PM, A E G wrote:
> Hi Guys,
>
> this has been a weekend destroyer for me. I've struggled this all day and
> most of today.
>
>From your discussion below, it sounds like the real problem is the Asterisk
crashing.
So, as a first step to solving **that** problem, make sure asterisk is
compiled with debug
flags, dumps another core file, and then you do the "gdb asterisk
", and
get a stack trace. That should give us some idea of what happened.
>
> I have a fairly simple Followme sequence in place to see how it works
> before I get into the complex scenarios.
>
> extensions.conf
> ---
> [Incoming]
> exten => ,1, Answer()
> same => n, Set(CHANNEL(language)=en_AU)
> same => n, Followme(TestFollow)
> same => n, NoOp("++Back after Followme: DIALSTATUS =
> ${DIALSTATUS}, Hangupcause = ${HANGUPCAUSE}")
> same => n, Hangup()
>
> [Followme-Dialout]
> exten => _1NXXNXX,1,Set(CHANNEL(language)=en_AU)
> same => n, Dial(SIP/GW-1/${EXTEN})
>
> followme.conf
>
> [TestFollow]
> context => Followme-Dialout
> number => ,30
> number => ,20
>
> The call goes out, and rings my first phone. If I answer it, the Asterisk
> core dumps, the calls stay up!
>
>
>
> [Jan 15 04:19:48] -- Called SIP/GW-1/1203555
>
> [Jan 15 04:19:51] -- SIP/GW-1-0007 is making progress passing it
> to Local/1203555@Followme-Dialout-0004;2
>
> [Jan 15 04:19:51] -- Local/1203555@Followme-Dialout-0004;1 is
> making progress
>
> [Jan 15 04:20:05] -- SIP/GW-1-0007 answered Local/1203555
> @Followme-Dialout-0004;2
>
> [Jan 15 04:20:05] -- Local/1203555@Followme-Dialout-0004;1
> answered SIP/DIDProvider-1-0006
>
> [Jan 15 04:20:05] -- Starting playback of followme/call-from
>
> [Jan 15 04:20:05] --
> Playing 'followme/no-recording.ulaw' (language 'en_AU')
>
> [Jan 15 04:20:05] -- Local/1203555@Followme-Dialout-0004;1
> requested a source update
>
> ast00*CLI>
>
> Disconnected from Asterisk server
>
> Bus error (core dumped)
>
> ...
>
>
> I have been playing with "Local" channels over the weekend, and as cool as
> they sound, they have caused me nothing but pain. Once again, following the
> console log, I notice that Followme indeed uses Local channel to make these
> calls and returns control when the call times out etc.
>
> The ONLY time it gets anywhere is if I use the 'l' option with Followme
> application.
>
> In that case, the call connect and I can have a conversation but the
> minute the remote party hangs up, asterisk dumps core again.
>
> it may be something to do with the "after return" to handle next steps but
> what are they supposed to be? I don't want anything to happen like go to VM
> or anything.
>
> Have tried this with 10.3.0 and 10.11.1. I noticed new changes have been
> made in v11...but this should work
>
> How does this work?? Do I need fancy options with the "Dial" command doing
> GoSub and what not? and Why does it insist on playing all these prompts I
> have commented them all out from followme.conf, but it's still looking to
> play them
>
> Thanks in advance
> \A
>
>
> --
> _____
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉ m...@parsetree.com
☎ 307-899-5535
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] INVITE retransmission by 1.8...
I have a site that moved to the latest 1.8 revision, and began to have problems with phones in "far away places" (South America, and the MidEast). What I see is that when a Dial() is issued, the sip channel driver sends out an INVITE to the phone. Very soon thereafter, Asterisk retransmits the INVITE. The phone sends back a 100 Trying, and then, usually, a 400 response. I may be misinterpreting what I see, but I *think* that the response from the phone is delayed just enough to invoke the retransmission. The phone responds to the second invite with a 400 code, which Asterisk interprets as an error, and the call immediately goes into hangup. Has anyone else seen this? It doesn't happen all the time, and only with certain phones. It comes and goes, but when it comes, phones become unreachable. It seems to be in this state the majority of the time for certain phones. While most phones seem far away, some are in Florida. We replaced the 1.8 version of Asterisk with a 1.6.2 version, and the issue has gone away. I know, I know, I could give more detail, fill out a bug report, but this is the early stages. I may be misinterpreting what I'm seeing. Anyone else seen this sort of thing? Any words of wisdom? murf -- Steve Murphy ParseTree Corporation -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] how to used SIPp for sip load testing
On Tue, Dec 27, 2011 at 6:33 AM, virendra bhati wrote: > Hi Sammy, > > I did the same and start calling. And it's working find but Now I want to > the server max capacity with this script then what is the correct process..? > There is a nice tutorial on how you can do this in the asterisk source code: ./doc/chan_sip-perf-testing.txt murf > > > On Tue, Dec 27, 2011 at 6:36 PM, Sammy Govind wrote: > >> Hi, >> as the Logs say clearly you need to create an extension in default >> context named service >> >> [default] >> . >> exten => service,1,NOOP(Incoming call from SIPp) >> . >> >> Regards, >> Sammy >> >> >> On Tue, Dec 27, 2011 at 5:48 PM, virendra bhati wrote: >> >>> Hi list, >>> >>> I have installed SIPp into my server. But not able to used it properly. >>> how to configure with my server ? how to see logs on webpage ? >>> how to start call testing >>> >>> when i start SIPp then found verious hits on myserver. >>> >>> *CLI:- * >>> [Dec 27 17:37:54] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:54] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:54] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:54] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:55] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:55] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:55] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:55] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> == Using SIP RTP CoS mark 5 >>> [Dec 27 17:37:55] NOTICE[28001]: chan_sip.c:20785 handle_request_invite: >>> Call from '' to extension 'service' rejected because extension not found in >>> context 'default'. >>> haddock8-astrx*CLI> >>> >>> >>> >>> -- >>> >>> Thanks and regards >>> >>> Virendra Bhati >>> +91-8885268942 >>> Software Engineer >>> >>> >> > > > -- > > Thanks and regards > > Virendra Bhati > +91-8885268942 > Software Engineer > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to create a module
On Fri, Jul 8, 2011 at 10:39 AM, Adrian Abramovich < adrianabramov...@gmail.com> wrote: > Hi, > > We are using asterisk 1.4 and we use a Perl script to record some specific > calls. As far, everything is working well. > I was thinking about create a module in order to improve script's > performance. > I checked the Russell's blog: > > http://www.russellbryant.net/blog/2008/06/19/how-to-write-an-asterisk-module-part-1/ > This is a old post and I would like to know if there are something new. > What I do, is look at the other apps/funcs for guidance. Pick the smallest first, and you can copy their style and layout. The module spec has evolved from 1.4 to 1.6 to 1.8, but it's the same basics (to a degree). > Is it a good idea to move to module? > If it increases performance, and you need that, then heck yes! The only drawback is that it *is* in the source; you'll have to tweak it as you move up the versions. You have to compile and install it. Perl would remain static (I would imagine) even when you update asterisk. > Thanks in advance, > > Adrian Abramovich > > > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] dialplan is not finding my number asterisk 1.8.3
Oh, you are *not* going to like this, but you have a few different paths: 1. If the dialplan stuff is not really a memory corruption, but some sort of unplanned, but maybe accidentally programmed thing, either by you or something in the asterisk code, then: a. compile asterisk for debug. You can get in the menuselect stuff and make sure the debug compile options are turned on. Install it. b. Shut down asterisk c. fire it back up, under gdb: gdb br ast_context_remove_extension_callerid2 comm 1 where c end run Then use asterisk as normal and wait for the problem to re-occur. Look to see if any calls to ast_context_remove_extension_callerid2 occurred (they will occur with dial reloads-- lots of them). You'll have to search carefully! The gdb messages could be buried in your console output. If the problem reoccurs, but you didn't see any calls to ast_context_remove_extension_callerid2, then it could be assumed that you are suffering some sort of memory corruption. Where it dies, or things start looking strange, may not indicate where or why the corruption is happening. In such a case, it really gets tricky to debug. Then we might resort to stuff like dmalloc, and others, to help spot where/when corruption occurs. Let's cross that bridge if we come to it. murf On Tue, Apr 5, 2011 at 7:30 AM, Jerry Geis wrote: > Jerry Geis wrote: > >> >> Steve Murphy wrote: >> >>> Idea: >>> >>> If something is corrupting your dialplan, then this should >>> reveal the extent of the corruption: >>> >>> You might, when the system is working properly, do a: >>> >>> asterisk -rx "dialplan show" > somefile1 >>> >>> and then, when you are having problems, do a: >>> >>> asterisk -rx "dialplan show" > somefile2 >>> diff -u somefile1 somefile2 >>> >>> and see if this reveals anything juicy. >>> >>> murf >>> >>> >> Steve, >> >> That is a great idea. I did that the first time it happened. I dumped the >> dialplan, then I restarted >> and dumped again. it was the same. Being the first time I thought it was >> just a fluke but now it >> has happened a couple of times. I have not been able to narrow anything >> down. >> >> Thanks, >> >> jerry >> >> Steve, > > perhaps I did something wrong the first time. As I just got the error > again. I dumped the dialplan and my section: > > > [ Context 'smvoice-mediaport' created by 'pbx_config' ] > > is empty. > > when I restart and dump again. > > > [ Context 'smvoice-mediaport' created by 'pbx_config' ] > '1105' => 1. Goto(smvoice-mediaport-public-address,s,1) > [pbx_config] > 'mediaport_direct' => 1. Goto(smvoice-mediaport-public-address,s,1) > [pbx_config] > 'public_address' => 1. Goto(smvoice-mediaport-public-address,s,1) > [pbx_config] > > I have the correct data. > > The only thing I have in the dialplan for this box is: > > [smvoice-mediaport-public-address] > exten => s,1,System(/home/silentm/bin/smfunctions -stop) > exten => s,n,Playback(beep) > exten => s,n,Dial(Console/dsp) > exten => s,n,Hangup > exten => h,1,System(/home/silentm/bin/smfunctions -start) > > Can a system call be removing stuff from the dialplan? > > What next? > Oh, you are *not* going to like this, but you have a few different paths: 1. If the dialplan stuff is not really a memory corruption, but some sort of unplanned, but maybe accidentally programmed thing, either by you or something in the asterisk code, then: a. compile asterisk for debug. You can get in the menuselect stuff and make sure the debug compile options are turned on. Install it. b. Shut down asterisk c. fire it back up, under gdb: gdb br ast_context_remove_extension_callerid2 comm 1 where c end run Then use asterisk as normal and wait for the problem to re-occur. Look to see if any calls to ast_context_remove_extension_callerid2 occurred (they will occur with dial reloads-- lots of them). You'll have to search carefully! The gdb messages could be buried in your console output. If the problem reoccurs, but you didn't see any calls to ast_context_remove_extension_callerid2, then it could be assumed that you are suffering some sort of memory corruption. Where it dies, or things start looking strange, may not indicate where or why the corruption is happening. In such a case, it really gets tricky to debug. Then we might resort to stuff like dmalloc, and others, to help spot where/when corruption occurs. Let's cross that bridge if we come to it. murf > > Jerry > > -- Steve Murphy ParseTree Corporation -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] dialplan is not finding my number asterisk 1.8.3
Idea:
If something is corrupting your dialplan, then this should
reveal the extent of the corruption:
You might, when the system is working properly, do a:
asterisk -rx "dialplan show" > somefile1
and then, when you are having problems, do a:
asterisk -rx "dialplan show" > somefile2
diff -u somefile1 somefile2
and see if this reveals anything juicy.
murf
On Tue, Apr 5, 2011 at 5:44 AM, Jerry Geis wrote:
> Jerry Geis wrote:
>
>> I am calling from a polycom phone into asterisk ( 1105 ) on a PC with a
>> speaker attached.
>>
>> When asterisk first starts this works. In fact it works for some time.
>> Then it just stops with this error on the CLI.
>>
>> [Apr 4 15:10:21] NOTICE[4357]: chan_sip.c:21358 handle_request_invite:
>> Call from 'mndemo_to_mediaport105' to extension '1105' rejected because
>> extension not found in context 'smvoice-mediaport'.
>>
>> When doing the "dialplan show" it clearly in the context.
>>
>> [ Context 'smvoice-mediaport' created by 'pbx_config' ]
>> '1105' => 1. Goto(smvoice-mediaport-public-address,s,1)
>> [pbx_config]
>>
>>
>> Its telling me it cannot find it. Its there - the dialplan shows its
>> there.
>> When I stop and start it works again for a little while.
>> Matter of fact I just issued "dialplan reload" and calling into 1105 works
>> again.
>>
>> Whats up? How do I get this to be consistent?
>>
>> Jerry
>>
>>
>> I just looked in my extensions.conf and I do not have
> extenpatternmatchnew at all. My understanding is that
> it is off by default.
>
> my sip.conf has:
> register => mndemo_to_mediaport105:secret@mndemo
>
> ; Description:
> [mndemo_to_mediaport105]
> type=friend
> defaultname=mndemo_to_mediaport105
> username=mndemo_to_mediaport105
> secret=secret
> disallow=all
> allow=ulaw
> allow=alaw
> allow=gsm
> rtptimeout=60
> host=192.168.1.58
> context=smvoice-mediaport
>
>
> I was not aware I needed another context of :
>
> [mndemo_to_mediaport105]
> include => smvoice-mediaport
>
>
> The context is set above in sip.conf and that is what the CLI above is
> showing its using.
>
>
> Also my extensions.conf section is :
>
> --
> [smvoice-mediaport-public-address]
> exten => s,1,System(/home/silentm/bin/smfunctions -stop)
> exten => s,n,Playback(beep)
> exten => s,n,Dial(Console/dsp)
> exten => s,n,Hangup
> exten => h,1,System(/home/silentm/bin/smfunctions -start)
>
> [smvoice-mediaport]
> exten => public_address,1,Goto(smvoice-mediaport-public-address,s,1)
>
> #include "/etc/asterisk/express.dnis.conf"
>
> --
> where express.dnis.conf has:
> ; Phone Caller ID & DNIS Manager screen
>
> ; MMPCGA: VISUAL PC ROOM 105 - exten =>
> 1105,1,Goto(smvoice-mediaport-public-address,s,1)
>
> ---
> Here is a call that works:
> == Using SIP RTP CoS mark 5
> -- Executing [1105@smvoice-mediaport:1]
> Goto("SIP/mndemo_to_mediaport105-0003",
> "smvoice-mediaport-public-address,s,1") in new stack
> -- Goto (smvoice-mediaport-public-address,s,1)
> -- Executing [s@smvoice-mediaport-public-address:1]
> System("SIP/mndemo_to_mediaport105-0003", "/home/silentm/bin/smfunctions
> -stop") in new stack
> -- Executing [s@smvoice-mediaport-public-address:2]
> Playback("SIP/mndemo_to_mediaport105-0003", "beep") in new stack
> -- Playing 'beep.gsm' (language
> 'en')
> -- Executing [s@smvoice-mediaport-public-address:3]
> Dial("SIP/mndemo_to_mediaport105-0003", "Console/dsp") in new stack
> << Call placed to 'dsp' on console >> << Auto-answered >>-- Called dsp
> -- ALSA/dummy answered SIP/mndemo_to_mediaport105-0003
> -- Executing [h@smvoice-mediaport-public-address:1]
> System("SIP/mndemo_to_mediaport105-0003", "/home/silentm/bin/smfunctions
> -start") in new stack
> << Hangup on console >> == Spawn extension
> (smvoice-mediaport-public-address, s, 3) exited non-zero on
> 'SIP/mndemo_to_mediaport105-0003'
> --
>
>
> As I mentioned starting asterisk all this works. There is some random time
> later - perhaps days where it then stops
> finding the exten.
>
> Is there something I have wrong in the config above?
>
> Jerry
>
> --
> _
> -- Bandwidth and Colocation Provi
Re: [asterisk-users] Dialplan matching
On Mon, Apr 4, 2011 at 8:09 AM, Asterisk User wrote: > > Hello all, I am trying to figure out the logic in on prefix matching for > Asterisk 1.4.5. I want to be able to pass all international calls EXCEPT > calls to 011870, 01137455 and so on. > > exten => _011870.,1,Goto(intl-disabled,s,1) > exten => _01137455.,2,Goto(intl-disabled,s,1) > exten => _01137477.,3,Goto(intl-disabled,s,1) > exten => _0113749.,4,Goto(intl-disabled,s,1) > exten => _011.,5,Goto(intl-disabled,s,1) > exten => _011.,6,Playback(all-outgoing-lines-unavailable) > exten => _011.,7,Wait(1) > exten => _011.,8,Playback(please-hang-up-and-dial-operator) > exten => _011.,9,Hangup > > Is this correct or should it be: > > exten => _011870X,1,Goto(intl-disabled,s,1) > exten => _01137455X,2,Goto(intl-disabled,s,1) > > I tried searching for definitive information on voip-wiki, nerd vittles, > but there is a lot of confusion. > Assuming that 011870 is followed by more than digit, normally, I'd say your first set is more applicable. The . in the pattern at the end means any number of digits, followed by a timeout. If you know the number of digits, and it is fixed, then you could use _011870XXX or similar to avoid the timeout, and begin the Goto immediately on reception of the final digit. The X in the second set will match just one digit, and the Goto will be be executed. Does that help? > > > -- Steve Murphy ParseTree Corporation -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Regarding error in Asterisk dail plan:
On Wed, Jan 26, 2011 at 9:28 AM, viswavardhanreddy karna < viswavardhanre...@gmail.com> wrote: > Hi all, > i am doing my master thesis on server perfromance evaluation i am > using asterisk as sip proxy server and sipp tool as traffic generator... > > i have run basic testing of asterisk like as shown in website > http://sipp.sourceforge.net/wiki/index.php/Howto_test_an_Asterisk_server_using_SIPp > > > when i have copied sip.conf and extensions.conf from the site and run the > client and server i am getting error like this > > NOTICE[2715]: chan_sip.c:20314 handle_request_invite: Call from '' to > extension 'service' rejected because extension not found in context > 'default' > > i dont know y this is coming its really troubling me a > lot... > > > viswavardhanreddy-- I'm sorry, I'm a bit tight on time, I haven't read your link. But I did some performance testing of Asterisk some years ago, and wrote a doc about it and it's part of the source tree of Asterisk (At least in 1.6 ). See doc/chan_sip-perf-testing.txt There I show how I tied sipp and asterisk together. It might not at all help you, might not be your approach at all, but it might give you some ideas. Best of luck! murf -- Steve Murphy -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip attack.. fail2ban not stopping attack
On Sat, Dec 25, 2010 at 7:41 PM, dave george wrote: > Yes we have that set in logger.conf. > > -Original Message- > From: asterisk-users-boun...@lists.digium.com > [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Nick Ustinov > Sent: Saturday, December 25, 2010 6:25 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] sip attack.. fail2ban not stopping attack > > Make sure you have > > dateformat=%F %T > > in logger.conf > > > > On Sun, Dec 26, 2010 at 1:04 AM, Dave George > wrote: > > My server is being attached all day and fail2ban is not stopping the > > attack. I updated stamstamp to match fail2ban requirements. > > > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" ' > > failed for '38.108.40.94' - No matching peer found > > [2010-12-25 18:54:34] NOTICE[15415]: chan_sip.c:21830 > > handle_request_register: Registration from '"7002" > > Dave > > > > > If all else fails, check your /var/log/fail2ban log file. Any error messages there? A typo in the file name of the log file to check; a jail that is set up but not turned on; double check your set up. Use iptables -L -n to check that fail2ban is properly setting up a chain to block ip's. Is the fail2ban service even running? murf -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No more room in scheduler
On Sat, Dec 11, 2010 at 6:40 AM, mahfoudh alfaqeeh wrote: > Dears: > > Really, later I faced problem in the asterisk system which is : > Message is shown when the unique id which is generated with each caller > reach > 9000 and something: > > No more room in scheduler > Asked to delete sched id > . > . > > after I restarted the server this message is not shown again till now > (after 2 week) > >>> > My question: > What is the reason of this error and how can I solve the problem > permanently > > Please I need the help as soon as possible. > Your effort is appreciated>>> > Thank So much.. > Tell us your exact version asterisk. Cut and paste the actual, exact messages you see. "No more room in scheduler" doesn't show up in 1.6.2, or trunk. Schedulers don't have any limits; the size of the uniqueid's don't either. Try "core show threads", "core show calls" "sip show channels" "core show taskprocessors" from within asterisk's cli. Try this outside asterisk: "lsof -p | wc" (you may have to install lsof via your package manager) > > > > > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > Steve Murphy ParseTree Corp. 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk SIP attacks and sshguard
On Thu, Dec 9, 2010 at 10:31 AM, Daniel Tryba wrote: > > You could use SIPVicious to run attacks on your own servers: > http://code.google.com/p/sipvicious/ > Yeah, why not? All the criminals on the internet are using it, too! ;^) I'm seeing 1-4 scans per day on the average. And it's pretty clearly svwar & friends. A total lack of imagination. A bunch of script kiddies. murf -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] codec_g729a implicated in file descriptor buildup
On Wed, Dec 1, 2010 at 12:15 PM, Kevin P. Fleming wrote: > On 12/01/2010 01:05 PM, Steve Murphy wrote: > > Hello, > > > > I wonder if anyone else has noticed this. > > > > I see a pair of calls to pipe() within the codec_g729a, and suddenly, I > > have a leaked file descriptor that remains until asterisk dies. > > > > > --snip-- > > So, since there is no list of problems fixed with the current g729a > > module distribution, (at least, no in the README in the dist, > > is this a problem that is known? Is this a new problem? Should I call > > support? > > > > Anybody else see this? > > This problem may be in the license file checking code... I've just taken > a quick look at it, and there may be at least one code path that leaks a > pair of pipe file descriptors. I'll enter an internal issue to get this > addressed ASAP. Thanks for the report. > > Kevin-- Any estimates on how long it will take to seal the leak? Need a beta tester? murf Steve Murphy ParseTree Corp. 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] codec_g729a implicated in file descriptor buildup
Hello, I wonder if anyone else has noticed this. I see a pair of calls to pipe() within the codec_g729a, and suddenly, I have a leaked file descriptor that remains until asterisk dies. Now, maybe no-one sees this, mainly because I have no g729 licenses on the machines where this happens. And conversely, I haven't yet studied servers that do have licenses. Why have codec_g729a.so loaded if I don't have licenses? Well, I can install licenses on the run as needed this way, and not worry about having to install anything, or muck things up if there is a mistake. I can mod the phones and get g729 used without restarting asterisk or loading modules. On completely quiet machines, with no calls in or out, I get one descriptor per day, maybe of a daily reload or something. I haven't gotten that far in my investigations yet. Since the module isn't compiled with debug info, the best stack trace I can get is: #0 0x4d5544a0 in pipe () from /lib/libc.so.6 #1 0xb69384ce in __cxa_finalize () from /usr/lib/asterisk/modules/codec_g729a.so #2 0xae7fdae4 in ?? () #3 0xae7fcae4 in ?? () #4 0x1000 in ?? () #5 0x in ?? () The version of the g279 module is: Digium G.729A Module Version 1.6.2.0_3.1.4 (optimized for generic_32) Just now, on a very low-volume asterisk server I am monitoring, two calls just got processed. The g729a codec did a pair of pipe() calls, and voila! I have one more open file descriptor as reported by lsof. Some of my servers (which are busy, but nowhere near capacity!) will build up 100 such leaked descriptors per day, and unless I jack up the maximum number of file descriptors, those servers will have to be restarted about every 10 days, or they will eventually stop accepting calls (or making them, for that matter). Not nice. So, since there is no list of problems fixed with the current g729a module distribution, (at least, no in the README in the dist, is this a problem that is known? Is this a new problem? Should I call support? Anybody else see this? murf -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing
On Wed, Dec 1, 2010 at 7:41 AM, Sherwood McGowan wrote: > On Wed, Dec 1, 2010 at 6:56 AM, Nikhil wrote: > > anyone have a idea on this.. > > > > On 11/22/2010 10:50 AM, Nikhil wrote: > >> Hi everyone, > >> I am facing lots for problem with CDRs in 1.6 and above > >> versions,its shows wrong records when I do transfer(caller side and > >> calee side),callforward,call parking.Is the present CDRs in 1.6 is > >> enough for Complete billing.?What I need to do to make it > >> proper.Please help me on this. > >> > >> Thanks > >> Nikhil > > > > > I can tell you that back in 2005 I set up a complete > residential/business VOIP ITSP that was using just the Asterisk CDRs > to track billing. As long as you setup your billing, I see now reason > wh > > Oh, and by the way, Sherwood is correct; you can ignore everything I wrote previously, IF you don't do call transfers, and you don't park calls. And even if you do a small amount of that, as long as no one forwards an incoming call to some international destination, you'll probably be OK with CDR's. If you don't mind losing a little chunk of the conversation here or there, the current CDR's should be sufficient for you, and you don't have to go thru any bother. Just keep in mind that clever people can/will take advantage of the fact that everything after an incoming call is transferred is lost to billing (as an example). murf Steve Murphy ParseTree Corp. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is existing CDR in Asterisk is enough for complete billing
On Wed, Dec 1, 2010 at 5:56 AM, Nikhil wrote: > anyone have a idea on this.. > > On 11/22/2010 10:50 AM, Nikhil wrote: > > Hi everyone, > > I am facing lots for problem with CDRs in 1.6 and above > > versions,its shows wrong records when I do transfer(caller side and > > calee side),callforward,call parking.Is the present CDRs in 1.6 is > > enough for Complete billing.?What I need to do to make it > > proper.Please help me on this. > > > > Thanks > > Nikhil > Nikhil-- Yes, there is a problem with CDR's in asterisk. There is a bug filed against the problem, but no practical solution for it. The cure: use the CEL interface instead, and generate your own CDR's (or whatever else you could bill from [it doesn't *have* to be CDRs]) The cause of the problem: An interesting combination of 3 operations being performed on channels, namely masquerading, and forming local channels; add to that the hardwired 'roles' that channels are given (channel, and peer), and the final knockout: CDRs are stored on channels. The above 3 operations affect CDR's because parking and transfers can change the role that a channel plays (chan to peer or vice-versa); Transfers and parking involve the masquerading, and sometimes local channels-- both these operations involve duplicating a channel. CDR's are meant for the channel playing the "channel" role, and CDRs on channels playing the "peer" role are tossed out. Transfers turn the above into a complex mush in which the results vary depending on who transfers who, who is calling, and who is called, etc. Because the CDR's are stored on the channels themselves, they pass thru many filters and operations that vary based on the roles they play and the operations performed, which can change in subtle ways from release to release, from one bugfix to another, even. So, the best way to get around all this is to get the CDRs out of the channels, And to do that, you either use CEL, or you build your own event tracking mechanism, using whatever means available (I've seen folks use the manager event reports with their own logic in perl, or php, or whatever to do the parsing and storage). Then, you either turn the events into your own billing mechanism, or you generate CDR's to fit into your currently existing billing mechanism. Doing this right and making it dependable is not an overnight sort of thing. I proposed a CDR generating backend for CEL (which I haven't completed yet). I even started it, but got layed off before I could finish it. I've generated a spec for CEL->CDR generation, involving something I call "simple CDRs".This doc has been evolving with time, and needs to be updated. I previously described "complex" CDR's in the spec that provided more fine-grained event logging in CDR format, but I've convinced myself that the complex stuff can also be done via the "simple" method, and so I'm about half way thru the spec, expunging the "complex" stuff. All my examples have to be changed -- If you are interested in looking at my spec, you can: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and look at the pdf there in that directory. murf Steve Murphy ParseTree Corp. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Why are the hackers scanning for these?
Hey, I'm going thru logs, and I see some very common and interesting things that the hackers are looking for. In a whole bunch of scans, I've noticed that the first guess or two for sip accounts is usually a 10-digit number. I'm asking myself, why these numbers? Are they looking for a voip trunk? Or is it just like a serial number for the scan? What? Here's some examples: 2648061411 3190339404 2685608247 3358171034 2092652562 2206598858 Just trying to follow the advice: "Know thy Enemy" murf Steve Murphy ParseTree Corp. 57 Lane 17 Cody, WY 82414 ✉ m...@parsetree.com ☎ 307-899-5535 Signature powered by <http://www.wisestamp.com/email-install?utm_source=extension&utm_medium=email&utm_campaign=footer> WiseStamp<http://www.wisestamp.com/email-install?utm_source=extension&utm_medium=email&utm_campaign=footer> -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] MySQL and Channel Event Logging
On Wed, Oct 13, 2010 at 9:52 PM, Sherwood McGowan < sherwood.mcgo...@gmail.com> wrote: > > > On Wed, Oct 13, 2010 at 9:53 PM, Paul Belanger < > paul.belan...@polybeacon.com> wrote: > >> On Wed, Oct 13, 2010 at 9:31 PM, Sherwood McGowan >> wrote: >> > Hey all, sorry if this has been covered, but I've not found anything >> after a >> > couple hours' worth of googling. I can see (and I'm familiar with) all >> the >> > usual MySQL addon apps once I install Asterisk 1.8.x, but I cannot find >> any >> > reference to MySQL and the new CEL logging tool other than ODBC. Is this >> the >> > only method available to use MySQL with CEL at this time? >> > >> Looking at the CEL config files, I don't see one specifically for >> MySQL. I do have it up and running via ODBC, for what it's worth. >> >> -- >> Paul Belanger | dCAP >> > Thanks mate, I appreciate the reply. That's what I've seen from looking at > the configs right now. > > When I wrote the CEL backends, I probably skipped the MySQL stuff, because it would be in the "addons" stuff for Asterisk. But, if you look at the similarities between the CEL backends, and the CDR backends, you'll probably notice that you could pump out a myseql backend with the same mods in a short amount of time. I would be curious to see how you plan to use that table! Have you mapped out your sql statements yet? murf -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to test BIG traffic through DAHDI/WANPIPEinterfaces
On Tue, Oct 5, 2010 at 1:02 PM, Danny Dias wrote: > Hello my friend Ingmar, > > I would like to know the cable you used? how was the connection? i'm using > this one: > > http://wiki.sangoma.com/Pinouts#A108 Loop Back > > Is this ok? what should i do my friend, my problems are "understand" the > fisicall connection :( > > Best Regards!!! > > 2010/9/24 Ingmar Steen > >> Hi DD, >> >> >> >> We usually use loopback cables and use the open source SIP test tool >> “SIPp” to initiate SIP calls that are sent from one group of 4 ports to >> another group of 4 ports. >> >> >> >> Met vriendelijke groet, >> >> Ingmar Steen >> >> Teleknowledge >> >> >> >> *Van:* asterisk-users-boun...@lists.digium.com [mailto: >> asterisk-users-boun...@lists.digium.com] *Namens *Danny Dias >> *Verzonden:* vrijdag 24 september 2010 11:05 >> *Aan:* Asterisk Users Mailing List - Non-Commercial Discussion >> *Onderwerp:* [asterisk-users] How to test BIG traffic through >> DAHDI/WANPIPEinterfaces >> >> >> >> Hello Community, >> >> >> >> I need to test or simulate many calls through dahdi/wanpipe, i have a >> Sangoma A108D, and i need to test the stability of the >> card/drivers/firmwares with a test environment, do you think is possible? >> >> >> >> What should i do? using some loopback cable maybe? >> >> >> >> Thanks in advance >> >> >> >> DD >> > I set up two machines with T1 interfaces, and connected the two with an appropriate t1 cable. One was acting as a network (master), the other as a subscriber (slave) (for timing). wrote two dialplans, one for each machine, that would answer an incoming call on one dahdi line, and call to the next numbered line on the other machine. The other machine was similarly outfit. I'd define the extension for the first line on the t1, and call it with any phone you desire. That call will cascade into 23 separate interlinked calls. If you are clever, the last call in should dial another real phone you have on-hand. You get the picture... right? Phone A dials the exten to call the first exten on the other machine. The dialplan should use the first channel on the t1 to place a call to the first exten on the other machine. On the other machine, the incoming call on channel 1 is answered, and then a dial to the second extension on the first machine, over the 2nd t1 channel. The first machine answers, and uses the 3rd channel to call the other machine and so on till all channels are being used. The last exten answers and dials a phone (dahdi or SIP, no matter) that you pick up. Such a looped call should probably be awful, but it's going thru 23 t1 channels! If you have two t1 interaces in a single card (or two cards), then you do this on one machine. Another approach: set up equal numbers of FZO and FXS lines, and similarly loop s single call thru all the channels.This would require just one machine. Other approaches would involve running multiple threads to call an extension and then hang up and repeating this over and over again on all channels to ascertain the load placed just by call setup and tear-down. This kind of load is different than when all lines are just shoveling data back and forth. Watch your load averages, your %cpu, your swap, etc, as the tests are in full swing. murf > >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Solving the CDR mess of attended transfers
A few corrections! On Tue, Sep 21, 2010 at 6:32 PM, Steve Murphy wrote: > > > On Tue, Sep 7, 2010 at 5:36 PM, Fabiano Carlos Heringer < > b...@grupoheringer.com.br> wrote: > >> Em 07/09/2010 17:15, Miguel Molina escreveu: >> >> El 07/09/10 14:49, Fabiano Carlos Heringer escribió: >> >> Is there a way to solve the mess on CDR caused by CDR Transfer? anyway, by >> paid support, no paid, or another way... Im going crazy about this. My boss >> is really furious because he don´t understand nothing on the CDR. >> >> I tried the 1.6.2.11, Asterisk 1.8 beta, and everything still the same. >> >> Any solution? >> >> Thanks! >> >> Hi >> >> Some quick measures: >> >> 1. Enable unanswered=yes on cdr.conf and try to see if it helps you with >> the CDR. >> 2. Try using CEL (Channel Event Logging) in 1.8-beta and try to see if >> that helps in a definite way. >> >> Cheers, >> >> -- >> Ing. Miguel Molina >> Grupo de Tecnología >> Millenium Phone Center >> >> Hi, will make this change on my cdr.conf >> >> About CEL on asterisk 1.8 i tried some test on my test server, he really >> logs each event on log, but i did not understood how he will work on a user >> view (most simple). It´s possible to log this events on a database such >> mysql? >> >> Thanks! >> > > Sorry for the delay, things have been busy here. > > Yes, there are problems with the existing CDR interface, mostly historical, > because as Asterisk > grew, the CDR system became obsolete. There were attempts to make it work, > but structurally > and architecturally, it was just not going to work. > > CEL was my answer, built on the channel event goodness that Russell. It's > now in 1.8; but it > Uh, that Russell *wrote*. > lacks a converter to CDRs. You *could* just use the string of events coming > out of CEL, but... > I'd love to see your SQL statements to pull things together! > > I had begun writing a CEL->CDR converter, but got laid off before I could > finish it. > It makes a good start toward a finished package. Long ago (what, almost 2 > years now?) > I proposed two methods of generating CDR's. One was 'simple', the other > 'Complex", or "Leg Based". > > Since then, I refined the doc to just 'Simple', and outlined with some > examples how it would/should work. > The doc still needs to be cleaned up, but you may make sense of it. > > The trouble with CDRs is that no two shops can agree on a CDR standard that > involves transfers, parks, etc. > Beyond the "start", "answer", and "end" times, and some fundamental data > about the call (source, dest, > responsible party, etc.) There isn't much unity about what timepoints need > to be represented, etc. And I'd seen > so few implementations, I couldn't judge a good way to generalize the CDR > converter. > > So, I challenge everyone to look at my simple CDR definition, and see it > would possible for you to adapt it > (perhaps via a mapping from it to your desired conflagration/configuration. > > To look at the doc, do "svn co > http://svn.digium.com/svn/team/murf/asterisk-RFCs and look at the > document in there (I have a few different formats, the .docx is the > source). > Sorry, the URL is http://svn.digium.com/svn/asterisk/team/murf/RFCs > > It's been in flux. Just the first few examples are accurate. Let me know > what you think. > > murf > > > > -- > Steve Murphy > ParseTree Corp > > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Solving the CDR mess of attended transfers
On Tue, Sep 7, 2010 at 5:36 PM, Fabiano Carlos Heringer < b...@grupoheringer.com.br> wrote: > Em 07/09/2010 17:15, Miguel Molina escreveu: > > El 07/09/10 14:49, Fabiano Carlos Heringer escribió: > > Is there a way to solve the mess on CDR caused by CDR Transfer? anyway, by > paid support, no paid, or another way... Im going crazy about this. My boss > is really furious because he don´t understand nothing on the CDR. > > I tried the 1.6.2.11, Asterisk 1.8 beta, and everything still the same. > > Any solution? > > Thanks! > > Hi > > Some quick measures: > > 1. Enable unanswered=yes on cdr.conf and try to see if it helps you with > the CDR. > 2. Try using CEL (Channel Event Logging) in 1.8-beta and try to see if that > helps in a definite way. > > Cheers, > > -- > Ing. Miguel Molina > Grupo de Tecnología > Millenium Phone Center > > Hi, will make this change on my cdr.conf > > About CEL on asterisk 1.8 i tried some test on my test server, he really > logs each event on log, but i did not understood how he will work on a user > view (most simple). It´s possible to log this events on a database such > mysql? > > Thanks! > Sorry for the delay, things have been busy here. Yes, there are problems with the existing CDR interface, mostly historical, because as Asterisk grew, the CDR system became obsolete. There were attempts to make it work, but structurally and architecturally, it was just not going to work. CEL was my answer, built on the channel event goodness that Russell. It's now in 1.8; but it lacks a converter to CDRs. You *could* just use the string of events coming out of CEL, but... I'd love to see your SQL statements to pull things together! I had begun writing a CEL->CDR converter, but got laid off before I could finish it. It makes a good start toward a finished package. Long ago (what, almost 2 years now?) I proposed two methods of generating CDR's. One was 'simple', the other 'Complex", or "Leg Based". Since then, I refined the doc to just 'Simple', and outlined with some examples how it would/should work. The doc still needs to be cleaned up, but you may make sense of it. The trouble with CDRs is that no two shops can agree on a CDR standard that involves transfers, parks, etc. Beyond the "start", "answer", and "end" times, and some fundamental data about the call (source, dest, responsible party, etc.) There isn't much unity about what timepoints need to be represented, etc. And I'd seen so few implementations, I couldn't judge a good way to generalize the CDR converter. So, I challenge everyone to look at my simple CDR definition, and see it would possible for you to adapt it (perhaps via a mapping from it to your desired conflagration/configuration. To look at the doc, do "svn co http://svn.digium.com/svn/team/murf/asterisk-RFCs and look at the document in there (I have a few different formats, the .docx is the source). It's been in flux. Just the first few examples are accurate. Let me know what you think. murf -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] help with dialplan
On Tue, Aug 31, 2010 at 9:34 AM, Danny Nicholas wrote: > Why not just copy the _1NXXNXX line into the remote context? > Well, that could be done, and probably would be a good tactic if you have lots of DID's and want to do db lookup or something to direct the next call leg. But, if you only have one or two DID's, all the machinery and programming seem a bit overkill. murf > > -- > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] help with dialplan
On Tue, Aug 31, 2010 at 9:14 AM, Todd Reese wrote:
> Interesting things going on herel.
>
> After your suggestions, Steve. I reran the dialplan show
> 16789542...@remote command with the below results.
>
>
> Phone calls are geting the 404 error and the NOTICE on the console.
> [Aug 31 11:06:46] NOTICE[11884]: chan_sip.c:20161 handle_request_invite:
> Call from '150' to extension '16789542133' rejected because extension not
> found in context 'remote'.
>
-- This one is easy to solve, Add the extension 16789542133 to the remote
context and have it do what you need to be done for an incoming call.
and also, see below:
>
>
> asterisk*CLI> dialplan show 16789542...@remote
> [ Included context 'dialout1' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/v6787500600/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout1' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/v6787500600/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout2' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/voip.comACA/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout3' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/v6783747049/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout1' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/v6787500600/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout2' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/voip.comACA/${EXTEN},40,Ttr)
> [pbx_config]
>
> [ Included context 'dialout3' created by 'pbx_config' ]
> '_1NXXNXX' => -2. Dial(SIP/v6783747049/${EXTEN},40,Ttr)
> [pbx_config]
>
> -= 7 extensions (7 priorities) in 7 contexts. =-
> [Aug 31 11:03:38] WARNING[11903]: pbx.c:5741 show_dialplan_helper: Avoiding
> circular include of from-internal within remote
>
See the "Avoiding circular include"? Get rid of that by removing one of the
includes that make the cycle; make your
inclusions hierarchical. One context to include them all, and in the
darkness bind them! (sorry, too much Tolkien)
murf
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] help with dialplan
Todd--
There is probably some nifty anti-infinite-recursion code in the
extensions.conf parser,
to keep asterisk from going into infinite loops trying to descend into the
right context.
In your dialplan, [remote] includes dialout1, dialout2, dialout3, and each
of those
include remote.
Straighten out that mess and maybe things might work. Just a guess, but
worth a try!
murf
On Tue, Aug 31, 2010 at 8:25 AM, Todd Reese wrote:
> From extensions.conf
>
> [remote]
> include => from-internal
> include => dialout1
> include => dialout2
> include => dialout3
> include => intercom
> exten => 150,1,Macro(oneline,${EXTERNPHONE0})
>
> [dialout1]
> include => from-internal
> include => 411
> include => remote
> exten => 911,1,Goto(nineoneone,s,1)
> exten => _1NXXNXX,n,Dial(SIP/v6787500600/${EXTEN},40,Ttr)
> [dialout2]
> include => from-internal
> include => 411
> include => remote
> exten => 911,1,Goto(nineoneone,s,1)
> exten => _1NXXNXX,n,Dial(SIP/voip.comACA/${EXTEN},40,Ttr)
> [dialout3]
> include => from-internal
> include => 411
> include => remote
> exten => 911,1,Goto(nineoneone,s,1)
> exten => _1NXXNXX,n,Dial(SIP/v6783747049/${EXTEN},40,Ttr)
>
>
>
>
>
> On 8/31/2010 9:58 AM, Paul Belanger wrote:
> > On Tue, Aug 31, 2010 at 9:16 AM, Todd Reese wrote:
> >> Here's the updated debug log.
> >>
> > [Aug 30 15:27:41] NOTICE[11568] chan_sip.c: Call from '150' to
> > extension '6789542133' rejected because extension not found in context
> > 'remote'.
> >
> > So, again, a context problem. You can confirm by entering:
> >
> > *CLI> dialplan show 6789542...@remote
> >
> >
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk does not translate from wav to alaw
On Sat, Aug 28, 2010 at 9:52 AM, Tilghman Lesher wrote: > On Saturday 28 August 2010 10:35:59 Bryant Zimmerman wrote: > > Thanks for sharing I appericate your insight as this is something I run > up > > against as well. > > What about g729 we use this coded a lot what is the best method to > > transcode it it? > > If you load "res_convert.so", you will have a CLI command "file convert > ...". > Usage: file convert > Convert from file_in to file_out. If an absolute path > is not given, the default Asterisk sounds directory > will be used. > > Example: > file convert tt-weasels.gsm tt-weasels.ulaw > > Tilghman speaks rightly. This conversion utility keys from file names, so for g729, you might say: asterisk -rx "file convert tt-weasels.ulaw tt-weasels.g729" or, asterisk -rx "file convert /home/user/tt-weasels.gsm /home/user/tt-weasels.g729" (oh, and make sure asterisk is running!) murf PS. Wouldn't it be nice if sox could handle the sirens, g729, and everything else? > -- > Tilghman Lesher > Digium, Inc. | Senior Software Developer > twitter: Corydon76 | IRC: Corydon76-dig (Freenode) > Check us out at: www.digium.com & www.asterisk.org > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk does not translate from wav to alaw
On Sat, Aug 28, 2010 at 3:22 AM, Jonas Kellens wrote: > Hello list, > > I have a file to be played in wav-format. > > I thought Asterisk would automatically take the wav-file and translate it > to the codec used, but I see this : > > [Aug 28 11:16:29] WARNING[2705]: file.c:664 ast_openstream_full: File > /var/lib/asterisk/sounds/vprompts/*zip-code.wav* does not exist in any > format > [Aug 28 11:16:29] WARNING[2705]: file.c:991 ast_streamfile: Unable to open > /var/lib/asterisk/sounds/vprompts/*zip-code.wav* (format 0x8 (*alaw*)): No > such file or directory > [Aug 28 11:16:29] WARNING[2705]: pbx.c:5752 pbx_builtin_background: > ast_streamfile failed on SIP/test1-000f for > /var/lib/asterisk/sounds/vprompts/*zip-code.wav* > > > Am I missing a module to translate from wav to alaw/gsm/g726/... ?? > > My guess is that your .wav file is NOT 8khz. The system doesn't accept anything but wav files at 8khz. Use sox to downsample to 8khz (and 1 chan), and the problems should go away. While you are at it, you could use sox to convert to the target format in a single operation. The scripts that Digium uses to take Allison's voice prompts (at 48khz) to the different formats, convert things to slin (raw) as a central format, but in my experience, the fewer steps the better. But I doubt that anyone could detect the difference in the end result... Here's what I do with CD-qual sounds to turn them into the common Asterisk formats: Assume $i is the name of the .wav file you want to convert: x=`basename $i .wav` sox -v 0.7 $i -r 16000 -c 1 -t sw $x.sln16 sox -v 0.7 $i -r 8000 -c 1 -t sw $x.raw sox -r 8000 -c 1 -t sw $x.raw -t gsm $x.gsm## OR ### sox -v 0.7 $i -r 8000 -t gsm $x.gsm sox -r 8000 -c 1 -t sw $x.raw -t ul $x.ulaw## OR ### sox -v 0.7 $i -r 8000 -t ul $x.ulaw sox -r 8000 -c 1 -t sw $x.raw -t al $x.alaw ## OR ### sox -v 0.7 $i -r 8000 -t wav $x.wav rm $x.raw y=`pwd` sudo asterisk -rx "file convert $y/$i $y/$x.g722" I'm ignoring the siren & g729 formats; use asterisk for those in like format, depending on your asterisk version and codecs. Allison normalizes the volume of sounds she distributes; use the -v 0.7 to bring the volume down a bit to the standard, and your sounds won't stick out against rest of Allison's existing recordings in Asterisk. Digium uses a filter program to 'heighten' the sounds a little; That's the main reason, I think, that they use the .raw format as an in-between. I've been skipping this step, as it doesn't seem critical, in which case the direct conversion is probably preferable. I suggest, that if you are converting sounds for Asterisk's sake, that you convert to all the possible formats. Disk space is cheap, and you'll squeeze a little extra performance out of Asterisk by allowing it to pick the 'best' format. Dahdi type interfaces would prefer the ulaw/alaw formats; High-def phones like Snom (and appropriate Polycoms, etc) could use the g722. Ulaw and gsm transcodings are cheap, but no transcoding is cheaper still. murf > Kind regards, > > Jonas. > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Deleting extension makes it usable?
I hope I'm correct, I don't have time to verify every bit of this, but The message [Jun 7 17:04:16] NOTICE[7422] chan_sip.c: Failed to authenticate user "asterisk" >;tag=as23bacb61 indicates the user "asterisk". Do you have a sip account for "asterisk"? Why it would take 14 seconds and an ANSWERED dial for an unathenticated use is something to investigate! As to the more general question of how 3799 could be unexpectedly matched in the dialplan, I would respond that there are several possibilities... One is, Is the account with the weak pword removed from sip.conf? The 3799 account? Because, it looks like SIP/206.20... (you abbreviated here in the CDR you listed) is where the call is originating. b. Did you *really* get rid of all 3799 occurrences in the dialplan? What patterns do you have in the dialplan that might match 3799, after the explicit 3799 is removed? Any _ type patterns included or in the context in question? c. I uncovered a pattern matching bug, and reported it in bug https://issues.asterisk.org/view.php?id=17366 where unexpected patterns are matched. Sorry, I haven't had time to correct it myself, it's probably a simple 1-line fix, but oh, what it might take to figure out what the line should say, and where it is! d. "s" is the "start" extension, and an incoming call will tend to get routed into an "s" extension. You can quickly determine (b) or (c), by going to the CLI, and saying "dialplan show 3...@whatever-context and see what turns up. murf On Tue, Jun 8, 2010 at 7:50 AM, J wrote: > I'm fairly new to FreePBX/Asterisk/Trixbox, but have Googled myself > into submission here, so any assistance is appreciated. > > We had a user with a weak SIP secret recently that allowed it to be > used by an outside user. The extension was 3799. I could see the > intruder's calls (including the destination phone numbers) in the > trixbox call report log. Because the extension was no longer used, I > went ahead and deleted it, thinking that would solve the problem. I > also discovered approximately the same time that the Asterisk Call > Manager port was open to the outside world, which has since been > closed. The web interface, ssh, etc. have never been exposed to the > outside world. Since taking these actions, I restarted the asterisk > server. > > Now, here's the issue. I don't think deleting the extension helped. > Now I see entries like this in the reports log: > > Calldate Channel Source Clid Dst Disposition Duration > 1. 2010-06-07 16:47:38 SIP/206.20... 3799"asterisk" > <3799> s ANSWERED00:14 > > The "Dst" field being "s", where it used to be the phone number being > dialed. How is this extension able to be used even after it has been > deleted? > > Strangely, what I've done to keep the user out in the mean time is > re-created the 3799 extension with a better secret. This results in > log entries like the following: > > [Jun 7 17:04:16] NOTICE[7422] chan_sip.c: Failed to authenticate user > "asterisk" > >;tag=as23bacb61 > > Why can sip:3799 connect and make calls when the extension doesn't > exist? Is this person somehow using a "user" account? I've checked > both /etc/asterisk and the MySQL tables and am not coming up with > much. What does it mean that their destination is "s", not a phone > number? > > Thanks for any assistance! > J > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] file command with alaw file
On Thu, May 20, 2010 at 1:49 AM, Pham Quy wrote: > Hi, > > How can I convert FROM ALAW file, which generated by asterisk apps > (monitor, or record app), to format (wav or mp3) that is playable by > music player?? Can Sox do this? > >From alaw to wav, you can use Asterisk's CLI f" file convert /var/lib/asterisk/sounds/soundfile.alaw /var/lib/asterisk/sounds/soundfile.wav to go from alaw to mp3, first convert to wav, then use lame /var/lib/asterisk/sounds/soundfile.wav /var/lib/asterisk/sounds/soundfile.mp3 sox looks like it can ogg/vorbis, but mine doesn't list mp3. You might fetch the source for sox and see if it can do mp3; lame is probably just as easy to obtain and use. murf > > I have an asterisk 1.6.2.6 on my CentOS 5.2. I record audio clip by > mixmonitor app and use file command to check the alaw output, and here > is output: > > - > 983006584-20100517-125002.alaw: RIFF (little-endian) data, WAVE audio, > ITU G.711 A-law, mono 8000 Hz > - > > How could file command recognize the format as there is no header in the > output file? Or Did I probably miss something making asterisk yield > incorrect alaw files? > > Please help, thanks > > Quyps > > On Thu, 2010-05-20 at 00:50 -0600, Steve Murphy wrote: > > Quyps-- > > > > I've noticed in general that the ulaw, alaw, gsm, slin files used and > > generated by > > asterisk do not have headers (the RIFF stuff), and asterisk is not > > expecting them. in general they > > will louse up Asterisk's ability to play the sound. They are just raw > > data and the extension > > on the file name (.gsm, or .ulaw, etc) is the only clue to the file > > format/contents. > > > > In general, if you need a sound file of your own making in a certain > > format, you can convert > > to most of the formats using sox in linux, but really, the best thing > > to do is record the source > > sound file in cd-quality sound WAV format, in 44 khz sampling rate, or > > higher, and then > > use sox to convert to 8khz format. Asterisk can do some of this via > > the file convert CLI > > command, ( on the asterisk cli, type "help file convert"). You'd have > > to judge for yourself > > if "file convert tt-weasels.gsm tt-weasels.ulaw" which would convert > > the 8khz gsm format to > > 8 khz ulaw, or "sox -v 0.7 tt-weasels.44khz.wav -r 8000 -c 1 -t sw > > tt-weasels.raw;" > > "sox -r 8000 -c 1 -t sw tt-weasels.raw -t ul tt-weasels.ulaw" which > > is the way the Asterisk > > sounds are produced from the the cd-quality sounds. They would seem a > > bit equivalent. > > > > I wonder if just "sox -v 0.7 tt-weasels.44khz.wav -r 8000 -c 1 -t ul > > tt-weasels.ulaw" would > > sound any better... you audio engineers out there may have an opinion. > > > > I've personally noted that not all linux distributions provide the > > same version of sox; > > some distribute sox with an absolute minimum of sound formats > > built-in. You may have > > to go out and find all the libraries and roll your own sox. > > > > murf > > > > > > > > > > > > On Wed, May 19, 2010 at 10:34 PM, Pham Quy wrote: > > On Mon, 2010-05-17 at 17:49 +0700, Pham Quy wrote: > > > On Mon, 2010-05-17 at 13:06 +0700, Pham Quy wrote: > > > > hi all, > > > > > > > > I install Asterisk 1.6 on Centos 5.2 (kernel 2.6.18-92.el5 > > #1 SMP Tue > > > > Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux) > > and do record > > > > audio clip with mixmonitor() as alaw file (softphone is > > also configured > > > > with alaw active only). Using file command i can get the > > following > > > > information > > > > > > > > 983006584-20100517-125002.alaw: RIFF (little-endian) data, > > WAVE audio, > > > > ITU G.711 A-law, mono 8000 Hz > > > > > > > > But when i install the same system on Centos 5.5 (kernel > > 2.6.18-92.el5 > > > > #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 > > GNU/Linux) i > > > > could get the same information with file command. File > > command > > > > recognized alaw file as JPEG image: > > > > > > > > 983006584-20100517-123825.alaw: JPEG image data > > &
Re: [asterisk-users] file command with alaw file
Quyps-- I've noticed in general that the ulaw, alaw, gsm, slin files used and generated by asterisk do not have headers (the RIFF stuff), and asterisk is not expecting them. in general they will louse up Asterisk's ability to play the sound. They are just raw data and the extension on the file name (.gsm, or .ulaw, etc) is the only clue to the file format/contents. In general, if you need a sound file of your own making in a certain format, you can convert to most of the formats using sox in linux, but really, the best thing to do is record the source sound file in cd-quality sound WAV format, in 44 khz sampling rate, or higher, and then use sox to convert to 8khz format. Asterisk can do some of this via the file convert CLI command, ( on the asterisk cli, type "help file convert"). You'd have to judge for yourself if "file convert tt-weasels.gsm tt-weasels.ulaw" which would convert the 8khz gsm format to 8 khz ulaw, or "sox -v 0.7 tt-weasels.44khz.wav -r 8000 -c 1 -t sw tt-weasels.raw;" "sox -r 8000 -c 1 -t sw tt-weasels.raw -t ul tt-weasels.ulaw" which is the way the Asterisk sounds are produced from the the cd-quality sounds. They would seem a bit equivalent. I wonder if just "sox -v 0.7 tt-weasels.44khz.wav -r 8000 -c 1 -t ul tt-weasels.ulaw" would sound any better... you audio engineers out there may have an opinion. I've personally noted that not all linux distributions provide the same version of sox; some distribute sox with an absolute minimum of sound formats built-in. You may have to go out and find all the libraries and roll your own sox. murf On Wed, May 19, 2010 at 10:34 PM, Pham Quy wrote: > On Mon, 2010-05-17 at 17:49 +0700, Pham Quy wrote: > > On Mon, 2010-05-17 at 13:06 +0700, Pham Quy wrote: > > > hi all, > > > > > > I install Asterisk 1.6 on Centos 5.2 (kernel 2.6.18-92.el5 #1 SMP Tue > > > Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux) and do record > > > audio clip with mixmonitor() as alaw file (softphone is also configured > > > with alaw active only). Using file command i can get the following > > > information > > > > > > 983006584-20100517-125002.alaw: RIFF (little-endian) data, WAVE audio, > > > ITU G.711 A-law, mono 8000 Hz > > > > > > But when i install the same system on Centos 5.5 (kernel 2.6.18-92.el5 > > > #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux) i > > > could get the same information with file command. File command > > > recognized alaw file as JPEG image: > > > > > > 983006584-20100517-123825.alaw: JPEG image data > > > > > > I guess i may miss something when i setup the new on on Centos 5.5, but > > > u dont know what it is. Anyone have idea about this? > > > > > > please help. > > > > > > Thanks in advance. > > > Quyps > > > > I did check content of two alaw files (using a hex editor) generated > > from two aboves cases. For the one fromo CentOS 5.2, beginning bytes > > look likes : > > > > riff1^0.wavefmt@...@...fact.^0.data.^0... > > > > and the one from CentOS 5.5 > > > > ..RQVTVXEMBAX > > > > It seem like the first one have some information about file format, > > which make our convert tool works correctly, and which the second one > > doesnt have. > > > > Can you explain to me this different, and how can i get the information > > as the first one? > > > > Thanks in advances, > > Quyps > > This question have been asked for a while, I really need some help > here? > > Thanks in advance. > Quyps > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk choking on voice messages announcements
On Wed, Apr 21, 2010 at 6:13 PM, bruce bruce wrote: > How can I find out what the source of the problem is guys? > > As I said I didn't change anything, except for making few minor changes to > the firewall today and that was at Amazon firewall level and not within > CentOS. > > What causes these bad dahdi_test values? > > P.S. there is only few calls load at anytime on this server. > Here are few ideas: 1. I have seen complaints that as Amazon loads up its virtual machines, that neighboring VM's running on the same hardware are sucking up CPU cycles and reducing the performance of the other VM's on board. One guy was complaining that to get the same performance he got a few months ago, he has to move to a more powerful machine, which costs more . You might move up to a more expensive, faster VM and see if it helps. 2. I don't know exactly how Dahdi gets its timing, but I do know that it has two methods; one involves HIGH RES TIMERS compiled into the kernel. The other when the high-res stuff isn't included. You can decompress /proc/config.gz into a local file and look for HIGHRES to be defined. If it isn't you might try to find a kernel with it defined, and see if it helps. 3. If you are on 1.6.1 or 1.6.2 (too tired to look up which), you could try using another method of generating timing than dahdi_dummy. I suspect that they may just reflect code already in Dahdi_dummy... but this seems like something you might want to become knowledgeable about! murf > Thanks > > On Wed, Apr 21, 2010 at 8:03 PM, Carlos Chavez wrote: > >> On Wed, 2010-04-21 at 19:36 -0400, bruce bruce wrote: >> > Here are result of dahdi_test: >> > >> > >> > [r...@ip-10-251-123-3 ~]# dahdi_test >> > Opened pseudo dahdi interface, measuring accuracy... >> > 99.725% 96.018% 99.532% 91.934% 99.923% 99.923% 99.628% 99.434% >> > -434.763% 99.239% 93.770% 99.141% 99.822% 91.232% 99.727% 93.770% >> > 99.726% -403.227% 98.069% 98.458% 95.136% 98.749% 91.229% 87.622% >> > 98.554% 93.282% -407.620% 94.650% 96.308% 98.750% 96.993% 93.478% >> > 94.063% 93.381% 61.745% -379.400% 99.628% 99.921% 99.142% 96.797% >> > 98.457% 99.337% 87.909% 95.141% -396.880% 99.531% 99.923% 99.921% >> > 91.035% 96.408% 91.916% 90.255% -402.153% 81.079% 74.534% 96.212% >> > >> > >> > What can one tell from these? >> > >> Only that your timing source sucks. You need 99.9% or higher if >> you >> want a stable system. I have servers with dahdi_dummy that never go >> below 99.7% accuracy. You really need to check your timing source. >> >> -- >> Telecomunicaciones Abiertas de México S.A. de C.V. >> Carlos Chávez Prats >> Director de Tecnología >> +52-55-91169161 ext 2001 >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > -- > _________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk choking on voice messages announcements
Then use a timing source if the version is correct (1.6.1 or 2), or install dahdi-dummy, which can be quite some amount of work On Wed, Apr 21, 2010 at 12:35 PM, bruce bruce wrote: > yes, it's on Amazon. > > On Wed, Apr 21, 2010 at 2:26 PM, Ryan Bullock wrote: > >> Are you running asterisk in a virtual machine? >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Being attacked by an Amazon EC2 ...
On Wed, Apr 21, 2010 at 9:23 AM, Stuart Sheldon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Randy R wrote: > > On Wed, Apr 21, 2010 at 2:55 PM, Fred Posner > > wrote: > >> On Apr 21, 2010, at 4:50 AM, Gordon Henderson wrote: > >> > >>> On Tue, 20 Apr 2010, Frank Bulk wrote: > >>> > >>>> Please take note of their posting: > >>>> https://aws.amazon.com/security/ which discusses the issue and > >>>> what they're doing to improve response. > >>> And is anyone on the list worthy of being considered a > >>> "significant SIP provider" to be honoured with the privilege of > >>> working with them? > >>> > >>> Gordon > >>> > >> None of the carriers I deal with have been contacted. Of course, > >> them only contacting "significant" providers... does that mean it's > >> ok if the attacks happen to non-significant providers or > >> end-points? > >> > >> ---fred http://qxork.com > > > > If it got to their BS/PR page/blog it means they're hearing about > > complaints on the net as well as people like you submitting. Everyone > > please keep posting where you can and sooner or later, someone big > > will pick up the story. > > > > Funny, I'd think the most "worthy" people to comment on this issue > > are on this list. That's the feedback they should be looking for and > > working on at Amazon EC2. > > > > /r > > > > We might me reading their PR wrong... Maybe there were large SIP > providers that were compromised due to this attack... Maybe they are > keeping that quiet at the request of those providers... It could also be > that the aliens in hiding in Colorado are behind the whole thing! ... Oh > no! I've said too much!!! LOL... > > It could actually be the case that this whole issue went beyond what we > are seeing, and they are trying to protect one of their Whale customers... > > Needless to say, what about the SSH brute force attacks that originate > from their network? What about the SPAM that flows like a fountain from > their net blocks? > > This was nothing more then PR hype... > > Stu > > Assuming that every such spamming/hacking/attack site is funded on a stolen identity/CC number, it will soon sink into Amazon that they are getting a bad rep, and losing money on such problems, as all such charges are reversed when the identity theft is discovered... How they overcome the problem, should be a tribute to the marvelous power of human ingenuity. murf -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Being attacked by an Amazon EC2 ...
Hmmm. It would seem that it would be to Amazon's advantage to jump on this problem, because the accounts that are performing this activity are most likely purchased with stolen identities, and sooner or later the charges are going to get reversed. Either the credit card companies are going to absorb the cost, or the merchants (like Amazon) at the other end. And, after listening to merchants grumble about it, I'd assume that in the end, Amazon is going to get stiffed for the bill. On someone else's credit card, I'd imaging they have almost infinite resources; Bandwidth to burn, the best and most powerful hosts. So what if they rack up thousands of dollars? They are probably organized crime units in Romania or whatever. murf On Tue, Apr 13, 2010 at 11:21 AM, Tzafrir Cohen wrote: > On Tue, Apr 13, 2010 at 04:32:58PM +0200, Hans Witvliet wrote: > > On Tue, 2010-04-13 at 15:49 +0200, Philipp von Klitzing wrote: > > > Hi! > > > > > > > Any aditional security within * is fine, but if someone is simply > > > > drowning your bandwith, action must be taken at a lower level. > > > > Otherwise you endup re-inventing the wheel for D.o.s. attackes for > voip, > > > > mail, ssh, ldap, http, rsync, (or any other service you might be > running) > > > > > > However, I *still* think Asterisk should provide a "delayreject" option > > > in sip.conf to greatly slow down answering request avanlanches. That > will > > > help to address the bandwidth issue if the attacker is configured to > wait > > > for a response before starting the next request. > > > > > > Apart from that here are the most important messages: Use strong > > > passwords in sip.conf, and use keys in iax.conf, and avoid usernames > that > > > can be guessed too easily (numbers from 100 to and first names). > > > > > > > Agreed, best would be to only use ssl-certificates for authentication, > > but not all parts involved support that, (to put it mildly...) > > Secure authentication won't solve the problem of attackers flodding your > pipe. Especially not if you have ADSL or similar connection. > > -- > Tzafrir Cohen > icq#16849755 > jabber:tzafrir.co...@xorcom.com > +972-50-7952406 mailto:tzafrir.co...@xorcom.com > http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AEL in 1.6 and Gosub
On Mon, Mar 15, 2010 at 12:47 PM, Klaus Darilion <
klaus.mailingli...@pernau.at> wrote:
>
>
> Am 15.03.2010 13:48, schrieb Kevin P. Fleming:
> > Klaus Darilion wrote:
> >> Hi!
> >>
> >> I just updated from 1.4 to 1.6.2.6 and Asterisk complains about my AEL
> >> dialplan:
> >>
> >> application call to Gosub affects flow of control, and needs to
> >> be re-written using AEL if, while, goto, etc. keywords instead
> >>
> >> What is the suggested replacement for an explicit Gosub() call? I use it
> >> like this:
> >>
> >> ...
> >> Gosub(blacklist,${exten},1);
> >> ...
> >>
> >> context blacklist {
> >> _+43900! => Hangup();
> >> _+43910! => Hangup();
> >> _+X. => return;
> >>
> >> }
>
How about:
&blacklist(${exten});
macro blacklist(the_exten)
{
switch(the_exten)
{
pattern +4390[01]: Hangup();
default: return;
}
}
You could use something like the above.
Basically, you are using the pattern matching capability to
end the call for certain extensions... so the above should
come close. If you really, really want to keep your gosub call,
then you can, you'll just have to ignore the warnings, iirc.
murf
>
> > In 1.6, AEL macro() is implemented using Gosub(), so you can use it as a
> > direct replacement. This is listed in the CHANGES file.
>
> Hi Kevin!
>
> I know that AEL macro does not use Macro() anymore, but Gosub(). But
> does that imply the other way round too?
>
> Using an AEL macro (which is implemented as Gosub) instead of a Gosub
> does not work as the target is a context, not a macro which is
> implemented as pseudo context with an 's' extension.
>
> I do not see a way to implement the above dialplan using an AEL macro.
> Do I miss something?
>
> regards
> Klaus
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DID/CID doesn't match "." (dot) in CID field
On Tue, Mar 16, 2010 at 7:45 AM, Daniel Grotti wrote:
> Hi Murf,
> this is what I get from CLI if I type : "[.]" instead of ".":
>
>
> [example]
> exten => test.skype/example[.]skype,1, NoOp(nothing)
> exten => test.skype/example[.]skype,n, Hangup()
>
Daniel--
OK, I went and looked thru the source. The code doing this to your CID
number is ast_shrink_phone_number(). It gets called on your cid number
and dutifully does this:
"remove '(', ' ', ')', non-trailing '.' and '-' not in square brackets.
Because the . is not at the end of the pattern, it gets wiped by this
routine.
There seems little to do about it, as is. The call to
ast_shrink_phone_number()
is not optional or conditional. Apparently, asterisk is expecting plain
phone numbers
with stuff like (715) 693-4855, or 715.693.4855, and will remove the cruft
for you. That
it's preserving dashes inside of brackets (and brackets, too), means it is
expecting
to see patterns here.
So, I'd file a bug, and say that a dot in brackets should survive, too,
along with a
dash in brackets. ...that to limit dots in the cid pattern to the last
character is
not good behavior.
Because of this, I wonder if your CID should begin with an "_" you'll
have to test
it out if they go and add the few lines to that routine they would need to,
to allow
dots in the pattern string. My memory is failing me and I don't have enough
time
to go playing in the source code.
murf
> CLI> show dialplan example
>
> [ Context 'example' created by 'pbx_config' ]
> 'test.skype' (CID match *'example[]skype'*) => 1.
> NoOp(nothing) [pbx_config]
> 2. Hangup()
> [pbx_config]
>
>
> As you can see the only "." has been erased.
> There is no problem on DID ("." notations works fine), but only in CID
> field.
> I'm usign Asterisk 1.4.26.2
>
> Thanks,
>
> Daniel
>
>
>
> Il 16/03/2010 14.19, Steve Murphy ha scritto:
>
> Daniel--
>
> Haven't tried this myself, but have you tried '[.]' instead of just '.' in
> the string (as a pattern search)?
>
> So,
>
> [example]
> exten => _test[.]skype/e[x]ample[.]skype,1, NoOp(nothing)
> exten => _test[.]skype/e[x]ample[.]skype,n, Hangup()
>
> If you don't really mean the cid matching (denoted with /), you have to
> also 'escape' the '/'...
>
> and watch out for N,X,Z in the pattern, they mean something, and will have
> to be 'escaped'
> like the '.' if you want them to match literally. I can't remember how case
> is handled at the
> moment, so... just for safety, you can 'escape' the little 'x' also...
>
> murf
>
>
> On Tue, Mar 16, 2010 at 5:59 AM, Daniel Grotti wrote:
>
>> Hi all,
>> using Skype for Asterisk I have the following problem.
>> In my dialplan I need to have a CID matching (example.skype) over a DID
>> (test.skype) :
>>
>> [example]
>> exten => test.skype/example.skype,1, NoOp(nothing)
>> exten => test.skype/example.skype,n, Hangup()
>>
>> Where test.skype and example.skype are Skype business account.
>> In this case, when I get a :
>>
>> CLI> show dialplan example
>>
>> I get:
>>
>> [ Context 'example' created by 'pbx_config' ]
>> '*test.example*' (CID match '*danexample*') => 1.
>> NoOp(nothing) [pbx_config]
>> 2. Hangup()
>> [pbx_config]
>>
>>
>> As you can see, the "." (dot) is disappeared and, of course, CID matching
>> doesn't work as I aspected.
>> I've try to escape "." with something like that "\.", but nothing.
>> It seems that asterisk doesn't consider "." in DID/CID evaluations.
>> This is an important point, because many Skype account uses "dot"
>> notation.
>>
>> It seems to work, instead, with "_" or "-".
>>
>> Any clues?
>>
>> Regards,
>>
>> Daniel
>>
>>
>>
>> --
>> _____
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>> http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>
Re: [asterisk-users] DID/CID doesn't match "." (dot) in CID field
Daniel-- Haven't tried this myself, but have you tried '[.]' instead of just '.' in the string (as a pattern search)? So, [example] exten => _test[.]skype/e[x]ample[.]skype,1, NoOp(nothing) exten => _test[.]skype/e[x]ample[.]skype,n, Hangup() If you don't really mean the cid matching (denoted with /), you have to also 'escape' the '/'... and watch out for N,X,Z in the pattern, they mean something, and will have to be 'escaped' like the '.' if you want them to match literally. I can't remember how case is handled at the moment, so... just for safety, you can 'escape' the little 'x' also... murf On Tue, Mar 16, 2010 at 5:59 AM, Daniel Grotti wrote: > Hi all, > using Skype for Asterisk I have the following problem. > In my dialplan I need to have a CID matching (example.skype) over a DID > (test.skype) : > > [example] > exten => test.skype/example.skype,1, NoOp(nothing) > exten => test.skype/example.skype,n, Hangup() > > Where test.skype and example.skype are Skype business account. > In this case, when I get a : > > CLI> show dialplan example > > I get: > > [ Context 'example' created by 'pbx_config' ] > '*test.example*' (CID match '*danexample*') => 1. > NoOp(nothing) [pbx_config] > 2. Hangup() > [pbx_config] > > > As you can see, the "." (dot) is disappeared and, of course, CID matching > doesn't work as I aspected. > I've try to escape "." with something like that "\.", but nothing. > It seems that asterisk doesn't consider "." in DID/CID evaluations. > This is an important point, because many Skype account uses "dot" notation. > > It seems to work, instead, with "_" or "-". > > Any clues? > > Regards, > > Daniel > > > > -- > _________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 3:01 AM, Olle E. Johansson wrote:
>
> 16 feb 2010 kl. 09.43 skrev Tzafrir Cohen:
>
> > On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:
> >> On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri
> wrote:
> >>
> >>> Yes but in any case you can enter all of the strings that reasonably
> match
> >>> - even if you have variable-length numbers, you will be able to
> determine
> >>> that a valid number be between 5 and 15 characters - or likely 2 to 20,
> all
> >>> numbers. A number of 156 characters is very likely to be a problem.
> >>>
> >>
> >> This is probably a stupid idea, because it could only be implemented in
> >> trunk, and won't help with current implementations,
> >> and I suggested it a long time ago already when I did the fast pattern
> >> matching code, but I don't THINK it would be all that
> >> hard to offer SOME regex syntax in patterns to help reduce the impact of
> >> these kinds of problems.
> >>
> >> Like using:
> >>
> >> [incoming-from-voip]
> >> exten => _X\{7-10\},1,Dial(${ext...@incoming-from-voip-old)
> >>
> >> instead of :
> >>
> >> [incoming-from-voip]
> >> exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
> >> exten => ,1,Dial(${ext...@incoming-from-voip-old)
> >> exten => X,1,Dial(${ext...@incoming-from-voip-old)
> >> exten => XX,1,Dial(${ext...@incoming-from-voip-old)
> >>
> >> I put the \'s in front of the {}'s because we probably wouldn't want to
> >> change the
> >> behavior of exact matching, and there's some precedent for using such
> stuff
> >> in some implementations of regex, where \< matches the beginning of a
> word,
> >> etc.
> >>
> >> and, of course there would be the shorthand variants \{7-\} for seven or
> >> more; \{-10\} for 1-10.
> >> Some might argue 0-10. Whatever.
> >>
> >> I THINK this could be implemented in both the fast pattern matcher and
> the
> >> current slow one. I know it wouldn't be that bad to do in the fast
> pattern
> >> matcher.
> >> I hadn't really given the slow one (the current one) much thought.
> >
> > I think it would be very useful. One small point:
> >
> > The '.' is short. This helps making it pupular. X\{1-\} is much less
> > so.
> >
> > Another thing that I think would help: an equivalent of perl's \w:
> > something similar to 'X', but also matches letters. This is syntactic
> > sugar, but we need such sugar for readable dialplans.
> >
> Leif and I had a proposal years ago for an "alphaexten" that used perl
> regexps.
>
>
Yes, I know that many have proposed full regex and regex-like extensions
for
the dialplan patterns, but there's one big rub. The current pattern matcher
is light and
fast compared to a full regex matcher. The restrictions on constructs make
it a fairly
fast linear matcher without any loops or recursive behavior to slow it down.
We can currently use
rules to quantify the "best match" that makes it fairly predictable, and the
work on a
fast pattern matcher (O(log(pattern length)) instead of O((num
patterns)^2) was possible.
But, when you move to full regex approaches, you lose all those nice
properties. You'd have
to move to a 'best match first' sort of strategy, so you can move from a
O(n^2) type scenario,
and you lock yourself into an O(n^2/2) scenario. For large dialplans on a
busy system, you are
totally screwed, without any hope of improving the situation.
I tried in times past to propose a subset of regex patterns that would still
leave us with fast
pattern matching
murf
/O
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 1:43 AM, Tzafrir Cohen wrote:
> On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:
> > On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri
> wrote:
> >
> > > Yes but in any case you can enter all of the strings that reasonably
> match
> > > - even if you have variable-length numbers, you will be able to
> determine
> > > that a valid number be between 5 and 15 characters - or likely 2 to 20,
> all
> > > numbers. A number of 156 characters is very likely to be a problem.
> > >
> >
> > This is probably a stupid idea, because it could only be implemented in
> > trunk, and won't help with current implementations,
> > and I suggested it a long time ago already when I did the fast pattern
> > matching code, but I don't THINK it would be all that
> > hard to offer SOME regex syntax in patterns to help reduce the impact of
> > these kinds of problems.
> >
> > Like using:
> >
> > [incoming-from-voip]
> > exten => _X\{7-10\},1,Dial(${ext...@incoming-from-voip-old)
> >
> > instead of :
> >
> > [incoming-from-voip]
> > exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
> > exten => ,1,Dial(${ext...@incoming-from-voip-old)
> > exten => X,1,Dial(${ext...@incoming-from-voip-old)
> > exten => XX,1,Dial(${ext...@incoming-from-voip-old)
> >
> > I put the \'s in front of the {}'s because we probably wouldn't want to
> > change the
> > behavior of exact matching, and there's some precedent for using such
> stuff
> > in some implementations of regex, where \< matches the beginning of a
> word,
> > etc.
> >
> > and, of course there would be the shorthand variants \{7-\} for seven or
> > more; \{-10\} for 1-10.
> > Some might argue 0-10. Whatever.
> >
> > I THINK this could be implemented in both the fast pattern matcher and
> the
> > current slow one. I know it wouldn't be that bad to do in the fast
> pattern
> > matcher.
> > I hadn't really given the slow one (the current one) much thought.
>
> I think it would be very useful. One small point:
>
> The '.' is short. This helps making it pupular. X\{1-\} is much less
> so.
>
Very true, but the added syntax would not replace '.'. And they mean two
different things. X\{1-\} would mean one or more numbers, . means
any number of any character.
Heck, besides N\{2-4\}, Z\{3-7\}, I guess we could even do .\{2-100\}, which
could mean 'match everything at the end of the string, but only if there's 2
to
100 of them', or something like that. Whatever is the most handy.
>
> Another thing that I think would help: an equivalent of perl's \w:
> something similar to 'X', but also matches letters. This is syntactic
> sugar, but we need such sugar for readable dialplans.
>
Could be done, but it ends up getting in the way of exact matching;
right now, using X,N,Z keeps you from exact matching those characters,
(is there some escape mech in the syntax to let you say \NA\NCY? I
haven't checked). But, there's no reason we can't add other matching chars
for handy things. A = alpha chars Y = alphanum chars, G = Graphical chars,
whatever. We just have to watch those backslashes, because if we use them as
an escape to mean literals in some situations, and as a notation to mean a
special function in others, then it starts getting confusing real quick.
But all this kind of thing Could Be Done.
murf
>
> --
> Tzafrir Cohen
> icq#16849755
> jabber:tzafrir.co...@xorcom.com
> +972-50-7952406 mailto:tzafrir.co...@xorcom.com
> http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Important security alert: update your dialplans now!
On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri wrote:
> Yes but in any case you can enter all of the strings that reasonably match
> - even if you have variable-length numbers, you will be able to determine
> that a valid number be between 5 and 15 characters - or likely 2 to 20, all
> numbers. A number of 156 characters is very likely to be a problem.
>
This is probably a stupid idea, because it could only be implemented in
trunk, and won't help with current implementations,
and I suggested it a long time ago already when I did the fast pattern
matching code, but I don't THINK it would be all that
hard to offer SOME regex syntax in patterns to help reduce the impact of
these kinds of problems.
Like using:
[incoming-from-voip]
exten => _X\{7-10\},1,Dial(${ext...@incoming-from-voip-old)
instead of :
[incoming-from-voip]
exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
exten => ,1,Dial(${ext...@incoming-from-voip-old)
exten => X,1,Dial(${ext...@incoming-from-voip-old)
exten => XX,1,Dial(${ext...@incoming-from-voip-old)
I put the \'s in front of the {}'s because we probably wouldn't want to
change the
behavior of exact matching, and there's some precedent for using such stuff
in some implementations of regex, where \< matches the beginning of a word,
etc.
and, of course there would be the shorthand variants \{7-\} for seven or
more; \{-10\} for 1-10.
Some might argue 0-10. Whatever.
I THINK this could be implemented in both the fast pattern matcher and the
current slow one. I know it wouldn't be that bad to do in the fast pattern
matcher.
I hadn't really given the slow one (the current one) much thought.
murf
>
> BTW, you could add a catchall "mail the sysadmin" option - so when you get
> a number that is not being matched you could be notified and adjust the
> dialplan as needed.
> l.
>
>
>
> 2010/2/15 Olle E. Johansson
>
>
>> > To avoid extensive rewriting and fix the current issue.
>> That works in countries where you have fixed-length numbers.
>> Unfortunately, not every dialplan works that way, so that can't be a generic
>> advice even though it may solve your problems.
>>
>> Thanks for your suggestion!
>>
>> /O
>>
>>
> --
> Loway - home of QueueMetrics - http://queuemetrics.com
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to make SpeechBackground keepplayingifutterance doesn't match our grammar
Quinn--
I would venture to guess that your problem is because you are using the
sound file streaming
mechanism at too high a level. At the app/agi level, you don't get any
control over the process.
You start the sound process, then you wait for the interrupt; it's all
neatly bundled into a single
package.
At the C level, using the machinery that Asterisk uses, you use these calls:
res = ast_streamfile(chan, "Filename", chan->language);
if (res2) { failure_code(); }
else {
ast_autoservice_start(chan); /* keep those packets running out to chan
*/
}
/* put code here to process the stuff from voice recognition s/w until you
get what
you want, or time out, or whatever */
if (!res2) {
ast_stopstream(chan);
ast_autoservice_stop(chan);
}
The code above pretty much supposes that the file will play longer than it
will take to get some outcome
from the VR stuff; but no matter, if it runs clear to the end, it will just
leave you with a dead channel.
Best to set some sort of timeout so as not to sit forever if the person at
the other end of "chan" is mute
or dies or something. The main thing to remem is that autoservice_start()
and streamfile() immediately
return, and do not block, and the shuffling of sound packets is handled in a
different thread. Some other
event or timeout or something needs to eat up time between the starting of
the playback and the stopping
of the playback.
Hope this helps, probably not what you were hoping for.
murf
On Mon, Jan 25, 2010 at 4:33 PM, Quinn Weaver wrote:
> On Mon, Jan 25, 2010 at 2:56 PM, Danny Nicholas wrote:
> > Since you're "Perling" it, why not just put the $sb_retval in a while
> loop
> > like this:
> >
> > - my $response_good=0;
> > - my $sb_retval=undef;
> > - while (! $response_good) {
> > -my $tmp_retval = $c->agi->exec('SpeechBackground', $path);
> > -if ($tmp_retval eq 'play_next') {
> >$sb_retval=$tmp_retval;
> >$response_good=1;
> >}
> > ...
> > }
>
> If we did that, we'd be replaying $path from the beginning every time
> the user said something that didn't match the grammar. For a podcast
> episode like a radio show, that's bad—you don't want to be 30 seconds
> or two minutes into the content and have to start over.
>
> Also, as I said, it's always matching one of the rules in our
> grammar--even if I literally say "goobledegook." So it's unclear how
> we'd implement $response_good.
>
> --
> Quinn Weaver Consulting, LLC
> Full-stack web design and development
> http://quinnweaver.com/
> 510-520-5217
>
> --
> _____
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] receive text
On Sun, Jan 17, 2010 at 7:34 AM, Thomas Perron wrote: > Is there any code that I can cut/paste that will allow me to receive > an SMS text on Asterisk? > and, where can I capture the incoming text? > > See chan_mobile in the asterisk-addons... For certain cell phones there is a facility there to pass an SMS on thru the phone to Asterisk. You do it all via dialplan apps in chan_mobile.c, you'll see apps MobileSendSMS(device,dest,message), which allows you to send an SMS message via the dialplan, thru the bluetooth attached phone. To get an SMS, you have to have a cellphone bluetooth attached, and capable of passing sms messages. When it reports to Asterisk via the bluetooth connection, that an SMS message was recieved, Asterisk will try to run the "sms" extension, with the channel variables SMSSRC and SMSTXT channel variables set to the appropriate values. In the dialplans you can turn this into an email, an announcement, a text-to-speech (via festival or Cepstral or whatever), or whatever your needs or imagination can supply. I've asked around a while back, and the only phone capable of such sms capabilities was one running the Symbian os, iirc, and that means Nokia, I guess, and Erickson, and a few others... according to the Wikipedia, it's a pretty popular smart phone OS. Hmmm, wonder if the google Android can handle this? Anyway, another non-hardware solution might be to use an internet SMS gateway (for 10 cents/msg in low volume), to send/receive SMS also... murf > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Inserting a wait in a sip dial SOLVED (kind of)
Dave-- I remember adding a feature a long time ago for snoms, to the source code, to send dtmf out for some button press on a snom phone, in the 'outward' direction, I think to activate a feature or somesuch. (Boy, is my memory hazy!) At any rate, I was able to inject dtmf, but I had to do it in the source. AFAICT, there is no app that do this explicitly; and Murphy's Law would state that even if a dialplan app existed, it would not get run at the time you need to be run. So, if you found a workaround, and it works, it won't matter how pretty it is. Magic is Magic. And speaking of Murphy's Law: Enjoy it while it lasts, because, sure as death and taxes, someone will fix a bug somewhere, and you'll lose an undocumented feature ;) murf On Tue, Jan 12, 2010 at 2:31 PM, David Gibbons wrote: > > Going foward, is there any way to programmatically inject DTMF tones into > an already-bridged channel? > > > Well, due to the lack of responses, either I missed something obvious or > nobody cares. I'm really hoping I didn't miss something obvious... :). > > In any event, I got curious of my own old question and hacked out a work > around: > > 0. Assume your extension is dumped into context 'mycontext' > 1. You dial an internal extension > 2. * Dials an external number (presumably another PBX device) > 3. When the remote device answers, both parties are dumped into the > DTMFworkaround context > 4. The called party has its DTMF mode set to inband so that the tones are > played out loud > 4.5. Meanwhile, the calling party is dumped into an empty meeting > conference that is used soley to bridge these two legs > 5. When the tones are done, the called party is dumped into the bridged > conference. > 6. When the caller hangs up, the conference boots the callee > > > [dtmfworkaround] > exten => 6534,1,Goto(dtmfworkaround|6536|1) > exten => 6534,2,Goto(dtmfworkaround|6535|1) > exten => 6535,1,Answer() > exten => 6535,n,Wait(1) > exten => 6535,n,SIPDTMFMode(inband) > exten => 6535,n,SendDTMF(1234) > exten => 6535,n,MeetMe(101|MFqx|1234) > exten => 6536,1,Answer() > exten => 6536,n,MeetMe(101|MFqxA|1234) > > [mycontext] > exten => 658,1,Dial(SIP/486,15,rG(dtmfworkaround^6534^1)) > > > -Dave > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SPRINTF option : format %1$s not supported
On Mon, Oct 12, 2009 at 4:51 AM, Olivier wrote: > Hi, > > With 1.6.1.7-rc2, doc says: > select*CLI> > -= Info about function 'SPRINTF' =- > > [Syntax] > SPRINTF(,[,...]) > > [Synopsis] > Format a variable according to a format string > > [Description] > Parses the format string specified and returns a string matching that > format. > Supports most options supported by sprintf(3). Returns a shortened string > if > a format specifier is not recognized. > > > > I'm trying use sprintf option allowing to swap argument display according > format string. > More precisely, I'm trying to this "%1$s" specifier (which means "use 1st > argument"). > Then, the reply is : > ERROR[3185]: func_strings.c:547 acf_sprintf: Format type not supported: > '%1$' with argument '1234' > > Though the message is clear, before giving up, I thought I should ask here > if someone could successfully use the > "%1$s" specifier (which is very useful when you want to localize some > messages or output some command strings). > My initial (imho) impression is that localizations in the code, are in general a bad way to approach localization in general. The localizations should be located neither in Asterisk code nor in dialplan code. I know, I know, that such code already exists, but that's still not making my assertion false... murf -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] res_speech_lumenvox.so: undefined symbol: ast_speech_register
On Mon, Aug 3, 2009 at 6:05 PM, Yelson Vivas wrote: > Hi Guys > I am new working with lumenvox products, and unfortunately I had not been > able to install it properly, I follow the steps in lumenvox site and it > looks like it works I mean: > = > [r...@pbx-millenium examples]# ./example 127.0.0.1 > Connecting to 127.0.0.1 > Interpretation 1: > 8587070707 > > count=0, decode returns 1 > Interpretation 1: > 8587070707 > > count=1, decode returns 1 > Interpretation 1: > 8587070707 > > count=2, decode returns 1 > Interpretation 1: > 8587070707 > = > But when I try to load the lumenvox module the entire pbx is killed, the > message is > > - > NOTICE[9278]: res_speech_lumenvox.c:841 load_module: Lumenvox SRE > Connector module Copyright (C) 1999-2007 Digium, Inc. > NOTICE[9278]: res_speech_lumenvox.c:842 load_module: This module is > supplied under a commercial license granted by Digium, Inc. > == Parsing '/etc/asterisk/lumenvox.conf': Found > -- Using server(s): 127.0.0.1 > -- Loaded tweaking profile default > asterisk: symbol lookup error: > /usr/lib/asterisk/modules/res_speech_lumenvox.so: undefined symbol: > ast_speech_register The function ast_speech_register is defined in res/res_speech.c (I found this out by grepping the 1.4 source for ast_speech_register). So, the solution may be as simple as running the "make menuselect" and making sure the Resource Modules section has res_speech checked. (wouldn't that be nice and easy?) murf > > > - > My system: > Centos 5.2, asterisk 1.4.22, > asterisk-1.4.x-lumenvox-support-linux-i686-32bit-b22-engine8.5, > lumenvox was installed using yum > So if you could give me any idea I really will appreciated it > Thanks your time > Regards > Yelson > > -- > Yelson E Vivas C > MPC > (571) 6500-800 > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2009 - October 13 - 15 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] #exec in #include'd file
On Tue, Jul 14, 2009 at 11:47 AM, Tilghman Lesher < tilgh...@mail.jeffandtilghman.com> wrote: > On Monday 13 July 2009 17:19:15 Philipp Kempgen wrote: > > Tilghman Lesher schrieb: > > > On Monday 13 July 2009 01:03:48 pm Philipp Kempgen wrote: > > >> Philipp Kempgen schrieb: > > >> > Is Asterisk supposed to evaluate #exec's in an #include'd file? > > > > > > The directive "#exec" is not permitted in an AEL configuration file. > > > > I see, that would explain why it doesn't work. :-) > > > > But in that case it's a documentation issue. The extensions.conf > > sample says: "The #exec command works on all asterisk configuration > > files." I guess it should read "The #exec command works on all > > asterisk *.conf files except for asterisk.conf." > > > > Is there a specific reason not to permit #exec in AEL files? > > It wasn't coded that way, and it's parsed in a completely different way > than > any other Asterisk configuration file. I don't know the reason Murf didn't > do '#exec' specifically, but I suspect it has to do with the complexity > thereof. I didn't "exclude" the #exec for any particular reason. I think it just wasn't in the original AEL (1.2) code, so I missed it... (or it escaped my all-powerful eyes somehow). If someone files a bug, I might be able to code up something to handle it in future releases. (just as a reminder for me). I guess you could, for the time being, put your #exec stuff in an extensions.conf file, and use the modules.conf tricks to preload the extensions.conf file first, if that is a requirement, as previously suggested... murf > > > > Is any *.conf file (which permits #exec) guaranteed to be read before > > extensions.ael? It would then be possible to (ab)use an #exec in there > > to trigger my generator script (which must not output anything then of > > course). extconfig.conf? logger.conf? modules.conf? Ugly workaround > > but doable. > > No, but you can force it by doing an explicit load of a particular module > in > modules.conf. Explicitly loaded modules are loaded before all > automatically-loaded modules. > > -- > Tilghman & Teryl > with Peter, Cottontail, Midnight, Thumper, & Johnny (bunnies) > and Harry, BB, & George (dogs) > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Attended transfer and dialplan
On Fri, May 29, 2009 at 11:35 PM, Olivier wrote:
>
>
> 2009/5/29 Danny Nicholas
>
>> I’m pretty sure that attended transfer is a “features” function, not a
>> dialplan one.
>>
>
> Yes, you're right but do you think there's such a big difference between
> both that it shouldn't be easy or even possible to add support of attended
> transfer in dialplan ?
>
> What I have in my mind is this :
>
> Today, Dial application M or U options allows macro execution when caller
> and callee are connected.
> What if this same macro could be also launched during some later events
> (like attended transfer) ?
> With features.conf, you could then specify :
> - how lo launch an attended transfer (which key to type as today),
> - if a given "feature" (attended transfer, parking, ...) should be
> supported by Dial macro option (for compatibilty, default could be set to
> none)
>
> and with extension.conf, you could specify :
> - which specific treatment (sending UserEvents, launching an external
> program, ...) to apply
>
> In this puzzle, if Asterisk could support a few more standard variables
> like ATTENDED_TRANSFERER ATTENDED_TRANSFER_TARGET, you would everything to
> define and run attended transfers specific logic :
>
> exten => 123,1,Dial(SIP/123,M(mymacro^arg1^arg2)) ; mymacro is launched
> upon connection and specified (in features.conf) events
>
> [macro-mymacro]
> GotoIf("x${ATTENDED_TRANSFERER}",
>
> What about that ?
>
Olivier--
This is actually not a bad idea.Why single out just the Attended xfer? Why
would you treat
attended xfers differently than blind xfers? Just curious.
Also, calling just one macro for all features seems a bit restricted. Why
not allow the features.conf
to specify which macro/gosub to call, for each feature? Dial is already
overloaded with options,
anything that could be offloaded would probably be desirable. Plus, calls
that were not initiated by
a dialplan "Dial()" invocation might not be able to provide that option.
Another question: what do you need this functionality to *do*? It could be
that there is an already
existing functionality that you could exploit to get the same results?
murf
>
>
>>
>> On my system I do *2 and asterisk says transfer, then I punch in the new
>> extension.
>>
>>
>>
>>
>> --
>>
>> *From:* asterisk-users-boun...@lists.digium.com [mailto:
>> asterisk-users-boun...@lists.digium.com] *On Behalf Of *Olivier
>> *Sent:* Friday, May 29, 2009 10:29 AM
>> *To:* Asterisk Users Mailing List - Non-Commercial Discussion
>> *Subject:* [asterisk-users] Attended transfer and dialplan
>>
>>
>>
>> Hi,
>>
>> How can you add specific statements into Asterisk dialplan (extension.ael,
>> ...) for attented transfers ?
>>
>> I can see Asterisk sending Transfer or Masquerade events through AMI (in
>> 1.6.1) but I could use an external program to catch those events but I would
>> prefer to use dialplan instead.
>>
>> Any idea ?
>>
>> Regards
>>
>> --
Steve Murphy
ParseTree Corp
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR question
Jim-- On Thu, Jun 4, 2009 at 1:40 AM, Jim Boykin wrote: > Hi, > > Asterisk does not post CDR when dial status is CHANUNAVAIL. CDR's are, at the current time, and always have been attached to the channel struct; so, if you don't create a channel, then there is nowhere to attach a CDR, and no way to process that. > > > Can someone tell me what are the conditions under which CDR is not posted? We try to filter the CDR if a channel were created, but did nothing; an example is where a Dahdi device is taken off hook, and then hung up again. But getting all the conditions right has been tricky to filter this sort of event sequence. I think you'll find that CDR's are one of the least solid parts of Asterisk at the moment. There's brave and creative folks working on fixing the current implementation, but as far as I'm concerned, it's got some fundamental problems, and needs to be overhauled. If you are interested, you can read my spec for a new approach by: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and then looking at the pdf in that dir, for my spec for the CEL->CDR proposal. While I have abominated the complexity of the ForkCDR/NoCDR/etc mechanisms of the current solution, I have considered making the spec include them for backward compatibility... Current implementations based on the current mechanisms shouldn't have to be made obsolete, although they usually do depend on a great deal of undocumented behavior, that may be tricky to imitate. murf > > > Thanks > Jim > > -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to write custom functions in AEL2 ,
On Mon, May 11, 2009 at 1:30 AM, Olivier wrote:
> Hi,
>
> I'm using asterisk 1.6.1 and AEL2.
> I'm trying to find the best way to write my own custom functions ?
>
>
> At the moment, I'm using this pattern (extensions.ael) :
>
> context foo {
> 123 => {
> &myfunc(123456);
> NoOp(${GOSUB_RETVAL});
> };
>
> macro myfunc (arg) {
> Return (${arg});
> }
>
> 1. First, I keep getting warnings like
> Warning: file /etc/asterisk/extensions.ael, line 446-446: application call
> to Return affects flow of control, and needs to be re-written using AEL if,
> while, goto, etc. keywords instead!
> and I would like to get rid of them.
>
This is easily done. Return() is calling the Return application; 'return',
however, is the keyword the AEL uses. Note the lack of a capital R at the
beginning of
the word "return". AEL is case sensitive and "Return" is not equal to
"return".
Also note that, as a previous reply mentions, that return takes no args,
that there is a patch available to upgrade to do that.
You don't need the patch to do what the patch does, tho. But, not having
refreshed my memory on the particulars, I will say
no more!
>
> 2. Secondly, I would like not to use GOSUB_RETVAL and call a custom
> function just like I'm calling other functions with statements like :
> 123 => {
> NoOp(TOLOWER(fOo BaR));
> NoOp(myfunc(123456));
> };
>
>
Again, check your version of Asterisk against whether AEL uses Gosub() to
implement macros.
The AEL2 wiki page on voip-info.org (
http://voip-info.org/wiki/view/Asterisk+AEL2 ) can also
be quite helpful at times!
> What would you advise me to do ?
>
> Regards
>
>
>
> ___
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Leg-based CDR proposal updated; Major mods
Hello! It's me again. I began a fairly large modification to my CDR proposal some weeks ago, and finally yesterday and this morning got enough accomplished to allow a commit and some peer review. Check the docs out via " svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs " This is a directory; in it you will find: CDRfix2.rfc.doc CDRfix2.rfc.docx CDRfix2.rfc.pdf The docx version is the one I actually edit; the doc verison should be editable in both the windows and linux worlds. The PDF version is for those who just want to read it. Basically, I modified the doc to turn Leg-based CDRs into Simple CDR's with splits (both automatic and dial-plan generated). Instead of a single time line for complex conversation, broken into consecutive segments, now you have N time lines (one per participating channel). A Leg-based CDR system devolves into a Simple CDR system when all the automatic and dial-plan splitting is turned off. This makes things easier to implement and understand. At least, for me! (If I don't understand it, I doubt I can make YOU understand it!) Also, I gave uniqueID's an overhaul based on the idea of REFERENCING. I think most users have misunderstood the uniqueID field in the current CDR system, and don't see the possibilities that solid referencing would open up. I introduce the idea of uniquely identifying channel 'instances', which are what Asterisk creates when it creates a channel struct internally. The uniqueID field on the CHANNEL struct uniquely identifies that channel instance across time for a single server. (Currently). (barring masquerades). These are what are REFERENCED by my destchannel, and channel fields. I provide new fields called "channel_uniqueid" and "dstchannel_uniqueid" to reference these fields; not just the channel name (dahdi/1-1 doesn't quite suffice across time.) (But I left the old fields alone for those who prefer device info). CDR unique ID's can/will be generated for external usage, but are not available to the dialplan or apps within Asterisk. Thus, only external referencing is possible to individual CDR records. But this should be good enough, I think! This may or may not help with issues brought forward a while back by greyman and others, -- I'd appreciate hearing about it. murf -- Steve Murphy, Pres, Consultant ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple(?) dialplan question.
On Sun, Mar 22, 2009 at 4:09 AM, Asterisk wrote:
> Hi List,
>
> I have a nice simple dialplan question for you Currently, I have
> definitions similar to the following in my extensions.conf file, to allow
> me
> to dial out using a variety of channels:
>
>; Direct dial (number starts with zero), use 0151 xxx :
>exten => _0.,1,Set(CALLERID(number)=0845xxx)
>exten => _0.,n,Dial(SIP/${ext...@sipgate,90,t)
>exten => _0.,n,Playback(invalid)
>exten => _0.,n,Hangup[/code]
>
> (I've munged some of the numbers, hence the x's)
>
> Now, this works fine provided the person answers in 90 seconds or less: If
> not, I get "that option is invalid" announced, and it hangs up. I want to
> do
> this:
>
> If DIAL fails because the other party is engaged, I'd like Asterisk to
> automatically re-try the number, for as long as I've got the handset off
> the
> hook or until the other party starts ringing. As there'll be no ring tone,
> it'd be nice it it could play music until DIAL succeeds in getting a ring
> tone; at which point it makes "ring ring" noises (this will serve as my
> prompt that - hopefully - someone's going to answer soon).
>
> If DIAL fails because I got the number wrong, then a PLAYBACK to that
> effect
> would be useful... I can record my own soundfile if there isn't a standard
> one. By wrong, I mean the exchange would return number unavailable, rather
> than I get the wrong person!
>
> If DIAL fails after it's been ringing for ages (e.g. when calling the local
> Post Office sorting office, who only answer 1 in 5 calls), I'd like it to
> retry, ala the busy response.
>
> IF DIAL exits because the other party hung up, I'd want it to simply hang
> up
> on me like it does now. I suspect this is standard behaviour? But maybe it
> tries to read the invalid announce to a closed channel with my dialplan,
> I'm
> not sure.
>
> If the above can be achieved in extensions.conf, that's great, as I've not
> done any AEL... but if AEL (or AGI, even) is the only way, so be it...
You can do it all three ways.
In AEL, you'd do something like this
context internalexten
{
_0. => {
Set(prevstatus=NOANSWER); /* set up a prevstatus */
Set(CALLERID(number)=0845xxx);
while("${prevstatus}" == "NOANSWER" || "${prevstatus}" ==
"BUSY")
{
Dial(SIP/${ext...@sipgate,90,tm); /* transfers and moh
*/
switch(${DIALSTATUS})
{
case CHANUNAVAIL:
Playback(bad_num);
hangup();
break;
case CONGESTION:
Playback(congested);
hangup();
break;
case BUSY:
case NOANSWER:
break; /* BUSY will fall thru into NOANSWER */
default:
break;
}
Set(prevstatus=${DIALSTATUS});
}
hangup();
}
}
The above code should (I haven't tested it or anything) give you most of the
behavior you
specified, but it will play MOH up to the time someone answers. No
ringing/moh mixture...
Dial doesn't do that. You may have to correct some typos, etc. that I've
made above!
A hangup from the remote end will end the Dial app, and the result should be
ANSWER,
which should drop you out of the loop and end the call.
Also, a hangup from the dialing exten should just terminate the dialplan
execution.
I might note that the above code should be easier to read than the equiv
extenstions.conf
code! But, I guess I'm biased!
murf
--
Steve Murphy
ParseTree Corp
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Global h exten
On Wed, Mar 18, 2009 at 11:57 AM, Steve Edwards wrote: > On Wed, 18 Mar 2009, Gabriel Ortiz Lour wrote: > > > Is there something like a global h exten, that gets called on every > > hang up, no matter what exten? > > (no matter what context) > > Nope -- but it sounds like a great idea. > > I do it this way... > > I define an "h" template: > >[h](!) >exten = h,1,goto(finish-call,h,1) > > And then every context references the template: > >[block-me](digit-timeout,h,i,max-timeout,pound-main,s) That's an elegant way to do it, another in AEL, would be to define a context with an h-exten, and include it in your other contexts... Just beware, that the h-exten is NOT ALWAYS called; the in the channel/peer role world, the h-exten is usually called on just the channel in the channel role. The parking manager doesn't run the h-exten if a channel hangs up while parked. And channel and peer roles can sometimes get a bit confused in transfer scenarios. The truth of each sentence above will surely change with new releases... murf -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] log to cdr each dialpan action, not only one record for each call
On Thu, Mar 12, 2009 at 1:13 PM, Matt Riddell wrote: > On 13/03/2009 8:02 a.m., nik600 wrote: > > Hi to all. > > > > What can i do if a customer needs to log in the CDR all the dialpan > > actions related to a call? > > I mean, not only the lastapp e the lastdata but all the dialpan actions! > > > > I know that the actual CDR system store one record for each call (and > > for billing purposes this can be correct) but in some cases the > > approach needed is something similar to the queue_log. > > > > I know that exists ResetCDR and ForkCDR but they don't do what i need, > > expecially because they fill-in lastdata and lastapp with "ResetCDR" > > > > So, what can i do? > > Use the Asterisk Manager with UserEvent? I think Matt's approach is more practical; Really, you can't just use the CDR logs, because that's what isn't enough for you. Some folks have reported getting by with a mix of CDR's and manager events, but ooo, it's ugly! It can be done, tho. But you could read my proposed CDR doc by checking it out of SVN: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and reading the pdf in the dir that will be created, and letting me know what you think of it. The Leg-based approach with your own splits might be the ticket you are interested in. Now, I might add this: surely you are jesting about *every* dialplan command! Most dialplan apps that get used are things like "gotoIf" and such, that take some number of microseconds to execute. It'd be silly timing such, as the CDR records are currently rounded off to whole seconds. My current thinking is to specify exactly which app invocations you want to track; those involved with dialing would be automatically tracked. Or time groups of invocations via forcing a leg-split via a simple dialplan application call... again, read the doc, and let me know what you think. murf -- Steve Murphy ParseTree Corp ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Are .call files working with extensions.ael ?
On Wed, Mar 11, 2009 at 5:29 PM, Olivier wrote:
> Hello,
>
> With an extensions.ael enabled system, I keep getting whatever I change
> into my "astup.call" file :
>
> [Mar 12 00:13:56] WARNING[2538]: pbx_spool.c:267 apply_outgoing: At least
> one of app or extension (or keyword message/pdu) must be specified, along
> with tech and dest in file /var/spool/asterisk/outgoing/astup.call
> [Mar 12 00:13:56] WARNING[2538]: pbx_spool.c:457 scan_service: Invalid file
> contents in /var/spool/asterisk/outgoing/astup.call, deleting
> [Mar 12 00:13:56] WARNING[2538]: pbx_spool.c:505 scan_thread: Failed to
> scan service '/var/spool/asterisk/outgoing/astup.call'
>
Olivier--
It's complaining that you don't have "Extension: " and "Priority:
. " lines in your call file, along with the context,
The Channel: lines calls one phone, the Context, Extension, and priority say
what to execute for the other channel,
and the two are bridged.
Whether the context, exten, and priority specified are in an AEL supplied
dialplan or an extensions.conf
dialplan, doesn't matter. You can even mix both together to form a dialplan.
Let's see, I have a call file laying around...
Channel: Sip/snom
Context: workext
Extension: 983075878001
Priority: 1
...
This will ring the phone specified in Channel, and when it answers, it will
run the extension you specify, and connect the two. (in this case it will
dial the "movie hot line" in Cody, WY, and the leading "98" says to use
a certain ISP to place the call.
murf
>
> With an extensions.conf enabled system, the same "astup.call" file would
> work.
>
> Has anyone tried ?
> Any hint ?
>
> Channel: sip/7...@mylocal
> CallerID: 692 <692>
> MaxRetries: 1
> WaitTime: 60
> RetryTime: 5
> Context: mylocal
> Extension: 00123457530
> #Priority: 1
>
> I suppose I should have written "mylocal" context in a different way as my
> extensions.ael includes :
>
> context mylocal {
> includes {
> subs;
> };
>
>700 => ...
> };
>
> Regards
>
> _______
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Steve Murphy
ParseTree Corp
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [asterisk-dev] 1.4 and CDRs -- The Breaking Point
On Sat, 2009-02-07 at 15:51 -0500, Alexander Lopez wrote: > > > -Original Message- > > From: Steve Murphy [mailto:m...@digium.com] > > Sent: Saturday, February 07, 2009 1:59 PM > > To: Alexander Lopez > > Subject: RE: [asterisk-dev] 1.4 and CDRs -- The Breaking Point > > > > On Fri, 2009-02-06 at 12:28 -0500, Alexander Lopez wrote: > > > > > > Looks good so far but let me make a few points some are redundant as you > > > have already covered them in your document, others may present an > > alternate > > > view (SNAFU) > > > > > > > > > I my opinion a call is a call, doesn't matter where it went or how many > > > times it changes legs. > > > > > > A call should have a single unique call ID. > > > > > > For example > > > > > > Call begins 0:00 > > > > > > Sales (A) calls customer (B) > > > customer states they have a problem, Sales (A) tranfers Customer (B) to > > > Support (C). > > > Support look up Customer determines they are not in system transfers to > > > Accounting Queue for Help (D) call leaves accounting and goes to support > > > queue (E) call gets handled by support engineer (F) then transfered back > > to > > > different salesman (G) > > > > > > In this case I would have ONE call lasting 25 minutes, with events in > > > between. > > > > > > I should have two records one with a summery of the call. > > > > > > CallID lasted 25minutes on such and such a date and time, originated by > > (A) > > > and answered by (B). > > > > > > And second set of records showing the detail or the calls. (Your chart > > in > > > the document would be fine) > > > > > > > Alexander-- > > > > From the above, I'd guess that the Simple CDR spec might be appealing to > > you. > > In that scenario, you'd get one CDR for each channel involved in the > > total > > call, but the interesting one would be the one with Party=B in this > > case. > > > > CDR: Party: B; channel: A, dstchannel: B, start: When B was dialed; > > ans: when B answered; end: when B hung up; disposition: ANSWERED. > > > > There would also be CDRs for A, C, D, E, F, and G; Each would reflect > > who > > called them, when they answered, when they hung up (ended). > > > > CDR: Party: A; channel: A, dstchannel: ; start: when A went > > offhook or submitted call, dep on tech; ans = start time, if applicable; > > end: when A > > xferred to C and got dialtone. > > > > CDR: Party: C; channel: A, dstchannel: C; start: when C was dialed; > > ans: when C answered; end: when C xferred or hungup. Disp: ANSWERED; > > > > CDR: Party: D; channel: C; dstchannel: D; start: when D was dialed; > > ans: when D answered; end: when D xferred to E... > > > > and so on. > > > > All the above would have the same LinkedID (as discussed in the doc), > > but this may not make much difference to you... you seem to be > > concerned about only the one situation, and the rest could be ignored. > > > > I'd imagine you could tell that all but B were "internal" locations, > > and B's CDR is probably the only one you'd be interested in billing > > for in this case, since B is the destination of the call. A would or > > should foot the bill for the call, no matter how many others talked > > to B (at least in my opinion). Deciding who's interesting for billing > > is not Asterisk's job. It's up to your CDR processing s/w to toss out > > the uninteresting CDRs. > > > > Do you agree, or is something fundamental missing here that you need? > > > > murf > > > > -- > > Steve Murphy > > Digium > > > > If I get to call you Murf, You get to call me Alex... > > The scenario I portrayed was for a corporate PBX, not a switch used to > sell/process minutes on Pre-paid. On all of the PBXs I have worked on, > management is looking for a few things. > > 1 Who called who > 2 Are my sales reps / customer service reps placing the calls they > need to. > 3 How long was the caller / callee on hold (could be told by Events in > the detail CDR) > > > I like your idea of a detail written to the every time an Event > happens, (IE Hold, Park, Transfer, Queue, Agent, Application, etc.) One of > the issue I have is that I have no idea what the call went through from the > CDR as it stands. >
Re: [asterisk-users] CDR 0.00 duration
On Wed, 2009-01-21 at 15:45 +0530, Sriram wrote: > Hi > > I am using Trixbox 2.4 and PRI lines..on the CDR i see many calls that > have duration of 0 seconds, but they are still shown as ANSWERED . how > come its possible when duration is 0.00 ? Are the callers billed for > such calls ? > > Rgds > Sriram > Sriram-- Well, if the end or ANSWER time isn't set, then you would get a 0 duration. murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to overwrite CDR(dst) value in h priority?
On Mon, 2009-01-19 at 08:45 -0500, Zeeshan Zakaria wrote:
> Hi everyone,
>
> In one of my contexts I run h priority in which I need to change the
> CDR(dst) value. But it doesn't work and in the CDR dst field is
> recorded as h.
>
> Context abc {
>
> 111 => {
> ...
> ...
> ...
> };
>
> h => {
> Set(CDR(dst)='111');
> NoOp(${CDR(dst)});
> Hangup();
> };
>
> };
>
> Can anybody give me an idea how to accomplish this task? In my CDR I
> need to see 111 in the dst field and not h.
CDR is specifically written to only allow certain fields to be modified.
dst wasn't one of them.
If you get rid of the h extension entirely, it won't cause an update
of the CDR. If I had to keep to the h exten (because it did other things
than just try to reset a value which was set by running the h-exten),
then I'd get rid of the Hangup() call, because it's useless. (The
h-exten
is being run because of a hangup situation in the first place.)
murf
--
Steve Murphy
Digium
smime.p7s
Description: S/MIME cryptographic signature
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Tue, 2009-01-13 at 21:09 +0100, Benny Amorsen wrote: > I wrote a really long email, but it hinged on one thing I need > clarified... > > tir, 13 01 2009 kl. 09:05 -0700, skrev Steve Murphy: > > > CDR1: A -> B start: e1a ans: e2 end: e4 Party: B disp: > > ANSW linkedID: abc9 > > CDR2: A start: e1 ans: e1 end: e6 Party: A disp: > > ANSW linkedID: abc9 > > > We are talking about the "Simple" CDR's, not the leg-based ones, > right? If so, why do all the CDR's only call one "Party"? Shouldn't > there be a src and a destination? > > > /Benny > Benny-- First, yes, all the examples I gave were for Simple CDR mode. Next, the notation is simplified. A -> B means channel: A dstchannel: B (A and B are also contractions for stuff like "Dahdi/1-1" or "Sip/bob-1") start, ans, end are the 3 times (e2, e3, etc are event times (symbolic); disp is the disposition field. linkedID is described in the doc. I don't specify src/dest, in the examples, as they really don't convey much without all the background description, (if I said src = '101' and dest = '202' you'd have to know the associated contexts, etc. -- a can of worms)--- but every CDR will specify those fields for the Dial (or whatever else was responsible for activating the channel). I also didn't spell out stuff like userfield, amaflags, callerid fields, etc; it isn't that they aren't important, it just clouds the examples to get too explicit and verbose. The main thing about these fields is that they are in the list of CDR fields and described in the CDR field section. The "Party" field says which channel this CDR applies to. I use it because the channel/dstchannel aren't always going to involve the channel in question. Usually, tho, Party will either be the channel or the destchannel. Knowing which one is the trick. And, as a side note, the A CDR in my examples usually lacks a dstchannel field, because it's not being activated by a dial-- it's being activated via an incoming call on an FXO interface. (or an incoming SIP invite, maybe...) And, if I'm missing info that would really, really, necessary to have, or hard to inject from the dialplan, now is the time to fight to make sure that it is in the spec. murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] [Re: CDR Rewrite -- Questions to the users]
Benny-- Thanks for the response! I've inserted comments in the following: PS. Pardon the HTML format; my email editor splits lines at an unadjustably small number of columns, but in HTML, no line length limits, and better looking examples! On Tue, 2009-01-13 at 14:16 +0100, Benny Amorsen wrote: > Steve Murphy writes: > > > Which of the two would you see being useful to you? > > "Leg based", as far as I can see, because that looks like the only way > to bill transfers differently depending on which end did the transfer. > > Possibly "Simple" on the Asterisk systems where we forbid transfers. > > > Is there Yet Another CDR system you would like to see instead? > > How would/should it work? > > "Leg based" looks good. > > > Will both fulfil the requirements of CALEA? > > We're not yet operating in a jurisdiction where CALEA applies. It > looks good enough for the jurisdictions we operate in, possibly apart > from the transfer issues further down, but I am certainly not a > lawyer. > > > It's been proposed that we implement just the Simple > > CDR now, and it be introduced in some 1.6.x (or higher) > > release. In that release, the existing CDR system would be > > deprecated, and in some "futurer" release the "old" (now current) > > CDR system would be dropped entirely. What do you > > think? Are we high on drugs, or what? > > I need this functionality for transfers, and I don't think "Simple" > provides it: > > A calls B: A pays for the whole duration for A => B > B transfers to C: B pays for B => C, A is still paying A => B > Good Question: Can Simple CDRs be used in xfer situations? Let's take a look. In this particular situation, 3 channels are involved: A, B, and C. Therefore, you will get 3 CDRs. CDR1: A -> B start: e1a ans: e2 end: e4 Party: B disp: ANSW linkedID: abc9 CDR2: A start: e1 ans: e1 end: e6 Party: A disp: ANSW linkedID: abc9 CDR3: B -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9 CDR2 covers A (see the Party field), CDR1 covers B, CDR3 covers C. A's CDR could be used to bill A for his call in. It covers both the time A spent talking to B, and C. If you charge a different rate for A talking to B vs C, then you have some interesting SQL queries to make, I'll guess... C's CDR records that B called C. It doesn't mention that A is doing all the talking. B's CDR records the call from A to B; this is the only one that seems a little useless... Is this enough? If this is all you had, could you make it work? If you can't, would adding a field or two help? > If it was A who transferred the call instead: > > A calls B: A pays for the whole duration for A => B > A transfers to C: A pays for A => C, and A is still paying A => B > B and C get to talk for free, while A pays twice. > In the SImple CDR world, here's what would be produced: CDR1: A start: e1 ans: e1 end: e4 Party: A disp: ANSW linkedID: abc9 CDR2: A -> B start: e1a ans: e2 end: e6 Party: B disp: ANSW linkedID: abc9 CDR3: A -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9 Here, A's total connection time is in CDR1; B with CDR2; C with CDR3. The call from B to C is in CDR3. A's transfer to C is in CDR3 (I just corrected this in the CDRfix2 document). Again, is there enough info here for you to do what you need to do? If not what addition could be added to make it work? > This should apply whether transfers are attended (soft), unattended > (hard) or caused by SIP redirections before answering. Ideally it > should also be possible to simulate SIP-like redirections in the > dialplan with the same CDR behaviour. > In the CDRfix2 doc, I outlined both the above blindxfer cases, and also permutations of attended xfers. Look them over, and see if what you need is possible with this format, and if not, is there something we can add that *would* make it usable...? murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Rewrite -- Questions to the users (Steve Murphy)
On Mon, 2009-01-12 at 17:08 -0200, David fire wrote: > > > 2009/1/12 Russell Brown > Quoth Steve Murphy... > >Date: Mon, 12 Jan 2009 08:51:03 -0700 > > > >QUESTIONS: > > > >Which of the two would you see being useful to you? > > Obvious comment really but given LEG based CDR, one can > determine the > 'Simple' data but you can't work it the other way. > > I'd therefore find LEG based CDR more useful as the > granularity (time on > Hold, in Queue, Waiting on pre-xfer ring etc etc) would be > good. > > > -- > Regards, > Russell > > hi > one question, i will need to rewrite all my apps that use the cdr? > and the queue_log will be rewrited? > thanks > Well, the wish/plan/whatever, if followed thru, would require people who have software that works with the existing CDR's, to tweak their code to work with the new regime. I don't think the queue_log stuff will need to be modified, at least with respect to CDR's, as all they do is reference the uniqueID... there may be other reasons pertaining to enhancements, etc. that might demand some code update there, but that's not in the realm of CDRs. By "tweak their code", is might involve a few lines of update, or a total rewrite, I don't know. But the idea is make the specs for the new system as public and known as possible in advance of a new implementation. The period of time during which the old code would still exist would be an entire release, so that gives you probably about 2 years... in the meantime, we'll probably want to cease maintaining the old code. That should mean that the old code should actually become more stable, because so far, it's very difficult to change ANY aspect of the current CDR system without introducing new regressions. Given the fact that the current implementation has serious problems, holes and gaps wrt to parking, xfers, etc, and is so hard to maintain in its current format, the long-term goals of reducing the cost of maintenance, and getting higher reliability, hopefully will make the effort of recoding worth that effort. murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Mon, 2009-01-12 at 19:26 +0200, Apostolos Pantsiopoulos wrote: > Steve Murphy wrote: > > Hello! ... > Hi, > > The specs look very promising. I think everyone > here should be grateful for your efforts. In answer to your > question I personally find both approaches very useful, although > I would prefer to see the "simple" approach implemented first > chronologically since I believe it is simpler to implement and we > could > get immediate results. > One small question. I tried finding the "peeraccount" variable > that > was brought up many times in past emails in your CDRs fields > descriptions > but I couldn't. This field was supposed to hold the accountcode for > the terminating side > (and could be set for each channel using CHANNEL()) according to > this : > > http://www.venturevoip.com/print.php?rssid=2011 > > Is this field going to be implemented? Yes, it will. I apologize for that omission. I will correct the CDRfix2.rfc.txt file, so it properly mentions this var. (small wait, while I go do it). There, now, rev 168504 of that doc contains peeraccount in both the Simple and Leg-Based sections. User modifiable, with a little verbage as to how. Thanks for catching that, btw!! murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Rewrite -- Questions to the users
Hello! Most are probably bored seeing another letter about this, but I've put in a fair amount work on a spec for rewriting the CDR system in Asterisk, and I have some questions: First, please look at what I've written so far: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and look at the file "CDRfix2.rfc.txt" in the RFCs dir. The spec SIGNIFICANTLY alters the way CDRs are generated, how they are structured, and what they express. If you have ANYTHING to do with CDRs, then it is critical you become involved in the design process for the new system! Or suffer with the results! What's going on? I wrote up two modes of CDR generation: Leg-Based, and Simple. A new field, "linkedID", that can be used to link CDRs as part of the same total call. Leg-Based is (or can be) very detailed. Every CDR has a type, like CALL, AXFER, BXFER, PARK, etc. Depending on what actions occur during a call, a call can be split up into several "legs". A dialplan func to insert an event that will create a new "leg" will be available, with its own user-specified type. Simple is just that. One CDR is generated per activated channel. The start time is when it was created. The end time when it died/hungup. The answer time is... you know! No fine-grained details. No dialplan fanciness. linkedID can help you group channels involved in a single 'logical call'. QUESTIONS: Which of the two would you see being useful to you? Is there Yet Another CDR system you would like to see instead? How would/should it work? Will both fulfil the requirements of CALEA? It's been proposed that we implement just the Simple CDR now, and it be introduced in some 1.6.x (or higher) release. In that release, the existing CDR system would be deprecated, and in some "futurer" release the "old" (now current) CDR system would be dropped entirely. What do you think? Are we high on drugs, or what? murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Fri, 2009-01-09 at 04:24 +, Grey Man wrote: > On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy wrote: > > > > But, since it is timestamp based, and unique in that the final part was > > incremented per request in the same sec, it made a great item to sort > > on, and allowed me to implement linkedID's. > > Again that's mixing fields that shouldn't be. The calldate or > starttime can be used to sort the CDRs on creation time. If you're > going to call a field uniqueid surely a good effort should be made to > make it live up to its name. If it's intended to be a sequenceid then > that's what it should be called. Sorry, I apologize for the 'uniqueID' field; I didn't invent it, or name it, and there is little definition for it. I think it's accidental that a transfer could yield two CDRs with the same uniqueID. I'm all for just simply dropping it. Maybe I will. LinkedID on the other hand, is a way to associate 'linked' channels. A linkedID is guaranteed (on the same Asterisk server) to be unique from any other linkedID that has been issued by that server. By appending another string, you can guarantee it is unique across systems. So, if you use a system name, or Asterisk server name, that you yourself guarantee to be unique among all the asterisk servers that would contribute CDRs to a database, you achieve complete, guaranteed uniqueness. If you use instead a 36-byte UUID, you avoid having to invent the unique system names, but the complete uniqueness guarantee is off. The chances of a collision are pretty small, so they are 'practically' useful. But still, to be mathematically precise about it, simple servernames are infinitely more unique than UUIDs. 10^36 is a big number, but infinity is even bigger. and the ratio between the two is infinity. Now, as to splitting the currently per-server unique label from the per-network part of the label, well, I'm dense, I know, but I still don't see any overriding reason to do so. Yeah, it might be cool to call the uuid part of the label a uuid, but really, it's silly. Now you have to use two fields to get uniqueness. Not cool. Just because a DB understands a UUID, doesn't mean you are obligated to separate it. Just because a language has a feature, you are not obligated to rewrite perfectly working code to use it, especially if it obfuscates what is going on, opens the door to bugs, etc. etc. I don't see any reason, either (and I could be missing something really obvious here, I admit), for providing a field that *is* unique to every CDR generated. When the CDR is entered into a table in the db, it occupies a certain row in that database. That row number will be guaranteed to be unique. Since nothing in the Asterisk world references that data once it's written, there would be little purpose in generating it. If you need a unique ID that spans all CDR's ever written to that db, across time and space, even if after a year or so, you prune all the old CDR's from the DB, and allow the row numbers to be reused, then *that* might justify such an ID. (you could search backups or something for that entry, if some customer brings up a problem after a year)... But, if your DB understands uuid's, then can't you automatically generate one for it via an entry in the table definition? And, the linkedid already provided is timestamp based, so across time, it will never be repeated. So, I'm still not seeing any reason why you need to dissect the linkedid field. How it was built doesn't matter, as long as in total, it has the necessary uniqueness property. And here's another thought. I could imagine that, if we appended a system name to the linkedID to guarantee its uniqueness, we might also like to have the system name in the CDR, so we could make queries and see if any of the Asterisk servers are busier than the others, etc. I wouldn't dissect the linkedID to get it; I'd add the system name as another column. But that's just me... If I'm missing something, educate me. I need to understand this sort of stuff to be able to write a useful CDR system. > > > I guess I could simply have > > used a simple integer for a linkedID, and had a routine somewhat like > > the one that coughs up the uniqueID's, just use a lock to provide > > a number that is incremented safely, (atomic_fetchadd_whatever) > > and hand it out. Then I could have > > used a numeric comparison. Might be faster. Maybe Someday... > > > > But, it is NOT a number. It's got a period in it but uuids usually > > have dashes. It's a string. Why you would rip off a system name, I > > cannot guess, unless you really want or need to deal with it as a > > number. > > > > My advise is not to. I have no prob wit
Re: [asterisk-users] Simple CDRs
On Fri, 2009-01-09 at 01:53 +, Grey Man wrote: > I would be interested in additional information in the CDRs as I'm > sure others would. My worry is it's not a critical peice of CDR > information and because it sounds like information being generated at > the dialplan level it could end up being complicated to implement or > confusing to desgin and become a distraction from getting the core CDR > fields sorted out. I tend to agree. We were discussing this sort of thing on IRC today, some of us devs, trying to guess what new things users might throw at us as to requirements for the new CDR system(s). I have a feeling that there will ALWAYS be implementers that will have a need for very... interesting pieces of information, and will want to see them in the CDR system. But, there is a "userfield", and users can set it in the dialplan. As long as funcs like CHANNEL() can get at the info you'd like to have, then you can always shove that info into the userfield. If CHANNEL() doesn't make a field available, it can easily be expanded. (At the current moment, CEL doesn't carry channel vars into the event data; it seems a pretty wasteful business; perhaps in the future, I can make it so any channel vars starting with "cel-" would be copied into the event data. In the meantime, copy what info you need into the userfield.) Another customization need would be where CDR's would be split-- what kind of things you want to time. The Simple CDR spec really wouldn't allow any splitting, but the leg based CDR approach would provide a simple call in the dialplan to split a cdr and assign a type to the newly completed CDR. I honestly can't think of any other operations that might need to be done, except attach extra info to a generated CDR; the only question would be when it would be best to attach it; and that's something we have to think about. Before a dial, so the dial event/answer event records it, or just before the channel closes (h exten?) or whatever... In the case of CDR-legs, the timing of when you store info on the channel, determines which leg(s) the info appears on. There are possibly a lot of games that could be played with this. There are/were a few bugs in the tracker that basically were complaining about missing information. In most cases, this was due to the fact that there were two place where data was being stored: on the channel, and in the CDR struct. And there is/was no simple explanation of when the channel information was updated into the CDR struct(s). Well, the new system will have simple rules to allow you to predict when certain info on the channel will be taken to be copied into a CDR. (I hope). Another side-effect of moving the CDR system out of the pbx loop is the fact that the h-exten may or not be the best place to try to add/mod CDR related data any more. I could go on (and on) about the h-exten, (for those of you wondering what the h-exten is, it's the hangup extension in the dialplan; the pbx will execute that extension when the channel is being hung up.)... but I won't. Just my thoughts on the fine points of the to-be-developed new CDR system... murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Fri, 2009-01-09 at 01:40 +, Grey Man wrote: > On Thu, Jan 8, 2009 at 7:22 PM, Asterisk Development Team > wrote: > > Actually I could see appending a 'servername' to the UUID as useful in a > > clustered environment. Every time I don't think I need to do that, I end > > up having to do it. And since this would be a configurable appendage, it > > shouldn't hurt anything. > > I would argue against that. If the server name is useful in the CDR > then add another field for it. I for one load CDRs to and from a > database using a typed langauge and would be utilising the UUID field > as a specific UUID type. If the server name has been tacked on I'll > need to do some string parsing to take it off. That aside I don't > quite understand the reluctance to rely on the uniqueness of a UUID. I > like the wikipedia description (http://en.wikipedia.org/wiki/UUID) > where a clash in randomly generated UUID has a probability greater > than 10^36 whereas the probability of Earth being hit by a meteor is > estimated as one in 17 billion. > > Where I and I'm sure others want to use the current "uniqueid" CDR > field is as the primary key in a database. Being able to rely on at > least one field in the CDR being unique solves a lot of probelms for > billing engines such as if the billing engine stops and starts has a > particular call been billed or not. At the moment the "uniqueid" is > next to useless for those of us putting CDRs into a database. > As to the 'old' uniqueID, I agree, it was of extremely limited use. Firstly, it was not really unique. In several xfer situations, you would end up with two cdrs that had the same uniqueID, because of the way the the CDRs were transferred during a masquerade, methinks. So you couldn't use it as a 'unique' key -- the row # would be better. And it couldn't really even be used to tie CDRs together in any useful way. But, since it is timestamp based, and unique in that the final part was incremented per request in the same sec, it made a great item to sort on, and allowed me to implement linkedID's. I guess I could simply have used a simple integer for a linkedID, and had a routine somewhat like the one that coughs up the uniqueID's, just use a lock to provide a number that is incremented safely, (atomic_fetchadd_whatever) and hand it out. Then I could have used a numeric comparison. Might be faster. Maybe Someday... But, it is NOT a number. It's got a period in it but uuids usually have dashes. It's a string. Why you would rip off a system name, I cannot guess, unless you really want or need to deal with it as a number. My advise is not to. I have no prob with uuids, except that they are 36 bytes, and overkill for uniqueness. linkedID + system name would be totally sufficient; One glance at the linkedID will tell you immediately what sys it came from, if you did that. But it's quite legitimate to want to use UUID's. I have no idea how much processing power they take to be generated, probably not much. There's pros and cons... just a thought, murf > Regards, > > Greyman. -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AEL question: testing channel variables
On Thu, 2009-01-08 at 19:24 +0100, Klaus Darilion wrote:
> Hi!
>
> I use the following condition:
>
> if (${FOOBAR}=YES) {
>...
> }
>
> The problem is, that if FOOBAR is not defined at all Asterisk generates
> a warning:
>
> WARNING[11982]: ast_expr2.fl:407 ast_yyerror: ast_yyerror(): syntax
> error: syntax error, unexpected '=', expecting $end; Input:
> =YES
>
>
> Of course I could use the following code, but this bloats up the code:
>
>
> if (${EXISTS(${FOOBAR})}) {
>if (${FOOBAR}=YES) {
> ...
>}
> }
>
>
> Is there another syntax to have nice looking code but avoid the warning?
Klaus--
The simplest I can think of is:
if ("${FOOBAR}"="YES") {
...
}
adding the quotes just makes it so if ${FOOBAR} evaluates to nothing,
then it will still end being a token, and you avoid the syntax error.
You have to keep in mind that by the time the $[ ... ] exprs are evaluated,
all ${..} constructs have been recursively evaluated away.
the wiki is a good reference for AEL2...
(http://voip-info.org/wiki/view/Asterisk+AEL2
and there is a page of example snippets.
murf
>
> thanks
> klaus
--
Steve Murphy
Digium
smime.p7s
Description: S/MIME cryptographic signature
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Thu, 2009-01-08 at 16:20 +, Grey Man wrote: > On Wed, Jan 7, 2009 at 6:01 PM, Steve Murphy wrote: > > On Wed, 2009-01-07 at 02:56 +, Grey Man wrote: > >> On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy wrote: > >> > >> That sounds a bit dangerous to me. If you go down the path of setting > >> the answer time based on dial plan applications or events you'll need > >> to understand and modify every dial plan application that can answer a > >> call. To me it would seem a lot simpler to do the > >> override/modification in each channel or even better even lower in > >> ast_channel. A channel has to have a very clearly defined definition > >> of answer and hangup whereas dial plan applications don't. > >> > > > > Hadn't thought along that line before: classifying the *kinds* of > > Answer. > > But we may not have to bother In this mode, a single CDR could > > cover several dial attempts and their corresponding "answers" > > incoming caller A could, during his lifetime in Asterisk, dial > > several users, say via assisted xfers, and have the targets hang up > > first, leaving his channel intact. It doesn't make sense to store an > > outgoing dial result in the originating channel CDR > > A single CDR should not be able to cover several Dial attempts or even > multiple destinations within the same Dial attempts. If you think of > Dial as just another application and of CDRs being designed to reflect > the lifetime of a channel then things are simplified. If a Dial or any > other dial plan application causes three channels to be created then > that's 3 CDRs that will be generated. If the first Dial call fails and > another one is made with another 3 destinations than that's another 3 > CDRs that will be generated. > OK. > > What if, instead, we record the disposition of the dial in the created > > channel CDR? A channel comes into existence only once. For external > > incoming > > calls into the PBX, the disposition is pretty uninteresting, because > > we'd > > not create the channel if the disposition wasn't ANSWERED... (well, at > > least > > in the DAHDI world, maybe not so much in the voip world)... but, > > once asterisk dials B in A's behalf, we could record all the dialing > > action > > in the CDR for B; It's src/dest related fields could record the dial > > from > > A to B; the disposition would be FAIL/BUSY/NOANSWER/etc... > > That's not quite true. An incoming call to Asterisk could FAIL due to > some dialplan condition, it could go UNANSWERED if the dialplan > forwards the call to a destination that does not pick up, it could get > CANCELLED by the external party before Asterisk finishes processing > etc. > Aha! Hadn't thought on these lines... but that's true. Dahdi is fairly binary, but SIP has more possibilities. > >> > Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override > >> > an ANSWER on exten s, BTW... > >> > > >> > And, would it be proper to include all dial attempts? My guess is > >> > that you would *NOT* want to see any dial attempts in this mode. Well, > >> > at least, in this particular case, if A *tries* to dial B, but B > >> > doesn't answer, then since A is a live channel, we would record > >> > it's life in the system. When A hangs up, we would see the NO ANSWER > >> > disposition, and the destination of B, right? If A tried to dial a > >> > group, and nobody answered, the destination would be a random member > >> > of that group, the args to the Dial command would record the other > >> > members, usually. > > If A tried to dial a group that consisted of 10 members then that's 10 > CDRs that should be generated. For those people that don't want > unanswered CDRs they can be easily turned off with the configuration > option. For those of us that want a CDR for every call which includes > successful and unsuccessful call attempts we ge them. > OK. It's looking like we are the same wavelength. > > Let's say you do your examp, but we add exten dev SIP/w to the > > list for variety; > > suppose: > > > > W just plain doesn't ANSWER > > X is offline, so it's FAIL; > > Y gets answered; > > Z is busy > > > > If you have unanswered = yes, then you'd expect to see: > > > > 1. A to Asterisk which is answered (by the dialplan) > > 2. Asterisk to X which is FAIL > > 3. Asterisk to Y which is answered, >
Re: [asterisk-users] Simple CDRs
The continuing discussion on a future "Simple CDR" mode of generation... from which I will extract the info and add a section to the overall CDR spec I'm developing... For newcomers, "Simple CDR" mode would not break the conversations into legs at all. Each CDR would simply record the total time spent alive. It would start when the channel got created. It would end, and the CDR get posted, when the channel got hung up and destroyed. It might have been transferred, parked, put on hold a hundred times in the process, but this wouldn't matter. It's all in the CDR fields, now, really, as the conversation continues... On Wed, 2009-01-07 at 02:56 +, Grey Man wrote: > On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy wrote: > > As to Answers, we have to start getting pedantic; if A is an exten, > > then the first answer will be when B answers. But if A is an incoming > > call via, say a dahdi fxo interface, or an incoming sip invite, then > > an s exten is going to get run, and usually the PBX runs the answer() > > app, and this will usually be the first answer. Now, I can use heuristics > > to override this first answer if a dial occurs, but... if multiple dials > > occur, this heuristic would tend to record the last answer; if we > > override only Answer() in the 's' exten, then we would only record > > the first answer... is this more like it? > > That sounds a bit dangerous to me. If you go down the path of setting > the answer time based on dial plan applications or events you'll need > to understand and modify every dial plan application that can answer a > call. To me it would seem a lot simpler to do the > override/modification in each channel or even better even lower in > ast_channel. A channel has to have a very clearly defined definition > of answer and hangup whereas dial plan applications don't. > Hadn't thought along that line before: classifying the *kinds* of Answer. But we may not have to bother In this mode, a single CDR could cover several dial attempts and their corresponding "answers" incoming caller A could, during his lifetime in Asterisk, dial several users, say via assisted xfers, and have the targets hang up first, leaving his channel intact. It doesn't make sense to store an outgoing dial result in the originating channel CDR What if, instead, we record the disposition of the dial in the created channel CDR? A channel comes into existence only once. For external incoming calls into the PBX, the disposition is pretty uninteresting, because we'd not create the channel if the disposition wasn't ANSWERED... (well, at least in the DAHDI world, maybe not so much in the voip world)... but, once asterisk dials B in A's behalf, we could record all the dialing action in the CDR for B; It's src/dest related fields could record the dial from A to B; the disposition would be FAIL/BUSY/NOANSWER/etc... > > Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override > > an ANSWER on exten s, BTW... > > > > And, would it be proper to include all dial attempts? My guess is > > that you would *NOT* want to see any dial attempts in this mode. Well, > > at least, in this particular case, if A *tries* to dial B, but B > > doesn't answer, then since A is a live channel, we would record > > it's life in the system. When A hangs up, we would see the NO ANSWER > > disposition, and the destination of B, right? If A tried to dial a > > group, and nobody answered, the destination would be a random member > > of that group, the args to the Dial command would record the other > > members, usually. > > I liked you previous approach where all call attempts were recorded > and there was a config option to opt out of CDRs for non-answered > calls for people that didn't want them. When the Dial command > specifies multiple destinations then there should be one CDR for each > destination that is dialled irrespective of whether it is answered or > not. A disposition of something like CANCELLED could be set for the > dial legs that Asterisk cancels after the first one is answered. > > As an example consider the standard call scenario where a user calls > into Asterisk and the dialplan forwards the call to 3 destinations: > > User A --> Asterisk: Dial(SIP/x&SIP/y&SIP/z) --> SIP/y answers > > That should generate 4 CDRs: > > 1. A to Asterisk which is answered, > 2. Asterisk to X which is cancelled, > 3. Asterisk to Y which is answered, > 4. Asterisk ti Z which is cancelled. > I like the CANCELLED idea another disposition! OK, if you set the unanswered=yes, like I have it now, you'd see the CDR's with CANCELLED, otherwise, you would onl
Re: [asterisk-users] Simple CDRs
Greyman-- I'm taking this discussion to the list. Folks, what we are talking about here, is me trying to get a grasp around Greyman's (Aaron's) request for a bare-bones CDR generation that describes just total connect time for channels, stripping out all the details. Who cares about xfer, park, hold, etc.? So in the following is our discussion about what *should* be there, and in what form... So, what I'm thinking, is to spec out two CDR generation modes, one detailed one according to the spec I'm working on, and the other mode will follow these lines... On Tue, 2009-01-06 at 10:37 +, Grey Man wrote: > On Mon, Jan 5, 2009 at 6:42 PM, Steve Murphy wrote: > > I **think** I have a handle on it... Basically, for each channel > > that did anything, no matter what, you'd like a single CDR > > for that channel that would record the time from when it first > > activated to the time it hung up. I'd have to assume the > > first "answer" time would be recorded in the CDR, in case > > multiple "answer" times might apply (for incoming calls, it > > would be the time the pbx 'answered' the incoming call; > > for outgoing calls it would be the time the other end "answered" > > the call... right? > > Hi murf, > > To my mind only hangups should generate CDRs and nothing else should. > When you say "for each channel that did anything" I'd like a CDR I'm > not to sure about that, if you mean to generate a CDR for every type > of channel that is ever hungup then the answer is yes. If you mean to > generate a CDR on non-hangup channel events then the answer is no. OK > > > so, if A calls B, B parks A, A's park expires, B is rung, > > B answers, B xfers A to C, they hang up, we should have > > a CDR for A's time, with the start time being the time > > the PBX created the channel for A; the answer time would > > be (if A is an incoming call) when the PBX answered the > > incoming call and maybe started giving A the IVR experience, > > and (if A is an extension), when B answered the call. The > > end time would be when A was hung up. > > > > A CDR for B would be generated? with his answer time when > > he picked up the phone to answer the incoming call from A? > > and an end time when he parked A? > > > > Another CDR for B would be produced he answered the callback > > from the PBX for the expired session with A, and end when > > he got hung up xferring the call to C? > > > > Another CDR for C would be produced to record C's conversation > > with A, start when his phone started ringing, answer when he > > answered, and end when he hung up? > > > > Am I on the right track? > > I don't use Parking myself so my understanding may be slightly off but > from what I do understand of Parking the CDRs would not be generated > quite how you describe. The main point is that Parking a call should > not generate a CDR as the Park operation has not necessarily ended a > call. Parking a call will hang you up, in most normal cases. This includes calling the Park() app, bxfer to the parking exten, and using the one-touch parking features. But, if some strange combo of events allows someone to park without a hangup, then I'd agree, no CDR should be generated. > > In your description I think the CDRs should be: > > 1 The call from A to the PBX, start time when B answers, end time when > the A-C call is hungup, Can't do this; it would be inaccurate; start time is when A either picks up the phone (if dahdi exten), or when A submits an invite (if sip exten), or when an incoming call (via sip invite, or dahdi fxo i/f) arrives at the pbx. As to Answers, we have to start getting pedantic; if A is an exten, then the first answer will be when B answers. But if A is an incoming call via, say a dahdi fxo interface, or an incoming sip invite, then an s exten is going to get run, and usually the PBX runs the answer() app, and this will usually be the first answer. Now, I can use heuristics to override this first answer if a dial occurs, but... if multiple dials occur, this heuristic would tend to record the last answer; if we override only Answer() in the 's' exten, then we would only record the first answer... is this more like it? Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override an ANSWER on exten s, BTW... And, would it be proper to include all dial attempts? My guess is that you would *NOT* want to see any dial attempts in this mode. Well, at least, in this particular case, if A *tries* to dial B, but B doesn't answer, then since A is a live channel, we would record it's life in the system. When A hangs up, we would see
Re: [asterisk-users] CDR - What Changed?
On Mon, 2009-01-05 at 12:27 -0700, Robert Broyles wrote: > On 12/17/08 I updated to 1.4.22 from 1.4.21... > > Now the CDR data isn't recording calls where the caller hung up while > waiting on the Queue. > > Sample CDR data BEFORE the upgrade: > > "2008-10-30 12:46:47";"\"John\" > <0006741103>";"0006741103";"11621708182";"incoming";"SIP/carrier-3";"SIP/120-09232ae0";"Queue";"CSR1";"562";"518";"NO > > ANSWER";"3";;"1193773594.70627"; > > Now there's nothing in the CDR for these calls. > > I dug through the ChangeLog, but didn't see anything directly related to > this. Any ideas? > At first I thought it was the 'unanswered' option in the cdr.conf, but > it's set to 'yes.' > > Thanks in advance for the help. Robert-- Could this be the same as Mantis bug 13691? (http://bugs.digium.com/view.php?id=13691) I'm hoping to get some time and try to clear out a bunch of CDR bugs... murf -- Steve Murphy Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Troubles with AEL
On Wed, 2008-12-31 at 12:41 +0100, Benoit wrote:
> Hi,
>
> I'm migrating some macro from extension.conf format to AEL and they are
> some things
> i don't understand, and some i don't evan know how to get them working.
>
> Example:
> Doing this "queueMemberList=${QUEUE_MEMBER_LIST(queue)};" won't
> make any warning
> message, however the resulting variable value won't be the
> expected one (a string) but some kind of number
>
> However this work: Set(queueMemberList=${QUEUE_MEMBER_LIST(${queue})});
>Is there a reason ? i have the same comportement with CUT()
>
Benoit--
Set works because it is translated directly into the dialplan;
queueMemberList=${QUEUE_MEMBER_LIST(queue)};
is translated into queueMemberList=$[${QUEUE_MEMBER_LIST(queue)}]
(note the $[] added), which is probably not what you want in this
case, but would be fine if you wanted the RHS to be evaluated...
a = ${b} + ${c};
The voip-info wiki is a good resource here in explaining the
fine points: http://voip-info.org/wiki/view/Asterisk+AEL2
with some examples at
http://voip-info.org/wiki/view/AEL+Example+Snippets
murf
> Also, there is this construct which isn't working:
> if( ${DB_EXISTS(family/key)} ) {
> } else {
> }
>
> However i can't find a workaround in this case ... any idea ?
>
>
> ___
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
--
Steve Murphy
Digium, Inc. | Software Developer
57 Lane 17, Cody, WY 82414 USA
direct: +1 256-428-6002
mobile: +1 307-899-5535
fax/home: +1 307-754-5675
irc: codefreeze | jabber: m...@digium.com
Check us out at: www.digium.com & www.asterisk.org
smime.p7s
Description: S/MIME cryptographic signature
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AEL Variable Warning Messages
On Tue, 2008-12-23 at 12:14 -0600, Brent Davidson wrote:
> I have two offices sharing a phone system. They also share a common
> internal context because all of the employees of the second office also
> work for the first office. Each office has 4 outside lines and I have
> defined 2 channel groups in my zapata.conf. The second office needs all
> of their outgoing calls to go out over their lines so the people they
> call will have the correct callerID. I created an asterisk database and
> with entries in the database for all extensions in the second office and
> defined the following macro:
>
> globals {
> CONSOLE="Console/dsp";
> TRUNK="Zap/r1";
> TCTC_Operator=15;
> Law_Operator=12;
> };
>
> macro outside-dial ( num ) {
> if (${DB_EXISTS(Office/${CALLERID(num)})}) {
> TRUNK="Zap/r2";
> } else {
> TRUNK="Zap/r1";
> }
> Dial(${TRUNK}/${num},,Ttok);
> }
>
> It's working and correctly routing outside calls, but I get the
> following messages when I reload the extensions.ael file:
>
> [Dec 23 12:16:22] WARNING[2994]: pbx_ael.c:2500 check_pval_item:
> Warning: file /etc/asterisk/extensions.ael, line 93-93: expression
> "Zap/r2" has operators, but no variables. Interesting...
> [Dec 23 12:16:22] WARNING[2994]: pbx_ael.c:2500 check_pval_item:
> Warning: file /etc/asterisk/extensions.ael, line 95-95: expression
> "Zap/r1" has operators, but no variables. Interesting...
>
> Any idea what is causing the warnings?
Yes, I do! I was concerned that users were falling into a common
error, where they forget to wrap variable references in $(); so,
if it looks like an expr has arithmetic operators, but no variable
refs, then you get this message.
Yes, I *could* have made it more intelligent. File a bug, and I'll
see if I can do so. At the worst, you can ignore this warning, or
I can simply remove this overly-simple warning.
murf
>
> Thanks,
> Brent
--
Steve Murphy
Digium, Inc. | Software Developer
57 Lane 17, Cody, WY 82414 USA
direct: +1 256-428-6002
mobile: +1 307-899-5535
fax/home: +1 307-754-5675
irc: codefreeze | jabber: m...@digium.com
Check us out at: www.digium.com & www.asterisk.org
smime.p7s
Description: S/MIME cryptographic signature
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dailplan code for holiday detection?
On Tue, 2008-12-23 at 10:11 -0800, Dan Austin wrote:
> This has been on my ToDo list far too long.
>
> I have a small call-center setup, with basic
> time of day/day of week validation before putting
> callers in the queues.
>
> With the holidays upon us, I need to add check to
> see if 'today' is a holiday so I do not put callers
> in unmanned queues. Due to how the agents work, I have
> to allow joinwhenempty.
>
> Does anyone have a snippet of dialplan code, perhaps using
> Astdb, to check it 'today' is a listed holiday?
>
> Thanks,
> Dan
>
Here is a little script I use on my home system;
There are others on
http://voip-info.org/wiki/view/AEL+Example+Snippets
ifTime(*|*|20-25|dec)
{
Playback(greetings/christmas);
}
else ifTime(*|*|31|dec)
{
Playback(greetings/newyear);
}
else ifTime(*|*|1|jan)
{
Playback(greetings/newyear);
}
else ifTime(*|*|14|feb)
{
Playback(greetings/valentines);
}
else ifTime(*|*|17|mar)
{
Playback(greetings/stPat);
}
else ifTime(*|*|31|oct)
{
Playback(greetings/halloween);
}
else ifTime(*|mon|15-21|jan)
{
Playback(greetings/mlkDay);
}
else ifTime(*|thu|22-28|nov)
{
Playback(greetings/thanksgiving);
}
else ifTime(*|mon|25-31|may)
{
Playback(greetings/memorial);
}
else ifTime(*|mon|1-7|sep)
{
Playback(greetings/labor);
}
else ifTime(*|mon|15-21|feb)
{
Playback(greetings/president);
}
else ifTime(*|sun|8-14|may)
{
Playback(greetings/mothers);
}
else ifTime(*|sun|15-21|jun)
{
Playback(greetings/fathers);
}
else
{
Playback(greetings/hello); // None of the above? Just
a plain hello will do
}
murf
--
Steve Murphy
Digium, Inc. | Software Developer
57 Lane 17, Cody, WY 82414 USA
direct: +1 256-428-6002
mobile: +1 307-899-5535
fax/home: +1 307-754-5675
irc: codefreeze | jabber: m...@digium.com
Check us out at: www.digium.com & www.asterisk.org
smime.p7s
Description: S/MIME cryptographic signature
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] ael vs conf
On Thu, 2008-12-18 at 15:36 +0200, Tzafrir Cohen wrote: > On Thu, Dec 18, 2008 at 10:48:03AM -0200, David fire wrote: > > hi > > what i should use? ael or conf??? > > lua ? > > > thanks > > David > > Silly (and untested) tip of the day: > > Instead of using include, use templates: > > If you have: > > > [a] > exten => _12X > > [b] > include => a > exten => _1. > > > This won't work as planned, as [a] is included and checked after [b]. > So: > > [a] > exten => _12X > > [b](a) > exten => _1. > > Would result in [b] having: > exten => _12X > exten => _1. > > What's the ael equivalent? I guess, if you use the #include , you could save the exten => _12X in a file snippet and include it where you want it. I'll have to think about how AEL might support templates, tho. murf Steve Murphy Digium, Inc. | Software Developer 57 Lane 17 –Cody, WY 82414 – USA direct: +1 256-428-6002 mobile: +1 307-899-5535 fax/home: +1 307-754-5675 irc: codefreeze | jabber: m...@digium.com Check us out at: www.digium.com& www.asterisk.org smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Thu, 2008-12-11 at 11:37 +, Andrew Thomas wrote: > I've just spotted another interesting CDR 'feature'. Data calls don't > get flagged as such. In other words - if I make an ISDN modem call to > another ISDN modem via. the PSTN, the source and destination channels > are set correctly (as is everything else in the current CDR) but there > is no record if it being a data call. > > Can the 'new style' (whatever it turns out to be) differentiate between > data and voice calls (eg. B and D channel ones on ISDN)? > How do you picture this information appearing in a CDR? Via another field, or some indication in an existing field? murf > Just one more thing to keep Papa Murf busy over the holidays :). > > Cheers > Andy > > -->> -Original Message- > -->> From: [EMAIL PROTECTED] > [mailto:asterisk-users- > -->> [EMAIL PROTECTED] On Behalf Of Anthony Francis > -->> Sent: 10 December 2008 18:19 > -->> To: [EMAIL PROTECTED]; asterisk-users@lists.digium.com > -->> Subject: Re: [asterisk-users] CDR Design > -->> > -->> > -->> > -->> Steve Murphy wrote: > -->> > Just to be pedantic, how would src_cid be different from the > clid > -->> field > -->> > that cdr's have now? > -->> > > -->> > and the same with src_exten vs. src; > -->> > > -->> > A simple example might help to let this sink into my brain. > -->> > > -->> > murf > -->> > > -->> > > -->> The main thing is that the originating number shouldn't be linked > to > -->> the > -->> callerid. This way you can do things like allow no callerid while > -->> maintaining billing integrity. > -->> Here is the CDR columns for one one of my providers that exhibits > -->> this: > -->> > -->> > -->> > -->> > -->> > -->> *Field Number* > -->> > -->> > -->> > -->> *Field Name* > -->> > -->> > -->> > -->> *Description* > -->> > -->> > -->> > -->> *Type* > -->> > -->> > -->> > -->> *Length* > -->> > -->> > -->> > -->> *Example* > -->> > -->> > -->> > -->> > -->> > -->> 1 > -->> > -->> > -->> > -->> SwitchBatchNbr > -->> > -->> > -->> > -->> Sequential, positive integer assigned to each CDR file imported > into > -->> the > -->> system > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->> > -->> > -->> 5594 > -->> > -->> > -->> > -->> > -->> > -->> 2 > -->> > -->> > -->> > -->> RecNbr > -->> > -->> > -->> > -->> Sequential, positive integer assigned to each CDR within a CDR > file. > -->> Together with the SwitchBatchNbr, a unique combination. > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->> > -->> > -->> 2354 > -->> > -->> > -->> > -->> > -->> > -->> 3 > -->> > -->> > -->> > -->> SwitchNbr > -->> > -->> > -->> > -->> Unique number identifying the switch from which the CDR was > processed > -->> or > -->> assigned > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Integer > -->> > -->> > -->> > -->> 13 > -->> > -->> > -->> > -->> > -->> > -->> 4 > -->> > -->> > -->> > -->> CustNbr > -->> > -->> > -->> > -->> The unique, numeric number assigned to a customer > -->> > -->> > -->> > -->> Numeric > -->> > -->> > -->> > -->> Long Integer > -->> > -->>
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 16:32 +, Grey Man wrote: > Another thing to be aware of as the wish list for the Asterisk CDR > continues to grow is that right now Asterisk does not lend itself to > accurately creating the most fundamental requirement of a CDR which is > to accurately record at the very least the originator, destination, > time and duration for EVERY call Asterisk processes. We'll have to make sure the spec covers this info and where it goes, carefully. Then all I have to do is follow the spec. Simple. (murf rolls eyes) > It's already proven to be a very hard requirement to meet for Asterisk > given the original CDR design and implementation and to my mind there > is no point trying to add more sohisticated behaviour - call flows, > events, linked ids etc. - until it has been. The more convoluted any > new design gets the less chance it has of ever getting implemented in > the near future. Getting a basic accurate CDR system in place does not > preclude future enhancements but without it they'll just add another > few layers to the house of cards. > > Regards, > > Greyman. > -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 15:46 +0200, Apostolos Pantsiopoulos wrote: ... > In the first situation you need a real time system, but in the second > situation > you don't. > > Being a programmer that dealt with both situations I can say that we > need both approaches in asterisk :). In fact the LEGO paradigm > would be the ideal solution. I think that asterisk should cope > with both situations instead of just choosing one. > I think we all agree on that. I agree, too. Only trouble is, there's only so many hours in a day! murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 13:41 +, Andrew Thomas wrote: > "Pardon me," > > Granted ;). > > "I have created realtime stats package that's based on CDR, you see new > info immediately after call leg/event is over" > > I see what you are saying but can you show hold-times etc? For example, > call comes in to A, A puts call on hold, A dials B, B answers A, A > transfers call to B, B speaks to caller. Basic PBX functionality - but > how long did it take B to answer A? What if B is an external number > (trunk to trunk)? > > To illustrate - dial an external number and, while on that call, check > your CDR's - there isn't any. Now put that call on hold, still none, > now call another internal extension - still none. Now hang up and > transfer the call. Now there is one CDR for your call. That isn't > real-time - that's historic (ie. it happens AFTER the call is finished). > > The CDR that's produced here will show your call to the outside world - > and its duration etc. So far, so good (for historic reporting). Now get > the person you transferred the call to to hang up. Another CDR record > - but this show as you talking to the internal extension - not the > external extension talking to the outside world. > > Therefore, if the 2nd extension stays on that call for a long time - > who's picking up the bill? > > Current CDR's are lacking in this respect - and I think this is what > murf is trying to sort out (please jump in here murf). > > murf jumps: Read the emerging spec: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=log click on (view) in the first numbered Revision. Or, fetch it to your machine via svn checkout: http://svn.digium.com/svn/asterisk/team/murf/RFCs And publish your scathing comments, loathing, compliments, whatever, and we can hammer out the spec. murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 15:32 +0200, Apostolos Pantsiopoulos wrote: > But the new CDRs that we are discussing would have to deal > with transfers correctly. I think that's where the whole thing started. > > I am not happy with the current CDRs system either. I find it obsolete. > That is why I am not using it for billing purposes. But a NEW one that > meets certain criteria would be ideal for billing. > Well, read my draft RFC, and see if I'm on the right track. Tune into CDR Design in the subject line in this email list, and let's toss this around and see if consensus is possible. svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and an occasional "svn update" in the RFCs dir will keep you up to date. Or you can just read it via your browser at: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=log and choose the (view) of the first numbered revision in the list to see the latest version. murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 14:47 +0200, Atis Lezdins wrote: > On Fri, Dec 5, 2008 at 2:35 PM, Andrew Thomas <[EMAIL PROTECTED]> wrote: > > "I'd disagree. In some cases a event based system would be the best > > solution, but in systems with high call volumes, scanning through events > > > > looking for the proper billing information and parsing them would be a > > hard job compared to CDRs." > > > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > > Events. Your 3rd party app could then do anything it wanted to with > > them. > > > > Events are real time - not historic (like CDR's). Events are presented > > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > > call has finished so you miss things like hold-times etc. > > > > Remember, I am not saying that everyone should stop using the CDR's if > > they feel comfortable with them - but I, for one, don't trust them for > > building a stable billing platform or a real time stats package (which > > more and more customers seem to want these days). > > Pardon me, > > I have created realtime stats package that's based on CDR, you see new > info immediately after call leg/event is over > > http://ftp.iq-labs.net/screenshots/cdr_view.jpg > > > If you start to change the CDR's to account for extra bits (using a > > unique ID) then your 'scanning' actually increases as you will need to > > tie up all the unique ID's to get one full call progress path. > > This is exactly how real-time billing works. If you somebody wants it, > they put in custom ResetCDR(w) in their dialplan and have all kinds of > events logged. Having Asterisk write all the timestamps/durations into > database is just much simpler. > > > Please note, I am not trying to cause flame wars here - just stating > > that I'd love an event based stream, that I can parse any way I see fit. > > I know there's the AMI - but that is a 2-way, give-you-everything > > solution. All I want is to know when a handset and/or trunk does > > something (I don't care about SIP registrations etc). > > > > I guess we'll just have to wait and see what santa murf gives us all for > > Christmas :). > > > > I really want to contribute this discussion (and RFC), i'm reading it > and i have lot of to say, but it's hard to find time for reading RFC > (i'm in middle yet). So, i hope this will go on and allow me to > respond with some objective comments. Atis-- I welcome your input. I don't want to write junk. And to make this useful to as many users as possible, I need to know what they need/want. I can't possibly make everyone happy, but I might get away with giving them something that makes getting to their desination possible. There's many ways to get a job done. I'm looking for the simplest and the most complete/general. murf > > Regards, > Atis > > -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 12:35 +, Andrew Thomas wrote: > "I'd disagree. In some cases a event based system would be the best > solution, but in systems with high call volumes, scanning through events > > looking for the proper billing information and parsing them would be a > hard job compared to CDRs." > > That's just it - you wouldn't be 'scanning' any CDR's - you'd be given > Events. Your 3rd party app could then do anything it wanted to with > them. > > Events are real time - not historic (like CDR's). Events are presented > as they happen (hold, ring, etc) - CDR's are usually presented AFTER the > call has finished so you miss things like hold-times etc. > > Remember, I am not saying that everyone should stop using the CDR's if > they feel comfortable with them - but I, for one, don't trust them for > building a stable billing platform or a real time stats package (which > more and more customers seem to want these days). > > If you start to change the CDR's to account for extra bits (using a > unique ID) then your 'scanning' actually increases as you will need to > tie up all the unique ID's to get one full call progress path. > > Please note, I am not trying to cause flame wars here - just stating > that I'd love an event based stream, that I can parse any way I see fit. > I know there's the AMI - but that is a 2-way, give-you-everything > solution. All I want is to know when a handset and/or trunk does > something (I don't care about SIP registrations etc). > > I guess we'll just have to wait and see what santa murf gives us all for > Christmas :). > LOL, santa murf here, just making note that a generic CDR generator, maybe with a few different flavors, generating CDR's 'realtime' or done on event logs once a month standalone, isn't going to be a walk in the park. Sure, there's going to be some simple bits to it, but as in every system with a fair number of event types, exceptions to rules, etc., it's going to involve some serious thinking, blood, sweat and tears. The code will encapsulate some hard-earned experience, minus some false assumptions that had to be corrected. Now, it might end up being a walk in the park, and maybe I'm just being pessimistic, but personally, as a programmer, a CDR spec is going to be easier to bill from than a sequence of interlaced events. murf > > > _______ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, 2008-12-05 at 10:52 +, Andrew Thomas wrote: > Thanks for this Greyman - it's all beginning to make sense now ;). > > I agree that the 'loss of CDR upon txfr' is a nasty bug which does need > to be addressed before anything else (assuming it hasn't been already). > > But, wouldn't it be better if you could ignore the CDR's completely and > use an event based system? This would give you ALL the information you > need. All that remains is to filter out the un-required bits. > > Like I said earlier - the CDR's aren't reliable enough for a billing > platform (as you've rightly pointed out) but are OK for very basic call > logging (something the customer can look at). > > Hopefully, the murf'ster will chirp in here :). > I'll Chirp here. I'm kinda impressed with the number of CDR Design messages in the Q since last I checked, but I'll try to plow my way thru them. I've been ruminating over Greyman's suggestion about simplified CDR's for the past few days, stepped outside my 'box', and I think realized what he actually was asking for, at last. As to the event system, say no more. CEL is it. It will spew out all possible CDR related events in any of several formats, in somewhat real-time (as they occur) order. The state of the channels are included with the time of each event. But, this alone isn't really useful in a database. Try coming up with SQL queries that tell you useful things about what's happened, or happening... CDR format is useful that way; and, like Brian, yes, you can mix the two to your heart's content, even add manager events to the mix. murf > Cheers > Andy > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man > Sent: 05 December 2008 09:37 > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] CDR Design > > On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas <[EMAIL PROTECTED]> > wrote: > > > > In summary: Leave CDR exactly as it is and create a new CEL (Call > Event > > Logging) module (optional in modules.conf) that puts out (and does not > > accept) call event information (ie. a one-way fire-and-forget output > > from Asterisk). > > > > Hi Andrew and Others, > > This thread is actually part of a discussion that has been going on > for over a year. The links below provide the background to the whole > thing. > > http://www.asterisk.org/node/48358 > http://bugs.digium.com/view.php?id=11849 > http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm > l > > Up until recently the approach was to try and fix the specific bugs > with transfer CDRs as a typical bug. There is now a realisation that > that is a lot trickier than inially thought so it's been decided to > try and come up with a good design for the Asterisk CDR sub-system. > > Regards, > > Greyman. > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
> > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users > > > > ___ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users > > > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Wed, 2008-12-03 at 08:11 +, Andrew Thomas wrote: > It seems to me that we are confusing billing and logging here. Call > billing only really needs the start and finish (like we get now) - but > proper call logging requires all steps. > > Do we leave CDR's as they are (for billing purposes) and have a separate > 'event' driven log for call logging? Or do we change the CDR structure > to accommodate logging as well? > > Personally, a separate 'event' log seems preferable to me as this keeps > existing billing platforms useable. It just means the logging programs > will need to be re-written to look at a new database for events. > > I know we have the AMI - but that puts out a lot more information than > is needed for simple logging (and requires something to prune and store > the events in a database of some sort). > That's the classic tradeoff... too much vs. too little detail. If you want 3 tons of detail, use Manager. If you want just 1 ton of detail, use CEL If you want a half-ton of detail, with time diffs built in, use CDR. There are some other differentiating factors... like the fact that CDRs do provide some grouping of events natural to billing. At any rate, NONE of them can be directly used for a billing app (if any currently can, you may have a problem!) --and I've seen folks use hybrid mixtures of the above to put together "The Perfect Billing System". murf > Any thoughts? > > Andrew Thomas > Technical Services Manager > DataVox Ltd > Saddleworth Business Centre > Huddersfield Road > Delph, Oldham > OL3 5DF > -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Mon, 2008-12-01 at 10:55 -0600, JD wrote: > Steve Murphy wrote: > > [...] > > I love it! You will have it done later today, correct? (joke.) > > Just a non-technical/social suggestion: don't call this CDR. Call it > "Enhanced CEL" or something like that. > > Why?: because otherwise you will forever get arguments about it. > Traditionally, a CDR is one line per call; all inclusive. And as you > know, that is a horrible standard for todays complex systems; but it is > what it is. > > So, perhaps Asterisk should not build native CDR at all. It should build > your "Enhanced CEL". A separate perl/ruby/etc script could be included > in the Asterisk distribution that build the "CDRs" after the fact. Or > multiple CDR scripts based on the flavor-of-the-day of what CDR means. > > Just my thoughts. I very much look forward to your code. This will make > my life so much easier. > > John John-- Point well taken, but if I call it anything but CDR, people will go "Huh?". CEL is per-event, but CDR's are event-groups. I think we are safe to keep calling it CDR, because I perceive that at least some of the big-name pbx vendors are generating much more than simple line-per-call records and they still call them CDR's. Using a db to make sense of CEL events for billing purposes is extraordinarily difficult, as the strings of events are reported as they occur, and with multiple calls going on simultaneously, the events are interlaced. You can pull out single threads by sorting on the linkedid; but still you have strings of events among multiple channels that will not be obviously easy to decode, especially by concocting SQL queries. Thus, the need to provide some sense via CDR's. And, yes, I agree with you. I will try to make it so a CEL->CDR generator could be run either 'real time' inside asterisk (via make menuselect choice), (and using your selection of existing backends), AND, I can try to provide a stand-alone option that could be run on CEL events that were logged to one of the CEL backends; probably just one of the plain-text ones. murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Desgin
On Wed, 2008-11-26 at 01:13 +0100, Freddi Hansen wrote: > > > > To me the obvious answer is to provide a CDR for every call leg so for > > > A calling B via Asterisk there would be two CDRs produced. It's far > > > far easier to disregard the unwanted CDRs than it is to try and > > > generate the missing ones and in some cases it's virtually impossible. > > > If it's weighed up I think people would vote to have accurate CDRs > > > ahead of anything else and if single legs are the best way to do that > > > then it's the way it should be done. > > > > > > In addition with single leg CDRs it will solve the dilemna about > > > acommodating every possible call scenario that I know has caused you a > > > lot of consternation over the last 18 months. > > > > > > Sure it's a change from the current situation so maybe needs to use > > > the standard apporach of a configuration setting to opt in initially > > > before becoming the default in the subsequent major release. > > > > > > > > OK, Greyman, your logic is solid. If we provide a CDR implementation > > that just generates the individual call legs, and ties them together via > > the linkedid > > (see team/group/newcdr), then both camps should be able to derive the > > info > > they need for billing, via hopefully not-overly-complex SQL queries to a > > backend db. > > > > I'll modify my RFC to reflect this line of thinking. Yes, it is a bit of > > shift. > > And, yes, the implementation will make this new approach optional, and > > not > > default. But, pardon if I make it available via the CEL domain come > > implementation time. > > > > > > It should take me a week to rehash my document; perhaps longer (I'm in > > bugfix mode, and this borderline development work); in the meantime, > > those with decided CDR needs might make their wishes known, if they do > > not think this approach will work. Speak now, or forever hold your > > peace; or forever complain... or whatever. > > If this is particularly distressing to you, perhaps your fears might be > > slightly assuaged when you read the details... > > > I was part of a team that did design a multiservice billing system about > 15 years ago and the solution people seems to agree on here (and me to) > looks pretty much the same i.e one call may consist of several calls > legs. In addition to the linkedid it would be nice to have an indication > in the cdr that tells us that 'this is the lastone on this linked id'. > Our experience was that we shouldn't for load reasons work with cdr's > in the immidiate multileg format in the DB. So we did collect cdr's in a > tmp DB until we got the the record with end marker set. We would then > produce our final cdr for the actual service, store it in billing col. > and delete it from the multileg col. When a new service is created we > only have to make a the new customized cdr, we don't have to touch the > generation of the multileg format. > > Freddi Freddi-- Very interesting. Brian Degenhardt had some code we just gave some thought to, wherein we determine if the last channel involved in a linkedID set has been closed. If so, then the entire set is finished. We can use this facility to get you a closing attribute, that could be added to the last CDR emmitted for that set; OR, we could just emit another CDR with type CLOSE or FINAL or something, that signals the end of the chain. murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Tue, 2008-11-25 at 08:06 +, Grey Man wrote: > >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> wrote: > > For the moment, let's not worry about the implementation. Let's > > get consensus on the spec first. In the scenario, where A calls B, > > B xfers A to C, C xfers A to D, or some such similar scenario, > > half the world wants a single CDR for A, from the time it started, > > to the time it hung up with D. The other half wants A->B's dial and > > bridge, > > a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some > > CDRs > > to describe the xfers, where B xfers A to C and C xfers A to D. > > > > My document is pointing in the former direction, and either we need to > > spec both, or pick one. > > To me the obvious answer is to provide a CDR for every call leg so for > A calling B via Asterisk there would be two CDRs produced. It's far > far easier to disregard the unwanted CDRs than it is to try and > generate the missing ones and in some cases it's virtually impossible. > If it's weighed up I think people would vote to have accurate CDRs > ahead of anything else and if single legs are the best way to do that > then it's the way it should be done. > > In addition with single leg CDRs it will solve the dilemna about > acommodating every possible call scenario that I know has caused you a > lot of consternation over the last 18 months. > > Sure it's a change from the current situation so maybe needs to use > the standard apporach of a configuration setting to opt in initially > before becoming the default in the subsequent major release. > > Regards, > > Greyman. > > P.S. Sorry about the duplicate post. I actually sent the email to the > list 4 times with around 8 hour spacings and I'm not sure why there > was a problem getting it through. Everyone-- I've just made some major changes to the CDRfix2.rfc.txt file in http://svn.digium.com/svn/asterisk/team/murf/RFCs to accommodate the Leg approach instead of a channel-based approach. Greyman is correct. By cutting the timeline into legs, we avoid all the nasty channel state problems, or so it appears thus far. I threw out all the text about channel/peer state, fleshed in all the example cases, etc. I added a section describing the linkedID field. I provide a list of CDR record types at the end, that will eventually be expanded to describe each field that set in that type, and what they mean. The types so far are: 3WAY AXFER AXFER1 AXFER2 BARGE BXFER CALL CONF HOLD PARK RECALL RECONN USER WHISPER murf -- Steve Murphy Software Developer Digium smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
