[asterisk-users] Grandstream HT 503 Outoing 403 Forbidden
I am trying to get Asterisk 1.6.2.5 working with a Grandstream HT-503 ATA. The FXO part is giving me fits. Every call I try to make to the FXO port outbound I get 403 Forbidden coming back. I've been through every configuration setting I can see, and Uncle Google is not helping me much. I updated the firmware to the current version, and that didn't help. If anyone has this working, I would like to know the secret sauce. -Thanks, Jim -- _ -- 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] SIP Registration Failure Logging
Let's say I have two Asterisk boxes, A and B. I am trying to get A to do SIP registration on B, so an extension for A can dial SIP phones covered by B. If I examine the logs on B, if the registration succeeds, I am seeing a notice to that effect on B. But if the registration *fails*, i'm not seeing any message logged on B. Maybe I'm just not looking in the right place. Is there a way to turn on logging or debugging so registration failures are logged on the target? I'm doing something profoundly stupid, and seeing the notorious chan_sip.c:12009 handle_response_invite: Failed to authenticate on INVITE message, and trying to trace why. -Thanks, Jim -- _ -- 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] Security Vulnerability in Asterisk
--On Monday, June 28, 2004 7:21 PM +0200 Michael Sandee [EMAIL PROTECTED] wrote: Other than that... if these problems are not being published when fixed... then other distro's do not have a chance to fix it... (think about distro's that use stable code, but haven't updated to 0.9 because of problems) I have to say -- with somewhat less vehemence -- that I'm another user who sure never noticed that the stable release of Asterisk had moved from 0.7.2 to 0.9x. This should have been an important announcement on *SEVERAL* security grounds. As of 0.7.2, the recommend version of channel H323 had some very serious vulnerabilities that the OpenH323 folks had fixed months previously. This is an opportune time to repeat: H.323 uses ASN.1. ASN.1 is fiendishly complex and is a known bad boy in which many security holes have appeared over the years. It would be naive to think there won't be more. As VOIP hits the big-time and Asterisk joins the ranks of some of the other more famous open-source projects, quick response to security vulnerabilities will be expected. It's nice to know in the case of these format string problems that they were in some sense addressed promptly, but we're not all subscribed to the dev list. A vulnerability that is fixed in CVS head but not back-patched to stable *is not fixed* as far as a large percentage of the user base is concerned. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Security Vulnerability in Asterisk
--On Monday, June 28, 2004 9:16 PM -0400 James Golovich [EMAIL PROTECTED] wrote: It was fixed in CVS head and stable and at the same time 0.9.0 was released. The existance was noted in the ChangeLog as well that comes with asterisk Good. But the OpenH323 patches were not back-patched for *months*. I'm not sure if there was an announcement posted to the lists about the code release, but it was definitely updated on the asterisk.org page and the wiki Hmm, I see I wasn't subscribed to announce. Shame on me. Well, hopefully in the future new versions of stable can be announced. I'd like to put forward as a good example what the PostgreSQL folks do. They post a kind of weekly progress report. It includes a digest of important patches, and new releases are announced all over the place. The Sunday Asterisk News posts seem to be filling that role here, and are a good thing, which I applaud. A new release of stable should be something to brag about, yes? ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] dtmfmode=inband with G.729
It appears Asterisk can handle DTMF inband on only a limited selection of formats, of which G.729 is not one. The issue appears to be something involving short data -- whatever that is. (I'm inferring all this from looking at dsp.c in the vicinity of the error message I was getting, which pointed to line 1424.) What *is* short data? Is this really a show-stopper for the G.729 format, or is it just a case that nobody coded this? I know that RFC 2833 is really a better way to go (this is for h323, so there is no option dtmfmode=info ...) but I'm not getting that to work. (I need to change firmware on my Cisco routers to get them to grok rfc2833.) -T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] dtmfmode=inband with G.729
On Fri, Apr 02, 2004 at 08:52:09AM -0600, Eric Wieling wrote: It's not asterisk, its the codecs. Codecs other than ulaw and alaw will distort continuous tones like DTMF. Welll ... At work we experience this with Cisco dial-peers over G.729: DTMF is erratic. But it's *NOT* inoperable. The way Asterisk does this, it doesn't even *try* to send the data through. I'd sure like that option, even if it might not register at the other end. My Cisco-dial-peer-only connection users tell me that they often have to try a second time, but DTMF does usually work for them eventually. Might not resgister does beat Refuse to try ... If you have an actual IVR application where errors matter, then of course you might decide you wouldn't want the risk of distored DTMF, but for simple things like picking an extension on a PBX where the consequence of an error is just a wrong number, why not give it a go? Anyone who chooses dtmfmode=inband is knowingly choosing an option that is inherently error-prone. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] G.729 and h323.conf
What should my allow= line look like in h323.conf for G.729? I've tried allow=G729A but this doesn't seem to be right. These codec indentifiers sure are mysterious. Take g711alaw. To allow it you seem to have to use allow=ALAW. Even though ALAW does not show anywhere as an identifier when you say show codecs. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Asterisk Security Audit?
Has Asterisk ever been audited for common security holes, such as buffer overruns? A quick grep through the source for routines that should never be used, like strcpy, strcat, etc., reveals a lot of it. I fear I fear. Has anyone flung pathology at IAX2 to see if it stands up to malformed packets? (This is always an issue when you have a protocol that only a small number of programs use ...) I hope I'm wrong, but I have a very queasy feeling ... [We already know that H.323 is not being looked after, security-wise ...] ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] H.323 ASN.1 Vulnerabilities: Request for official patch!
To recap: 1. Security vulnerabilities have been found in the ASN.1 parsing of *many* H.323 implementations. Some security experts consider them quite serious, others don't. 2. OpenH323 *was* vulnerable when the announcement was made. (About a month and a half ago, or so.) 3. The OpenH323 folks patched their code quite quickly. I belive that to obtain their fix you need to check code out of CVS. 4. If you visit asterisk.org, follow the usual download instructions, and build in H.323 support, your resulting Asterisk *WILL* be vulnerable. 5. Integrating a fixed version of OpenH323 with Asterisk is not straightforward. (I at least have not been able to get this to work.) 6. There is (in my opinion) *widespread misunderstanding* on this issue. E.g., I had Digium support try to convince me that Asterisk was not vulnerable. I would like to make a public appeal to whoever is in position to do this to issue an official patch -- and to update the asterisk.org website so newbies get a fixed version when they download and build in H.323 support. Please please please ... -T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VMware, * and SJphone ... newbie
I've read and tried a LOT of sample config's for sip.conf and extensions.conf and no matter what I do I get registration error's when trying to get SJphone registered to my * server. I have a XP VMware host with Redhat 9 / * as a guest. The SJphone is on the host XP trying to register with the guest Redhat/* server. Any suggestions? I think I'm just missing something stupid. I'm used to the idea of using VMWare so that the adult operating system is the host, and the toxic delinquent is the guest, rather than vice versa, as you have it, so this may not pertain. Check routing!!! Do you have network connectivity between the host and guest *generally*? How do you have your networking set up? When Linux is the host, guests can be set up in a variety of configurations -- NAT, bridge, etc. With Linux as the host, routed can be somewhat cranky at routing from your host LAN to NATted VMs. Can you ping your host from the guest? This may not be an Asterisk issue at all. It might be a networking issue. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] H.323 ASN.1 Vulnerabilities: Request for official patch!
See the existing discussion on this Ditto. IT DOES NOT WORK. Compiles, but no calls go through. I asked you to post your exact versions of all components, but I don't believe you did this. I have not been able to get it to work with Asterisk 0.7.2. Just because *YOU* got it to work on your particular system does not mean the problem is solved. If there is a way to get it to work reliably: 1. Please post complete details 2. Someone update asterisk.org with correct information. I believe it is correct that there is no official response on this from Asterisk to what many people consider a critcal security issue. Read the archives is nice, but really, the default Asterisk should be fixed. And the fix needs to be tested on a variety of systems, too. I tried your exact version of pwlib, and have not been able to get a *SINGLE* call to work. See the existing discussion on this Ahem. I posted pretty thorough details on what wasn't working ... Please respond so that the discussion can -- uh -- exist ... -T.i.A., Jim [Apologies for bandwidth-wasting inclusion below -- I'm reposting since someone thinks this discussion has been settled ...] On Thu, Feb 26, 2004 at 09:18:45AM +0800, [EMAIL PROTECTED] wrote: In the Makefile inside asterisk/channels/h323 directory, there's a line like this: CFLAGS += -I$(PWLIBDIR)/include/ptlib/unix -I$(PWLIBDIR)/include try to use -I$(PWLIBDIR)/include ONLY, it should work. I've compiled it with pwlib 1_6_2, which works fine leo Sigh. I am having a very rough time here. Could you please post exactly which versions of Asterisk and OpenH323 you used? When I use your advice above I get a successful build, but I haven't got a single call to actually *work* through H.323. Here are my results (all trials are Asterisk 0.7.2): OpenH323 1.13.0 / Pwlib 1.6.0: Asterisk segfaults when it gets an H.323 call. OpenH323 1.13.2 / Pwlib 1.6.3: Channel won't load, there's an unresolved symbol. OpenH323 1.13.2 / Pwlib 1.6.2: Asterisk appears to be fully stable. As far as Asterisk is concerned, everything works: calls are made, answered, bridged, all looks fine from the console. But nothing is actually making it *back* through H.323 from the Asterisk end. When I call Asterisk through H.323, Asterisk thinks things are fine, but from the calling end it thinks no one answered. When I call from the Asterisk end, I never hear anything that sounds like an answer. Now this looks *VERY* familiar. It sure is like the H.323 problems I had right at first until I caught on to using *only* G.711 A-law. Once I started making sure everyone was on ALAW, H.323 starting working fine (except for DTMF, but that's a subject for a new thread ...) ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] GotoIf voicemail message is too long??
If someone leaves a voicemail message and gets booted out of voicemail because the message is too long, I would like different behavior than if the # key is pressed. Anyone have a snippet of extensions.conf that shows how to do this? How do I do a generic gotoif based on the result code of an application? Related questions: What is the magic place to find where in the documentation the WHAT!? the condition syntax is documented? Is there a URL for this? What is the magic place to find all there is to know about magic extension offsets (e.g. +101 if yatta yatta, +50 if yatta yatta, etc.) T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PCphoneline FXO to FXS box??
pcphoneline.com sells a little box with two RJ-11 jacks that is supposed to convert an FXS port into an FXO port. According to their blurb, when a call comes in it basically conferences the two lines together. Is anyone out there using this box with Asterisk? Any problems? What happens to callerid when you get an incoming call? I'm thinking about using one of these things with the Grandstream ATA-286 for a spot where I may not have a PC available to put a Digium FXO card into. (Don't have Ethernet where the PSTN jack is, so the easiest thing to do is WiFi it. Seems a shame to dedicate a whole PC to just a single FXO port ...) -T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Patching Asterisk for OpenH323 ASN.1 Vulnera bilities
On Thu, Feb 26, 2004 at 09:18:45AM +0800, [EMAIL PROTECTED] wrote: In the Makefile inside asterisk/channels/h323 directory, there's a line like this: CFLAGS += -I$(PWLIBDIR)/include/ptlib/unix -I$(PWLIBDIR)/include try to use -I$(PWLIBDIR)/include ONLY, it should work. I've compiled it with pwlib 1_6_2, which works fine leo Sigh. I am having a very rough time here. Could you please post exactly which versions of Asterisk and OpenH323 you used? When I use your advice above I get a successful build, but I haven't got a single call to actually *work* through H.323. Here are my results (all trials are Asterisk 0.7.2): OpenH323 1.13.0 / Pwlib 1.6.0: Asterisk segfaults when it gets an H.323 call. OpenH323 1.13.2 / Pwlib 1.6.3: Channel won't load, there's an unresolved symbol. OpenH323 1.13.2 / Pwlib 1.6.2: Asterisk appears to be fully stable. As far as Asterisk is concerned, everything works: calls are made, answered, bridged, all looks fine from the console. But nothing is actually making it *back* through H.323 from the Asterisk end. When I call Asterisk through H.323, Asterisk thinks things are fine, but from the calling end it thinks no one answered. When I call from the Asterisk end, I never hear anything that sounds like an answer. Now this looks *VERY* familiar. It sure is like the H.323 problems I had right at first until I caught on to using *only* G.711 A-law. Once I started making sure everyone was on ALAW, H.323 starting working fine (except for DTMF, but that's a subject for a new thread ...) * * * This particular siege has been really frustraing. I hate to seem like I'm whining, but really there should be an official patch here, and asterisk.org should point people properly so that new downloaders who need to build H.323 support will get the patched version. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Grandstream transfer into outer space
On Wed, Feb 25, 2004 at 05:14:35PM -0500, I wrote: So: now I've got my caller just sitting there, transferred into nowhere. Is there a way to pick the caller up? I haven't found a way to do this. Sorry to be a nag, but no one answered the original question. Is there a way to pick up a stranded call??? If Asterisk doesn't do this, what about the idea of creating a new channel for this purpose? It seems to me it should be feasible, but I haven't spent any time with the code, so am just speculating off the top of my head. It could work kind of like picking up a parked call: you'd have a .conf where you specifiy e.g. an extension that will pick up the first stranded call. It seems to me this issue is pretty important. If you're thinking of Asterisk competing against a commerical PBX, having a situation where a call can get stranded with no way to pick it up is a significant flaw. I've seen PBXs that could be set up so that any call not picked up after some length of time magically rang back to the operator. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Grandstream transfer into outer space
On Thu, Feb 26, 2004 at 03:49:11PM -0600, James Sizemore wrote: You could always create a rule to match any-e-thing 3 or 4 digits, that always forwards to the receptionist This has the same problem as a catch rule -- suggested in other posts -- for the invalid extension. I don't want to catch *ALL* transfers. Likewise, if extension 450 dials 451 but hits 481 by mistake -- just an extension to exenstion call -- then I surely don't want to send *THAT* to the operator. All these things would work fine *IF* I could somehow separate transferring into *its own context*. But, it isn't clear you can do that. Actually, I don't even need to catch transfers managed by Asterisk -- just the blind transfers done by the Grandstream itself. I'm still completely newbieville to how SIP works, but it looks to me as though I'm asking for Asterisk to be able to do something different when it gets an INVITE from a phone that *already has a channel open*. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Patching Asterisk for OpenH323 ASN.1 Vulnerabilities
I need to know how to get Asterisk patched for the recent vulnerabilities in various H.323 implementations due to integer overlows in ASN.1 parsing. I'm quite new to this world of Asterisk, H.323, SIP, and VoIP, so please bear with me if I garble something. The consensus in the Asterisk community seems to be that (somehow) Asterisk is not vulnerable to these security holes, which many experts consider quite serious. I am frankly having a lot of trouble understanding where this bliss is coming from. From my reading on this, it looks to me as though the developers of OpenH323 have acknowledged that their code ***IS*** vulnerable, and have published a patch. Please see http://www.openh323.org/pipermail/openh323/2004-January/065237.html This suggests that to have fixed H.323 code, one needs the following code versions: Version CVS tag PWLib 1.6.0 v1_6_0 OpenH3231.13.0v1_13_0 In particular, the recommended versions of PWLib and OpenH323 that you will get from following the default instructions for building Asterisk will ***NOT*** be patched. I tried downloading the above versions, and Asterisk does not build with these versions. Is there a version of Asterisk I need to check out of CVS to get patched versions of H.323 to build? How does one incorporate these fixes into Asterisk??? ASN.1 is a swamp. There have been many holes of this kind, and I fear there will be many more in the future. The Asterisk community has to be prepared to react quickly when a patch is released from OpenH323. -T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Grandstream transfer into outer space
The Grandstream BudgeTone 101 phone has a Transfer button. This appears to be a blind transfer: once you've dialed the extension to which you want to transfer, the phone tries to do this and then dumps you out. My question is this: Let's say I explain to my users that I don't want them using the Transfer button, to use # and let Asterisk transfer the call, or to use parking, and again let Asterisk handle it. But, someone forgets. They hit the Transfer button anyway. Then they type the wrong extension. If they had transferred using the # key and let Asterisk do it, Asterisk would have reacted reasonably to a wrong extension, but the Grandstream doesn't know about all this magic. So: now I've got my caller just sitting there, transferred into nowhere. Is there a way to pick the caller up? I haven't found a way to do this. When this happens the caller is still connected to something, and at the Asterisk console, sip show channels shows the call. It seems as though there ought to be some way to reach in and connect to it ... Any ideas welcome. These Grandstream phones are kind of nice. I sure don't want to have to start out a new installation by *taping over* the Transfer button, but if there isn't a way to reach a stranded caller, it's deadly. -T.i.A., Jim ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Patching Asterisk for OpenH323 ASN.1 Vulnerabilities
On Thu, Feb 26, 2004 at 09:13:20AM +1100, Adam Hart wrote:
Yes, asterisk is vulnerable if you have H.323 running.
What happens when you try and compile asterisk with the latest version of
OpenH323, it's been a few months since i've done it but it used to work.
A flood of errors. Starting off like this:
In file included from /local/dist/asterisk/pwlib_1.6.0/include/ptlib.h:169,
from ast_h323.h:30,
from ast_h323.cpp:29:
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/unix/ptlib/pdirect.h:78: syntax
error before `protected'
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/unix/ptlib/pdirect.h:80: syntax
error before `*' token
In file included from /local/dist/asterisk/pwlib_1.6.0/include/ptlib.h:181,
from ast_h323.h:30,
from ast_h323.cpp:29:
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/unix/ptlib/config.h:53: syntax
error before `public'
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/unix/ptlib/config.h:55: destructors
must be member functions
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/unix/ptlib/config.h:57: syntax
error before `protected'
In file included from /local/dist/asterisk/pwlib_1.6.0/include/ptlib.h:187,
from ast_h323.h:30,
from ast_h323.cpp:29:
/local/dist/asterisk/pwlib_1.6.0/include/ptlib/args.h:121: syntax error before
`{' token
(This isn't the actual latest version, but the one published on the
OpenH323 mailing list as the one to use to pick up the patch for the ASN.1
problem.)
-Thanks, Jim
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Patching Asterisk for OpenH323 ASN.1 Vulnerabilities
On Thu, Feb 26, 2004 at 09:43:00AM +1100, Adam Hart wrote: Wierd errors, the actual library compiled fine though? Cause pdirect.h doesn't been touched for 5 months Yup, PWlib and OpenH323 built fine, no errors. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Grandstream transfer into outer space
On Wed, Feb 25, 2004 at 06:19:13PM -0500, Matthew B Marlowe wrote:
You said using the # feature gives you the ability to not lose a call if
you dial an invalid extension but that doesn't work for me.
When I dial # and enter an invalid extension I want it to sy ' invalid
extension' to ME and ask me to reenter one.
Instead if I dial # (or transfer button) and enter an invalid extension
it plays ' invalid extension ' to the CALLER and asks THEM to reenter an
extension number and the call is lost from me.
Hmm. Well, here's what I did. I modifited macro-stdexten so that the dial
command looks like this:
exten = s,1,Dial(${ARG2},20,tr); Ring the interface, 20 seconds maximum
When the receiver of the call presses # and enters an invalid extension,
it seems to be announcing it was invalid to the person who pressed #, and
then *resuming the call* -- you haven't lost anybody.
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
