Re: [asterisk-users] recording not working to NFS
On 10/17/21 12:59 PM, cio-al...@playerschool.edu wrote: I did test manually and the NFS mount works fine. I do create a directory and it shows at the server. I am using containers, indeed. How can it be affecting Asterisk that I am using LXC containers? I'm by no means an expert in containers, but from reading a few sites on the net and reading between the lines, here's how I understand it. Containers are, fundamentally, a way of isolating an app environment from other things. With LXC one must apparently explicitly grant the container access to resources such as filesystems. Apparently, if you expose a filesystem to a container, that exposure applies only to that filesystem - and not to other filesystems mounted within it. In order to allow a container access to an NFS resource, one must apparently do several things: 1. The host mounts the NFS share somewhere (e.g. /mnt/nfs/server5/spool). 2. The host must create a directory (e.g. /var/mounts/voicemail). 3. The host must do a loopback mount of the NFS share mount-point onto the second directory (e.g. "mount -o loop /mnt/nfs/server5/spool /var/mounts/voicemail") 4. The host must give the container access to the loopback mount point (separately from any other accesses)... in effect treating this as a separate disk or filesystem for the container. Once that's done, an app in the container (e.g. Asterisk) can access /var/mounts/voicemail and it'll be accessing the NFS share. At least, that's how I read what I read. I may be mistaken. I'd suggest checking the LXC documentation for the details. -- _ -- 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
Re: [asterisk-users] recording not working to NFS
I did not explain myself well, for this I apologize. The files never appear on the NFS mount, only in the local drive. Restarting Asterisk with the mount on does not fix it. Asterisk simply ignores the mount and writes to the local drive. But the mount is fine, I can create a dir and it appears on the other side, so NFS is fine. Any idea? That's a bit bizarre. I had first though that this might be a problem if you were to start Asterisk before mounting the share... Asterisk might have opened the message directory when it started, and then doing directory-relative file creation and moves. But, you say that restarting Asterisk doesn't change the behavior. On your system, are you using containers, or namespaces, or etc.? You might be accidentally setting up an environment in which the NFS mount isn't being "seen" by the environment in which Asterisk is running. It might also be worth checking if you can manually create files in the shared location when running as the same user-ID/group-ID as Asterisk is configured to use. You might be seeing some sort of odd permissions-based problem. -- _ -- 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
Re: [asterisk-users] Audio Dropouts During Call
>> A good Ethernet cable-pair tester can spot such things pretty quickly. > > I disagree. > > *Certainly*, incorrect pair terminations can cause the sort of problems > described, however I haven't yet come across a cable tester which can > identify > that a cable correctly connected from end to end with wires {1..8} <-> {1..8} > is in fact not correctly connected in ethernet 1-2 3-6 4-5 7-8 pairs. > > All cable testers I have so far encountered will check that all wires are > correctly connected end to end and not cross connected etc., but have no clue > whether the wire joining pin 3 at one end to pin 3 at the other end is > twisted > together with the cable from pin 4 or pin 6. > > I would be very interested to find such a tester, if you can point us at one. Well, I did say a _good_ cable tester, and that means "expensive" :-) I agree, the simple DC-continuity type of cable tester won't catch more than a fraction of the problems. These inexpensive testers ($50-$100 range, usually) can diagnose open wires, or cases where the two ends of the cable are wired differently and the signals don't match up at all. As you correctly point out, they're useless for "mixed pair" problems since these don't show up at all on DC. Electrical detection of such problems has to be done in a high-frequency (signal or pulse) domain. What you need is a tester which has either or both of two capabilities: (1) Crosstalk measurement - excite one pair with a signal, and measure the other pairs/wires to see if some of the signal leaks across onto them. (2) TDR - Time Domain Reflectometry. Excite a pair with a known pulse, and measure the voltage across the pair over time. This lets you measure the actual impedance of the pair all the way to the "far end". A swapped-pair problem will show up pretty quickly as an incorrect (and varying) impedance on the "pair" you are trying to drive. TDR can locate broken wires and sorts - not just the fact that they're there, but how far down the cable they are. A good TDR setup can even let you "see" things like a place where the cable has been bent too sharply or pinched, and the twisted-pair wires have been smooshed out of their proper configuration. As to specifics, a bit of Google-fu turns out the following possibilities. I haven't used any of them myself, but the data sheet summaries of capabilities look promising. The high-end Fluke cable-testers such as the CIQ-100, DSX-5000, and DSX-8000 would probably work - these are described as being able to locate crosstalk faults and impedance faults. Another very interesting device is the PocketEthernet tester, which sells for 199 Euros (less without VAT). It analyzes the wiremap, has TDR capability, and includes a bunch of higher-level diagnostics as well (bit-error-rate, Ethernet link analysis and capabilities- announcement, DHCP, ping tests, bit-error-rate testing, etc.). It uses a tablet or smartphone as its GUI (connected via BlueTooth) and generates a pretty spiffy-looking report in PDF format. I don't know what its sensitivity would be to such problems on a short (e.g. jumper) cable - that'd be a good question to ask the manufacturer. For diagnosing signal integrity problems in a building's installed Ethernet wiring, I'd want to have a device of this sort available. The high-end devices can probably be rented. The PocketEthernet is cheap enough that I'd just buy one if I can to do any work of this sort. There's also another dirt-cheap method for diagnosing bad Ethernet jumpers - substitution. Buy a bunch of known-good CAT-6E (e.g.) jumpers from a reliable vendor, and inspect them. Mark them as "This is a good one". If you have a suspect connection, start swapping cables one at a time - replace each jumper with one of your known-good supply and re-test to see if the problem goes away. If it does, take the cable you removed from service and _immediately_ cut off both ends right at the connector, and then throw the whole thing into the trash, so that no one will _ever_ put it back in service. Do not try to salvage, repair, or re-use a bad jumper - life's too short to try to pinch pennies like that. (If you don't do this, the old cable _will_ come back to haunt you some day.) -- _ -- 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
Re: [asterisk-users] Audio Dropouts During Call
> I looked at your network diagram. Try checking the configuration of the > Ethernet ports on the firewall and the Asterisk box. Make sure they are > set to auto-negotiate and not set to a fixed speed and fixed duplex. > I have found in the past that if one end of a link is expecting auto- > negotiation (as the switches probably are) and the other end is expecting > a fixed configuration, things can degrade to half-duplex trying to talk > to full-duplex, resulting in lots of collisions and packet loss when there > is any kind of significant traffic. > > Your description would be consistent with the firewall introducing lots of > LAN collisions when busy, in the central gigabit switch, even if the VoIP > traffic isn't passing through the firewall. Also, check the wiring. Check each individual RJ-45 jumper, *and* the in-house wiring, with a proper tester that can verify that the individual pairs are hooked up correctly. I've seen all kinds of hell occur, in situations where somebody used telco-type RJ-45 connecting cables, in place of proper Ethernet connecting cables. The problem is this: in a telco RJ-45 cable (such as was/is often used for proprietary telephone systems) the individual wires are either not in twisted pairs, or are twisted-pairs in a 1-2 3-4 5-6 7-8 arrangement. These work fine for analog connections. They're latent-death-on-wheels for Ethernet. Ethernet only works well if you connect the pairs as a 1-2, 3-6, 4-5, 7-8 arrangement, because this is how the signals are sent electrically. Using the correct connections ensures that the signals on each pair are "balanced" electrically - that is, the two wires in each twisted pair are carrying equal-but-opposite currents for the two sides of an individual signal. This minimizes electrical coupling between pairs, and thus minimizes crosstalk. If you use a telco-style cable (these are often black, and flat), or if you use what looks like an Ethernet cable but which had its wires "punched down" to the connector in the wrong pairing, things go very badly indeed. One twisted pair might be carrying one TX signal and one RX signal. This pretty much *guarantees* terrible cross-talk between the two. The symptoms of this can be as was related... the connection appears to work OK under light load, when there's usually traffic flowing in only one direction at a time. However, when you put a bidirectional load on the connection, the signals going from A to B and from B to A cross-talk with one another, leading to a very high rate of corrupted/dropped packets on the network. This will often show up in the end device's Ethernet packet statistics, if you can get to them... look for a high rate of dropped or "bad" packets, FCS (frame sequence check) errors, etc. I've seen a fair number of cheap "Ethernet" cables that had been manufactured wrong. You should see a color pairing such as http://www.hardwaresecrets.com/how-gigabit-ethernet-works/ indicates - pins 4 and 5 are a pair (blue, and white-and-blue), and the next-outer pins are also a pair (orange, and white-with-orange). If you see a pattern such as "white-with-green, green, white-with-blue, blue, white-with-orange, orange, white-with-brown, brown" where there are four color-matched pairs of wires next to one another, you've got a bad cable. The same error can occur when building wiring is "punched down" to the RJ-45 jacks. A good Ethernet cable-pair tester can spot such things pretty quickly. -- _ -- 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
Re: [asterisk-users] Asterisk pjsip registration issues
> Hey all > > I am trying to register a PJSIP server on our office to an Asterisk 11 > chan_sip server in a datacenter. > > I keep getting > WARNING[18084]: res_pjsip_outbound_authenticator_digest.c:178 > digest_create_request_with_auth_from_old: Host: 'XXX.XXX.XXX.XXX:5060': > Unable to create request with auth. No auth credentials for realm(s) > 'asterisk' in challenge. > > Any insights would be appreciated I have been banging my head for several > days now. I ran into a very similar problem when I tried to switch my PJSIP service with Vitelity from "fixed IP address" to "registration-based". I would try to place a call, and it would simply time out and then get a "busy here" error from Vitelity. Calls to a similar Vitelity sub-account from a Zoiper soft-phone worked just fine. I wiresharked the sessions and found that the critical difference seemed to be in the From: and Contact: headers. Zoiper set these to the Vitelity sub-account name (the registration name) while PJSIP just set them to "asterisk". I checked the PJSIP wizard file, and found that the outbound authentication object had the right username information in it, so that wasn't the problem. After stumbling around for hours, I found that it's necessary to set the "from_user" parameter in the endpoint object to match the username in the outbound authentication object. This causes PJSIP to send this value (rather than "asterisk") in the From and Contact fields of the INVITE, and this apparently gives the far end the information it needs to issue a proper credentials challenge. Once I added this one line to my definition and restarted, outbound calls worked like a charm. So, in pjsip_wizard, one would write something like [peername] type = wizard transport = transport-udp remote_hosts = outbound.peer.com sends_auth = yes endpoint/context = outbound endpoint/from_user = MYNAME outbound_auth/username = MYNAME outbound_auth/password = MYPASSWORD Modify and embellish as required. If you're writing your PJSIP objects individually rather than via the wizard, just set the fields in those objects appropriately. -- _ -- 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
Re: [asterisk-users] OT: Explain where mailing list bouncing comes from ?
I'm not sure of the precise specifics of how Digium runs the list, but this sort of problem has been a "known issue" with mailing list distributions ever since SPF and similar technologies showed up, almost a decade ago. DomainKeys and DMARC makes it more of an issue, but the overall problem is not new. I had to switch mailing-list packages (from Majordomo to GNU Mailman) for the lists I run, and configure Mailman properly to avoid the worst of the problem. In my experience, the problems affect mailing lists where: - The mailing list software retransmits an incoming message to subscribers, using the same sender address (in the SMTP transaction and/or message headers) that the original sender used. and - The sending domain has some sort of anti-forgery technology in place - either SPF or DomainKeys can trigger the problem. When such a message is retransmitted, one of several things can happen when it hits a mail server that does anti-spoofing enforcement: (1) "Hmmm. This message says it comes from j...@example.com, but the example.com domain has an SPF record which says that only the following five IP addresses are authorized mailers for this domain, and suggests a policy of 'reject' for other IP addresses. This message is coming from an IP address which isn't on that list. Reject it." or (2) "Hmmm. This message says it comes from j...@example.com. It has a DomainKeys signature from that domain, which covers the sender ID, subject, and message body. The signature doesn't match" [sotto voce, the Subject header was modified by the mailing list software to include the group name] "and example.com suggests rejecting messages which say they're from example.com but have bad signature. Reject it." There are almost certainly other, similar scenarios. As a result, messages of this sort will tend to "bounce" from hosts that implement forgery protection, and the mailing-list software will often react to a flurry of such bounces by unsubscribing the intended recipient from the list. None of the workarounds for this are perfect - they all have side effects. [A] Recipients who are being unsubscribed because gmail (e.g.) is bouncing such messages, can change their subscription to the mailing list to "daily digest". Mailman (and I believe most other mailing list packages) send out digests as new messages, with their own domain as the return address, thus avoiding the problems. [B] For SPF, the mailing list software can be configured to "take ownership" of the message... rewriting the sender address into a new form which doesn't break SPF rules. Examples for a message from j...@example.com might be Joe at example.com via Foobar mailing list Joe and so forth. GNU Mailman has the ability to do something along the lines of the first example. It's the configuration I use on the small mailing list I run. I believe it also adds a Reply-To: header to the message to "point back to" the original sender. It's possible to rewrite/substitute the message used in the SMTP session, but leave the original sender's address intact in the message headers. This will be acceptable to many (but not all) systems that check SPF. [C] For DomainKeys... well, if the mailing list software is going to make any changes at all to the headers on messages it's relaying, or change the message body at all, it should strip out any DomainKeys signature that might exist on the message. Or, it can send the whole inbound message (unmodified) as a MIME attachment within a new message it originates. This leaves the signature intact, but can be hard for many mail programs to handle gracefully. It would be up to Digium to do [B] and [C] for the mailing lists, if they so choose. Individual subscribers can do [A] to reduce the risk that they'll be unsubscribed from the list whenever an SPF-protected message is sent through the list. -- _ -- 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
Re: [asterisk-users] SIP Trunk over Proxy (matching ip of outbound proxy in incomming calls)
> Not sure maybe there's a better solution but I thought about using another > peer with type=user for incoming connections. That's what I've done for my connection to the service provider I use (Vitelity), as they have different inbound and outbound hosts/proxies. This works fine. -- _ -- 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
Re: [asterisk-users] Disallow CALLS without registry
>>> so the main question is -- how to Disallow CALLS without registering >>> on PBX > In fact, I'm not sure that it's actually possible to disallow [authenticated] > calls from a peer that hasn't registered! > > As far as I can tell, 'registration' was never intended to be part of the > authentication process. It's sole purpose is to inform the PBX as to the > current location of the endpoint. I suspect this means that what the OP is > asking for cannot be achieved with the current code bases. > > But each time I'm proven wrong I learn something, so if I'm wrong then please > by all means correct me! :) I think your understanding is largely correct... although I do believe it _is_ possible to achieve what the original poster wants, with a bit of dialplan trickery. I think you're correct, in that registration of a peer (using proper credentials) is not normally necessary in order for that peer to be able to place a call (again, with those same valid credentials). The "ingoing" and "outgoing" aspects of a peer are fundamentally separate... and that's why there's no option which requires registration to make a call. The way you're "supposed to" prevent unauthorized calls, is to make sure that each peer has valid (unique, cryptographically-strong) credentials (i.e. a proper password). The peer has to prove that it has these when it places a call - and, so, registration per se is irrelevant. As long as you don't allow anonymous calls to be placed, you should be OK. Now, there probably _is_ a way to force specific peers to register prior to placing a call, if that's what you really want to do (although I would ask "Why?" to anyone who wants to do things this way). The way I would do it, in Asterisk, is: - Turn on "qualify", so that Asterisk will check each registered peer periodically and confirm that it's still on-line. Using a modest registration timeout (a few minutes) is probably also beneficial. - Create a new dialplan context, which will be used as the initial context for all of these peers when they try to place a call. Specify this context in the definition of each such peer. - In this call-placing context, have a single ruleset which matches all numbers being dialed. - In this ruleset, retrieve the name of the peer placing the call (I think it's CHANNEL(peername) but I could be wrong). - Test the peer's SIP status with SIPPEER($peername:status) and see if it's OK. If so, the peer is registered - jump to another rule or ruleset which dials the requested number. If not, reject the call, or play a polite (or rude) message which explains that unregistered phones may not place calls. -- _ -- 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
Re: [asterisk-users] Multiple phones when one is unregistered
> So does the Dial command go directly to the registered device or does > it use the extension? If you've given the Dial() command the SIP/user1 format, it will attempt to dial directly to the SIP device/phone/endpoint you specify. If you specify SIP/user1&SIP/user2&... it attempts to dial directly to all of them simultaneously, and the first one which picks up, gets the call (the dialouts to the others are dropped when the first one answers). To the best of my knowledge there is *no* automatic fallback to the Asterisk voicemail which might be associated with one or more of these SIP users. The usual way that you'd get to Asterisk voicemail, is if your dialplan catches the error which would result from Dial() if none of the users is available and answers, and explicitly calls the Voicemail() app. Things can become more complicated in a couple of situations: (1) If one of the SIP users you specify isn't actually a SIP endpoint device, but is a SIP identity on another system (PBX or VoIP provider or etc.), then you really don't have any control over how that endpoint would handle situations where the called user isn't available. The endpoint might answer with *its* voicemail, immediately. (2) If you were to dial a Local/ destination rather than a SIP/ destination, then that dialing operation *is* run back through your dialplan, and it might divert the call to voicemail instantly. The easiest solution to each of these is "Don't do that". Don't multi-dial to anything other than SIP (or IAX) endpoints which are real, physical devices that either ring (if they're connected) or fail to respond or reject the call (if they aren't available). Don't multi-dial to any SIP device which implements its own internal "voicemail" feature (e.g. has an answering machine attached). I do what you're thinking of all the time. On my Asterisk setup, one incoming PSTN number goes to an extension which multi-dials about half-a-dozen of my SIP softphones. No matter which tablet or PC I happen to be using, if I'm running the SIP softphone app, it'll ring. The only time the call fails from this dial is if none of the SIP devices answer. I could route to Asterisk voicemail in this case, but I don't bother - Asterisk simply rejects the call with a no-answer or not-available status, the VoIP provider fails the call, and Google Voice (which is where the original number is anchored) sends the call to its own voicemail system and I get an email. The only down-side to this is that the Asterisk log gets a bunch of "SIP call failed" status messages each time this happens - one for each dialed SIP user that wasn't "on the net" at the time. This isn't a problem for me in practice. > I was assuming that it was going to the > extension's voice mail if it wasn't there but that's in the extension > dialplan and I suspect that the extension is irrelevant and only the > SIP registration matters. Correct. -- _ -- 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] Removing mailbox and password prompt for voicemail
> I am using ODBC realtime storage with Asterisk. Currently, with no password > set, a user can dial the voicemail number to retrieve their own voicemail, > without needing to enter a password (without hearing the password prompt). > However, there is still a 'mailbox' prompt played, and if a different > mailbox number is entered after this prompt, then a password can be entered > (if set) which intrudes into the other person's mailbox. I want to remove > this 'mailbox' prompt so that users won't have this opportunity to access > another person's mailbox. So... I think you've been given all of the necessary elements to a solution which will allow you to do this, while still maintaining adequate voicemail security. (1) Set up an inbound voicemail mailbox (you've already done this). (2) Set up a strong, non-guessable password on the mailbox. This will allow you to access the mailbox remotely, if you wish (by using the "* during the mailbox's greeting" feature) without allowing random callers to break into the mailbox. (3) Set up a custom dialplan context for those phones that you wish to give "password-less" access to the mailbox. (4) In this context, add an extension which, when dialed, runs the VoiceMailMain() application, specifying the correct mailbox identifier for those phones, and including the "s" option (which will bypass the password prompt). (5) In sip.conf, place each of these phones into this custom dialplan context. (6) If desired, record a different voicemail greeting message in place of the "Camedian mail", convert to the correct format, and place into your voice-prompts directory. (7) Do a "dialplan reload" and "sip reload". Voila. You're done. From any of these phones you'll be able to dial the extension you added in step (4), and go right to the voicemail "You have NNN new messages" greeting and the menu. No password required. You'll also be able to access your voicemail remotely (and safely) by dialing one of these extensions, waiting for the "Please leave a message" greeting, and hitting "*", and then entering the password. -- _ -- 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] 11.21.0 : echo woes : can't installcanceller (sean darcy)
>OK. Maybe an echo canceller won't make any difference. But why does the >remote side _always_ hear an echo if we use a local dahdi extension, >and _never_ when we use a local SIP extension ?? The echo that the remote called hears, might be of either electrical or acoustic origin. If electrical, it would indicate a mismatch between the line impedance of the Dahdi card or device and that of the phone extensions being used. You might be able to adjust jumpers or settings on the Dahdi card to select an impedance which matches the phone better, and reduce the echo. Or, use a different type of phone, having a better-matched hybrid in it. If acoustic, it would probably be due to bad phone handsets. I've seen quite a few cheap phones where sound coming out of the speaker could travel through the handset body (like going through a pipe) and reach the back side of the microphone and be picked up by the mike. Better phone handsets don't have this problem; those that do can sometimes be improved by stuffing the inside of the handset with some sort of damping material such as cotton wading or Dacron pillow stuffing. Speakerphones are, of course, notorious for generating echo. SIP phones won't have the impedance-mismatch issue at all, and their handsets may simply be better-designed with respect to acoustic feedback and leakage problems. -- _ -- 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 encrypted authentication for clients
> Thanks Jeff, just to confirm, password are not sent in plain text? I > want to safeguard against man in the middle attacks, sniffing traffic of > clients. That's correct. The way it works is: - Both the client, and Asterisk, know what the password is. - The client sends a SIP message which would require authorization (a register or invite, for example). It provides the username in the message. - The server generates a random "nonce" (basically a big random number) and sends it back to the client... basically saying "Use this nonce, and your password, to prove who you are." - The client combines the nonce, and the password, and uses the combined data as input into a hashing function (I can't recall whether MD-5, SHA-1, or something more modern is used). I *think* some of the other details of the original message are also included in the hash but don't recall for certain. - The client re-sends the original message, and includes its username, the nonce, and the hash. It does not send the password at all. - The server makes sure that the nonce is is the most recent one it sent, and that this is the first time the client has sent back that particular nonce. Once that's certain, the server uses the nonce and its copy of the password to compute the hash, and compares this with the hash the client sent. - If the hashes match, the server "knows" that the client knows the correct password (to a very high degree of certainty) and it allows the command to proceed. If they don't match, the client doesn't know the password, and the command is rejected. The hash functions that are used, are ones which would make it extremely difficult (months or years of computing time) to figure out what the password is, by breaking the hash algorithm. Of course, if a "weak" (short, guessable) password is used, it can be broken by a dictionary attack or brute force - the hash technique can't defend against this. -- _ -- 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] Connecting peer if the peer is already connected
> Now I have the problem for my cellphone... I need to register from almost any > IP (at least in Europe), so I can't restrict it. > Well, the password is NOT simple and random. > > Now, I tried to register the user of my cellphone using a PC, as my cellphone > was already registered. > And Asterisk accepted this registration... :( Were you trying to register the PC using the *correct* credentials used by your phone (the right username and password), or *incorrect* credentials (wrong password)? If your PC offered up the correct credentials, then I believe it's entirely normal behavior for Asterisk to accept this registration, and "bump off" the previous registration which used these same credentials. Asterisk (and most SIP servers) will treat this situation as an "Oh, this is a valid user of mine who has moved to a different IP address." The same thing would happen if your cellphone were (for example) to switch from cellular IP to WiFi, or vice versa, or (in many cases) moved from one service area to another. The way you avoid confusion between multiple devices, is use different (unique) credentials for each SIP client... and, of course, use strong, difficult-to-guess passwords. Any time you try to share credentials between two or more distinct devices, confusion *will* occur if both devices are on-line at the same time. You can never tell which of the two will succeed in establishing and holding a registration... although it will typically be the one which forces through a registration packet the most frequently. If you were to somehow tell Asterisk "Don't accept a different registration for my cellphone user , if user is already registered", you could quite easily find yourself unable to register the cellphone with Asterisk for a prolonged period of time... the PC could lock you out, and the cellphone could lock *itself* out every time it moved from one IP network to another. -- _ -- 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] Can Asterisk help me with some requeriments, of my current project?
> 1 - My SIP server (Asterisk) will have some SIP clients registered in its SIP > registrar. Let's say 6 SIP clients. In my project I have to implement a way > of a SIP client making a call to a number and all others 5 SIP clients ring. > That is, the others 5 SIP clients must receive the SIP INVITE. Can Asterisk > help me with such functionality? The Dial() application lets you specify two or more destinations, separated by "&" characters. When you execute an application call of this sort in your dialplan, Asterisk dials all of the destinations in parallel. If they're SIP clients, each will receive an INVITE at the same time. http://lists.digium.com/pipermail/asterisk-users/2005-April/094621.html > 2 - When several SIP client ring, if one answer the call first, the others > will have to stop ringing immediately. Can Asterisk help me with this > requirement? If you use the "dial in parallel" technique I just described, when one client answers the call, Asterisk sends out a "cancel invite" to each of the other clients it had dialed. This *should* result in each of those other clients stopping their ring promptly... but that's up to the client. > 3 - How to avoid one of the SIP clients receiving SIP INVITES? That is, one > of the SIP clients is forbidden to receive calls. Is there a way to program > it in Asterisk, maybe via dial plan? The question of which clients are called in response to a Dial() in your dial-plan, depends entirely on which clients are named in that Dial(). If you have five clients, and only include three of them in a particular Dial(), only those three will ring. If you have a client which is never named in a Dial() anywhere in your dialplan, Asterisk will never call it. It will be an "outbound calls only" client. > 4- Let's suppose that I have a data base (let's say SQLite) in my SIP server > (Asterisk) and I need implement a way of SIP Clients executing queries in > such database. Could such queries be done/sent via SIP messages to Asterisk? > Is there a way of accessing a database by meas of Asterisk, during a call, > for example to collect information about others SIP Clients? Here I'm > intending to create a software to be a kind of interface between Asterisk and > the database, if necessary. In principle, a client could "dial" a URI which includes parameters for a SIP query. Asterisk's dialplan would recognize this URI (for example, it might start with *888* or some other such string), parse it, and feed the bits to an SQL query. With this approach (or any approach which accepts an SQL query or parameters from a client) you must be *EXTREMELY* careful to avoid "SQL injection" attacks. The story of little Bobby Tables is what I'm talking about here: https://xkcd.com/327/ > 5 - If I need to send SIP messages all encrypted, using SSL or TLS , to the > Asterisk, will this SIP server be able to interpret all messages correctly? > Is there a way of let Asterisk talk with SIP clients in a secure way, using > SSL, for example? Can Asterisk help me with this? https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial -- _ -- 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] sedwa...@sedwards.com causes me to be knocked off the list
> Someone on this list uses the address @sedwards.com > > I doubt this is their actual email address as there is no MX record for > sedwards.com and I can't find registration for their domain either. > > Part of my mail servers reject these emails because they cannot be > replied to, or are likely to be spam. > > Every so often I get a mail from the list management to say that I've > been unsubscribed because of excessive bounces and it takes a single > click to re-register. > > It's a bit of a niggle for me. What do you think I should do? Change my > servers so that I don't check sender domains? If the SMTP session is saying "MAIL FROM: ", and if "sedwards.com" has no MX or A addresses on file with DNS, then I think it's appropriate to reject the mail at that stage, either permanently or temporarily. The latter is probably better in case there's a transient DNS problem. Your server should send an error message in response to the "MAIL FROM" command. The Asterisk mailing list servers should *not* be forwarding messages to list subscribers in this way. Most of the big mail providers are now performing SPF (or similar) validation on the "MAIL FROM" addresses, and will reject a lot of mail which is "reflected" through mailing-list servers. Current practice is for mailing-list servers to "rewrite" the sender address in the envelope (to a form which identifies their own domain as the intermediate relay/sender) or to just use an address such as "asterisk-us...@list.digium.com" as the MAIL FROM address. Now... if you're digging into the message headers themselves (e.g. looking at the "From: " header) and rejecting the mail because the address therein isn't legitimate... that's a different issue and a bigger problem. Your mail server can't do this during the initial SMTP handshake... only after it accepts the entire message from the sending system. This creates an anomalous situation, because your server provisionally accepted the message (by saying OK to the MAIL FROM, RCPT TO, and DATA requests from the sender), and then rejected the message as undeliverable "at the last moment". Not a good thing, according to the SMTP spec, and it's not surprising that some servers will consider this a practice which justifies blocking further deliveries to your system. In this case, you'd be better off accepting the mail normally via SMTP, using your spam filter to "tag" it with a "suspicious" label, and the filing it in a "spam" folder or just discarding it after reception. >From the point of view of the sending system, it will have been accepted normally (rather than rejected or bounced) . One thing you definitely should *NOT* ever do, is accept a mail message via SMTP (saying "OK"), determine that you think it's spam, and then have your mail server "mail back" a "rejected" bounce message to the sender. This is bad, bad, bad. It causes "back-scatter" - if mail is sent with a forged sender address (which is quite common) the poor schlub whose address was stolen for this purpose is likely to get a reject message for every copy of the forged mail. This can put a horrible burden on the victim's mail server. -- _ -- 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] Investigating international calls fraud
> Hmm the calls are made during the day (and sometimes very early in the > morning). Right now it looks like someone actually made these calls. If > that is the case it's somewhat comforting to know the system wasn't > compromised. However, the $25,000 phone bill still remains. Yikes. $6.25 > per minute to Cambodia seems quite steep to me. Since the Mitel had a default admin password, it seems possible that somebody accessed its UI over the network, and then accessed and copied its SIP credentials for your Asterisk server. If that's the case, the calls might not have been placed through the phone. The miscreant could have configured the purloined credentials into another hardphone, or a softphone app on any PC or tablet or cellphone which was able to access your LAN. The "cloned" phone would not have needed to actually register with Asterisk... it could simply have send an INVITE to place a call, and Asterisk would have challenged it and then accepted the credentials. If your CDR log shows IP addresses for each call, you might be able to compare these with your DHCP (or whatever) IP registration service, and see if the calls actually came through the phone or not. If not you might be able to identify the device which initiated the calls. The bad news is, I suspect that you're probably "on the hook" for the cost of the calls. In the case of an "inside job" it's often hard to legitimately "disavow" the charges. You may have to pay the bill and then (if you can identify whomever placed the unauthorized calls) attempt to recover the cost from him/her in court. This sort of misused by an insider might be "theft by conversion". -- _ -- 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] PBX hacked: why hundred of calls to the same number ?
> Is the destination Number like Country Code +972? > > +972 59 xx(x) mobile - Jawall [moving to 7-digit subscriber numbers] > > source - http://www.wtng.info/wtng-972-il.html > > My SIP Proxy logs all the unauth. INVITEs and I found the a lot calls go > to the Country code +972 xxx I've seen that a very high percentage of the "SIP probing" my Asterisk system has seen over the past few years, consist of attempts to phone numbers in +972 (or, more generally, the West Bank and/or Gaza). It's consistent enough that I've set up a Fail2Ban rule which slaps a semi-permanent block on any IP address which tries this, even once. Since the last time I did a firewall-reset, the resulting iptables rules have blocked over 2000 call attempts (one attacker at 142.54.180.50 has tried over 1200 times). These attempts seem to come from all over the world... I'd guess that the majority are being sent through 'botted systems. -- _ -- 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] recording in mp3
> Problem with this is client needs to listen to the call recordings and my > interface will only display .wav or .mp3 so they will moan if they have to > wait until the next day for today's recordings If you're up to writing a bit of shell script, and are running on Linux, you could automate the conversion process so that it happens as soon as the recording is completed. Look at the "inotify" system service (man section 7) and the "inotifywatch" program. You can tell inotifywatch to monitor files being written into a specific directory (or set of directories) and output a series of events when files in this directory are open or closed. What you'd probably want to do, is catch the "close_write" events (a file has been closed, and it had been opened in a mode which allows it to be written). When you see a close_write event for a recording file of the sort that Asterisk writes, you'd check to see if it's been converted to your desired format yet. If not, fire off a separate task (e.g. via "batch") to convert it. Here's a very simple script I did to do something like this... run a periodic-processing script a few seconds after files with a specific name pattern have been touched in any way. It's not sophisticated enough to look only for close or close_wait events, but it should give you the idea. #!/bin/bash function processevents () { action=0 while true ; do if [ $action == 0 ] ; then timeout=300 else timeout=5 fi read -t $timeout event if [ $? != 0 ] ; then action=0 /data/soundchaser/periodic else if [[ $event =~ ".wav" || $event =~ ".gotit" ]] ; then action=1 fi fi done } cd /data/soundchaser inotifywait -m /data/soundchaser/public_html/done | processevents -- _ -- 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] g726 transcoding
> Just checking the transcoding on our Asterisk boxes and I get the > following results. > I have the g726, ilbc and lpc10 formats and codecs enabled in 'make > menuselect' so I dont understand why its showing as no translation path. > Any ideas? Are the modules actually loaded? Try doing a "module show" and see if the codec modules actually show up as having been loaded. If not check your modules.conf file and see if they've been disabled, and check your Asterisk modules directory to confirm that they were actually installed. -- _ -- 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] Tired of dropouts and garbled phone, calls - where to go next?
> In my case, I have good incoming quality and terrible quality going out. > That is, I can hear people perfectly well but they complain that my > voice drops out and is garbled regardless of who places the call. This suggests to me that you may have congestion problems in your "upstream" traffic flow. Setting QoS on the packets may not help, if whatever router you are using for Internet connectivity isn't managing the traffic flow well. In my experience, you need to do two things: - Make sure that the traffic with QoS for low latency, is placed in a separate transmission queue on the router from "bulk" traffic (e.g. web service, file transfer). - Make sure that your router uses a "traffic shaping" system, to ensure that data isn't being submitted to the network interface faster than it can actually be transmitted by the *slowest* link in the path to your Internet provider. A lot of routers, switches, and network interface drivers these days have a lot of buffering. This is a mixed blessing. Unless you are careful, a burst of low-priority (bulk) traffic can be transmitted into your switch/router, and fill up a bunch of the buffer... by the time the system "knows" that you have some audio-QoS traffic to send, there's a whole bunch of data ahead of it in some network router or switch (or even the ring-buffer in a network interface card) and there's no way for your audio data to "jump ahead" of the bulk data in order to be delivered quickly. Ideally, your system should send data upstream at a rate which never "bursts" up to, or above your link's sustained data transmission rate. You want the buffers in the "upstream" equipment to remain as empty as possible. For background reading on this, look up the "Bufferbloat" problem and project, and the "Linux ultimate traffic shaper" scripts. They may not be directly applicable to your problem but may explain some of what you are seeing. -- _ -- 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 register peer (the quest for near 100% availability)
> Is there any way to force this? I have several user agents and I want to > achieve > near 100% availability for all peers. I realise that the peer will be 'woken' > up > at my qualify intervals, but can I actually force registration from the CLI? For those peers which are at known, fixed, predictable IP addresses (e.g. in-house phones which have statically-configured IP addresses or which get non-dynamic addresses from a DHCP server you control) you do not need to use registration at all. You can simply hard-code the peer's address into sip.conf (or, I presume, an equivalent realtime table). When you Dial() such a peer, Asterisk will start sending out the INVITE packets, regardless of whether it has heard anything at all from that peer in the last hour or fifty. No need for "qualify" although you can use this to keep track of whether the peers are actually alive or not. If you take this approach, you'll save yourself a great deal of heartburn if you can figure out an automated way of keeping the IP addresses synchronized, between Asterisk and whatever "hand out the addresses" mechanism the phones use (DHCP, TFTP-based provisioning files, etc.). Keep a "master list" of peers and addresses in a simple table or file somewhere, and use this to populate the other pieces of software which need to know. For peers which can move around to arbitrary IP addresses, and where your server system won't know what those addresses may be in advance, using REGISTER from the device is really the only good approach. If you've got a setup where devices change their IP address frequently and need to be on-line constantly, I'd say you have a fundamental problem with no easy solution. Using a short registration time limit (e.g. 30 seconds) is probably the least awful way to handle this, and if you're talking about a very large number of phones you may want to set up a dedicated SIP proxy to handle this registration burden and keep Asterisk from having to deal with it. -- _ -- 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] IAX2 over OpenVPN connection.... working but
>> Here's where I am baffled and I am hoping someone with intricate >> knowledge of this implementation may be able to explain it to me. What >> we had to do to get this working was to set the host= parameter to the >> respective endpoint IP's of the VPN tunnel, 172.10.1.1 in my case, and >> 172.10.1.2 in his case. Calls flow normally now and we cannot understand >> how or why. I would have assumed with a destination of either LAN as >> defined by the routing table it would have left out on the OpenVPN >> connection by default, and what's even more strange is that IAX is the >> only protocol that does not appear to function as intended. > My guess is asterisk is replying using the tunnel ip address which your > original box won't accept unless you actually sent to that address. Thats > what I see on our remote openvpn tunnels. If you want to know whats going on > use tcpdump to check packets through the tunnel. Yes, I've seen this same problem. It has two possible solutions. The reason for the problem is this: IAX2 (the Asterisk implementation, at least) depends on the "source" address in the UDP packet it receives, to know which connection the packet is part of. When it talks to a peer, it expects to see the packets arrive from the peer with a source address which matches what it understands the peer's address to be. Packets arriving from "unknown" addresses, are simply dropped on the floor (considered to be misrouted, misconfigured, or forged, I think). Normally, the Asterisk IAX2 implementation does not bind itself to a single network interface. It will receive UDP packets to the IAX2 port, arriving from any interface. And, when it sends an IAX2 UDP packet, it simply sends it out through the socket which is bound to the "any interface" port. Because the socket isn't bound to a specific interface, it doesn't have a specific IP address associated with it. The Linux kernel chooses an IP address to put into the UDP packet "source" field, and the one it chooses is the IP address of the interface on which it is transmitting the packet. In the scenario that's being described here, an address result mismatches. Each system is transmitting UDP packets *to* the "primary" or "official" or "public" interface on its peer... and these packets are being transmitted by the Linux kernel on the OpenVPN interface, and are being given the system's OpenVPN tunnel endpoint address. In each case, when the packet arrives at the peer, the Asterisk IAX2 stack receives the packets, finds that it has no known peer at the tunnel IP address and no IAX2 session set up for this address, and discards the packet. There are, I believe, two solutions which don't involve modifying the IAX2 code in Asterisk. Both work equally well, as far as I know. One approach is the one you've taken - tell each system to "talk to" its peer's OpenVPN tunnel endpoint address, rather than to the "primary" address. This eliminates the IP address mismatch. This approach works fine if both systems are connected only via this OpenVPN tunnel, and always have the same OpenVPN addresses. The other approach is to configure each system to bind its IAX2 port *only* to one IP interface (usually the public one), to ensure that each peer knows how to reach its peer's public IP address (either directly, or via a route though the OpenVPN tunnel), and to tell each system to speak IAX2 to its peer's public IP address. In this case, since the Asterisk socket is bound to a specific interface, all packets sent through that socket will have the bound interface's IP address in its "source" field, and (once again) the address mismatch is eliminated. This second approach is preferable for "road warrior" configurations in which you might sometimes be using the OpenVPN tunnel, and sometimes not (e.g. a laptop or tablet IAX2 client which is sometimes on the corporate LAN and sometimes out on the Internet using OpenVPN). -- _ -- 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] SoftHangup for emergency calls
> Setting up a group of analog lines to use for outbound emergency calls > (911). My current dial plan and debug output shown below. It appears > that when the SoftHangup() is executed that the line does not really > hang up. In the case shown, I had reduced the group to a single DAHDI > (analog) channel and dialed in to that number from the outside. You can > see in the output that the SoftHangup() was executed, but the call was > not terminated - the outside caller stayed connected to something. > Caller no longer heard the sounds from the menu he was in, but the call > itself seemed to stay connected. That may be due to a common characteristic of PSTN lines (at least, it's common here in the U.S.) By design, most U.S. PSTN lines have a very asymmetrical response to a physical hangup: - If the calling party hangs up, the call is terminated immediately. - If the called party hangs up, and the calling party does not, the line remains "live" for some time (typically around 30 seconds, I believe). If the called party goes off-hook again during this period, they can resume the call. If I recall correctly, things were designed this way so that the called party could say "Oh, hang on, I answered this call in the bedroom and the stuff I need is in the living room", hang up the extension phone, go to another room, pick up the other phone and carry on with the call. If that's what you're running into here - if the line you are trying to SoftHangup() was handing an inbound call - then there may be no good solution. As far as I know, there is no way to force an incoming PSTN call to release the line, other than "go on-hook, and wait for 30 seconds to pass". Several possible workarounds, roughly in order of increasing complexity and decreasing reliability: (1) Keep one of your PSTN lines reserved for emergency calls only; remove it from your inbound hunt group and place it in a Dahdi line group of its own (or don't group it at all). (2) Keep one of your PSTN lines reserved for *outbound* calls only; you should be able to SoftHangup() an outbound call within a second or two. (3) Figure out a way to check the PSTN lines that are in use at the time of an emergency - if they're all in use, somehow find one which was in use for an outbound call, and select it as the one to SoftHangup() and dial upon. (4) If you must keep all of your PSTN lines in bidirectional use, you may have to *tell* the parties that the line is needed for an emergency call, and ask them to release the line. Do a barge-in on the channel, play an alert sound, play a message saying "Emergency call in progress, please hang up this line immediately, play the alert sound again for a few seconds, SoftHangup(), Wait(2), and then try dialing. -- _ -- 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] I can hear my own voice through the headset
> Here is my IP-PBX setupmy setup is : sips softphone <-> asterisk <-> xorcom > PSTN gateway <-> pstn line to telcoi'm using xlite for windows > when I make a phone call (sip - outgoing channel),I can hear my own voice so > clear. it's very annoying mewhen talking a little loud... any solution? Two questions: (1) Does the problem occur when you make a SIP-to-SIP call, without the PSTN being involved? (2) When you hear your own voice in the headset, is it delayed, or is just an immediate louder-than-you-want "side-tone"? If it *does* occur in SIP-to-SIP calls, this would rule out your XORCOM and the PSTN as the cause. If it's only occurring in SIP-to-PSTN calls, then the XORCOM and PSTN (or the interaction between them) is a likely suspect. There are several things which can cause this sort of problem. (A) Direct acoustic feedback within the headset. In this case, you'd probably hear it even if the headset was unplugged entirely. The only cure is to buy a better headset. (B) Incorrect audio-mixer settings in your PC. To the PC audio infrastructure, a headset usually "looks like" a microphone and a separate speaker. The audio mixer (hardware and software) usually has an ability to mix some of what the microphone "hears" into the speaker output. If this "knob" is turned up too high, you'll hear your own voice too loudly. If too low, you won't hear your own voice at all when you speak into the headset, and many people find this lack of side-tone to be confusing. The cure here is to adjust the audio side-tone level, either in your Windows audio-mixer control panel, or in X-Lite (if it has such an adjustment). (C) Electrical "reflection" from an analog impedance discontinuity in the analog telephone-line system. This can result from a mismatch between the telephone wiring, and the PSTN interface device, and can occur at any point in the analog transmission. If the loud side-tone you hear is *not* delayed noticeably, then the impedance mismatch might be at your XORCOM/PSTN interface. The XORCOM may have a software adjustment or jumper setting, to match its audio impedance to that of your local phone line... try fiddling with these settings to see if they reduce the excessive side-tone level. If the loud side-tone you hear is delayed (it sounds a bit like an echo) then it may very well be at the "far end" of the phone line, outside of your own physical control... it might be at your local phone office, or anywhere between you and the far end of the phone connection. Not much you can do about this. (D) Audio feedback at the far end of the call, in a cheap phone handset. Sometimes, audio from the "back side" of the speaker in a handset travels through the body of the handset and is picked up by the microphone, and results in an audible delayed "echo" of the voice from the far end of the line. Using a better handset, or stuffing the handset full of audio damping material (cloth or cotton or fiberglass) is the cure here. -- _ -- 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] chan_sip sending from wrong source, address when multiple interfaces are used
> I must be missing something. If a phone sends a UDP packet to > 192.168.1.1, how does that get routed to (arrive at) the 10.0.2.1 > interface on the Asterisk server? The only way I can imagine that > happening is if a router in between the phone and the server has been > told that 192.168.1.0/24 is reachable *through* 10.0.2.1, which seems > like a bizarre way to construct a network. Getting replies from Asterisk > *back* to the phone would also require the IP stack on the Asterisk > server to route those replies back over the 10.0.2.0/24 interface > instead of the 192.168.1.0/24, which doesn't make any sense either. This can and will happen, if the multi-interface Asterisk server is also being used as the router between these networks. In this case, the packet sent by the client system to 192.168.1.1, is being sent by the client to the client's active (possibly default/only) routing gateway, which will be 10.0.2.1. The packet arrives at the server/router, and because it matches the IP address assigned to one of the server's network adapters (and Asterisk is bound to all of them) it's delivered to Asterisk. When Asterisk replies, it's doing so via a socket which is bound to 0.0.0.0. Since there's no specific IP address bound to this socket, the kernel has to pick one of the host's IP addresses to put into the packet it sends... and the one it picks is the one assigned to the network adapter on which it chooses to transmit the port. In this case, that will be 10.0.2.1. So, the client sends a packet to 192.168.1.1 and gets a response from 10.0.2.1, which is a huge WTF situation for many protocols. This is not just an issue for SIP. I've had exactly this same problem with IAX2 clients and Asterisk, and had to apply the exact same cure - I tell IAX2 to bind itself only to my host's externally-routable public IP address, and not to 0.0.0.0. Then, if I specify the public IP address as the server in each IAX2 client configuration, everything works fine. This is probably a not-unusual configuration if you're setting up a modest-size "VoIP-only" or "VoIP-mostly" network on a budget... a Linux or other Unix-ish system running Asterisk will often have enough CPU power to handle the RTP routing between networks, saving you the cost of a dedicated router. I have this very issue on my own system - a modest home network with a couple of internal LANs, some IP ranges set aside for VPNs of various sorts, and one externally routable IP address. > chan_sip does have the ability to use connect()-ed sockets for dialogs > now, since that is required for TCP, TLS and WebSocket support. It > wouldn't be a huge leap to use them for UDP as well, if that was beneficial. Would be well worthwhile... and if you can port similar code over into chan_iax2, it would fix the problem there as well. -- _ -- 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] Fwd: RTP stats explaination
> In our app we do not forward packet immediately. After enough packet > received to increase rtp packetization time (ptime) the we forward the > message over raw socket and set dscp to be 10 so that this time > packets can escape iptable rules. > >>From client side the RTP stream analysis shows nearly every stream as > problematic. summery for some streams are given below : > > Stream 1: > > Max delta = 1758.72 ms at packet no. 40506 > Max jitter = 231.07 ms. Mean jitter = 9.27 ms. > Max skew = -2066.18 ms. > Total RTP packets = 468 ? (expected 468) ? Lost RTP packets = 0 > (0.00%) ? Sequence errors = 0 > Duration 23.45 s (-22628 ms clock drift, corresponding to 281 Hz (-96.49%) > > Stream 2: > > Max delta = 1750.96 ms at packet no. 45453 > Max jitter = 230.90 ms. Mean jitter = 7.50 ms. > Max skew = -2076.96 ms. > Total RTP packets = 468 ? (expected 468) ? Lost RTP packets = 0 > (0.00%) ? Sequence errors = 0 > Duration 23.46 s (-22715 ms clock drift, corresponding to 253 Hz (-96.84%) > > Stream 3: > > Max delta = 71.47 ms at packet no. 25009 > Max jitter = 6.05 ms. Mean jitter = 2.33 ms. > Max skew = -29.09 ms. > Total RTP packets = 258 ? (expected 258) ? Lost RTP packets = 0 > (0.00%) ? Sequence errors = 0 > Duration 10.28 s (-10181 ms clock drift, corresponding to 76 Hz (-99.05%) > > Any idea where should we look for the problem? A maximum jitter of 230 milliseconds looks pretty horrendous to me. This is going to cause really serious audio stuttering on the receiving side, and/or will force the use of such a long "jitter buffer" by the receiver that the audio will suffer from an infuriating amount of delay. Even a local call would sound as if it's coming from overseas via a satellite-radio link. I suspect it's likely due to a combination of two things: (1) The fact that you are deliberately delaying the forwarding of the packets. This adds latency, and if you're forwarding packets in batches it will also add jitter. (2) Scheduling delays. If your forwarding app fails to run its code on a very regular schedule - if, for example, it's delayed or preempted by a higher-priority task, or if some of its code is paged/swapped out due to memory pressure and has to be paged back in - this will also add latency and jitter. Pushing real-time IP traffic up through the application layer like this is going to be tricky. You may be able to deal with issue (2) by locking your app into memory with mlock() and setting it to run at a "real-time" scheduling priority. Issue (1) - well, I really think you need to avoid doing this. Push the packets down into the kernel for retransmission as quickly as you can. If you need to rate-limit or rate-pace their sending, use something like the Linux kernel's traffic-shaping features. Is there other network traffic flowing to/from this particular machine? It's possible that other outbound traffic is saturating network-transmit buffers somewhere - either in the kernel, or in an "upstream" communication node such as a router or DSL modem. If this happens, there's no guarantee that "high priority" or "expedited delivery" packets would be given priority over (e.g.) FTP uploads... many routers/switches/modems don't pay attention to the class-of-service on IP packets. To prevent this, you'd need to use traffic shaping features on your system, to "pace" the transmission of *all* packets so that the total transmission rate is slightly below the lowest-bandwidth segment of your uplink. You'd also want to use multiple queues to give expedited-deliver packets priority over bulk-data packets. The "Ultimate Linux traffic-shaper" page would show how to accomplish this on a Linux system; the same principles with different details would apply on other operating systems. -- _ -- 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 show used "wrong password"
> Ouch. That isn't going to be so easy to spot, then! You would have to guess > a bunch of likely passwords, fake up a challenge with some known nonce, and > compare the response against those you would expect with each of the various > possible passwords. (You've already got the Source Code to do all this, of > course.) > > You'll have to try the selective unplugging method instead . There may be a way to do this, even in the face of the nonce-and-hash security system. As I understand it: when a system (re)registers with a good password, what you'll typically see is: - A registration request from the client (with the client's ID in the SIP parameters) - A response from Asterisk, saying something on the order of "Stale authentication. Try again. Here's a new nonce for you." - Another registration request from the same client, specifying the newly-issued nonce, and having a hash based on that nonce and the shared secret. - An "OK" response from Asterisk. When a system (re)registers, and has the wrong password/secret, the exchange will be different. - A registration request from the client (with the client's ID in the SIP parameters) - A response from Asterisk, saying something on the order of "Stale authentication. Try again. Here's a new nonce for you." - Another registration request from the same client, specifying the newly-issued nonce, and having a hash based on that nonce and the shared secret. - A response from Asterisk, rejecting the second registration request with something like a "bad digest" error. So, if you examine all of the SIP protocol exchanges taking place, you should see a whole bunch of successful four-way handshakes (from clients that have the correct secrets), and an occasional four-way handshake failure (from the one client that has the wrong password in its configuration). You won't be able to tell what password the client is actually trying to use - that's the whole point of the nonce-and-hash approach - but you'll be able to identify its client name, and (unless the far end is using a NAT or proxy) its IP address. To pin down the actual location of the client, you'll either have to go there, or have someone at the remote site do some investigation and (possibly) packet tracing on the LAN. Or, I suppose one could simply use Asterisk to try to phone the device or softphone in question, at whatever address it called in from, and ask whoever answers the phone to disable it! -- _ -- 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] Line noise/hiss on Openvox A400P card on FXO
> 5. Placing ferrite cores on the phone cables. Do either of the phone lines in question have DSL on them? If so, a ferrite core (which will block common-mode RF signals) probably won't help much, if at all. DSL is a differential-mode signal, and its frequency content starts down in the tens of kHz. Ferrite cores are usually intended to block much higher frequency interference, and won't have enough inductance to help much with DSL signals. What I would suggest, is that you get yourself a couple of DSL "microfilters"... plug them into the A400P FXO ports, and plug the lines into the filters. These sorts of filters are designed specifically to block DSL differential- mode signals from getting into analog-phone circuits, and they will also be fairly effective against other forms of low-frequency-RF noise. -- _ -- 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] Walkie talkie to sip phone interfacere:
> I've been trying to find a solution that would allow our sip phones to > communication with walkie talkies. Our setup is that we have sip phones > setup in 2 locations, headquarters and dome. We can communication from > headquarters and dome through sip phones, but within the dome we have > technicians that use walkie talkies to communicate as they go about > their work. Our hope is to allow 2 way communications from our sip > phones at headquarters (or within the dome) with our technicians using > their walkie talkies as they are working throughout the dome. Not sure > if this is possible but I would appreciate any suggestions. It's definitely possible. How practical it is, remains to be seen and is probably a "how well do the details work out?" issue. The simplest approach is probably this: you'll need a walkie talkie "base station" which will serve as the transmit/receive point for the dome. The most straightforward would be to use one of the actual walkie talkie radios, with a well-filtered DC power supply in place of a battery pack. You would need to hook up the W/T's "speaker out" and "mic in", and perhaps the "push to talk" line, to suitable audio and control I/Os on some sort of Asterisk end-point. The least expensive way would probably be to use the Asterisk server itself (or some PC running a soft-phone client), and use the PC/server's sound card jacks. You would need some sort of level-adjusting (padding) system for the signal being fed into the walkie talkie's "mic" input (these generally require much less voltage than a sound card's line-level output), and it would probably be a good idea to have an audio isolation transformer in each audio path to prevent ground loops and hum and RF pickup. You'd need some way of keying the radio's push-to-talk when someone on the phone starts to speak, and then release PTT when the voice stops. Some walkie talkies have a VOX (voice-operated switch) which will do the job. Others do not, and you would need a separate VOX circuit (not difficult). One possible hardware device which might save you trouble is the Tigertronics SignaLink USB - it's primarily designed for and sold to amateur-radio operators but has multiple uses. It consists of a USB "sound card", isolation transformers, an adjustable VOX/PTT circuit, and a very flexible radio-interconnect-cable system which you could adapt to the speaker/mic needs of your walkie talkie. You'd simply plug it into the server's USB jack, and it would become a secondary audio interface. On the Asterisk side, you'd want to use the ALSA channel driver, and create an inbound extension which would simply "dial" the ALSA channel. Or, you might decide to use one of the various Asterisk bridging/conference applications, and have the ALSA walkie-talkie channel be perpetually signed into a conference bridge which one or more other users could phone into. You'll need to select and implement a suitable security policy, to control who can access your dome audio link, and decide whether someone in the dome can use a walkie talkie with DTMF capability to dial calls or otherwise control the Asterisk system via radio. Finally, you need to make sure that all of this is legal in your particular jurisdiction. Here in the U.S., there are quite a few personal and mobile-radio services for which it is *not* legal to create a connection to the wired telephony system. This is probably something you should determine first, rather than at the end. -- _ -- 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] single registration per user
> Is about outgoing calls from multiple devices with the same username at > aprox same time. The overwritten is for incomming calls. I want to prevent > using the same account in multiple devices at same time. The solution with > IP will not apply because users may be behind nat or will change everytime > multiple access points. Do you have any other clues? As others have noted, this doesn't really have anything to do with "registration" per se. Registration by a user, tells where calls *to* that user should be sent (IP address and port). Authorization to initiate an outbound call through Asterisk doesn't depend on the device having registered. It depends on the device sending an INVITE with the appropriate user-ID, and the device's ability to respond to the corresponding security challenge from Asterisk. Any device having the appropriate ID and secret can thus authenticate on the outbound call... Asterisk won't (unless you jump through a lot of hoops) "know" whether this is the same device that has currently registered with that ID. I can think of several approaches which might work: (1) Set "call-limit=1" in the SIP user definition for this user. This will (if I'm reading the documentation correctly) limit Asterisk to only one call to this user/peer at a time. There used to be separate limits for "incoming" and "outgoing" calls, but that was eliminated several versions ago. (2) As others have suggested, do it in the dialplan using the GROUP function. Perhaps the simplest way to do this would be to set up a dialplan context which each of these users is bound to. In its "s" ruleset, set the GROUP() value to be the user-ID, and then check the number of members in the group... if it's more than 1, jump to a rule which does a Congestion() or plays a "You are a cheater and I make rude motions in your direction" recorded message or hangs up or ... If the group-count test succeeds, jump to another dialing context which actually does the dialing based on the $EXTEN passed by the caller. This would be a bit like example 2 in the page at http://www.voip-info.org/wiki/view/Asterisk+func+group but you would use a specific group name per user e.g. $CHANNEL(peername) rather than a group per outbound trunk. (3) Do something like (2), but instead of using the GROUP feature to limit calls, compare the caller's IP address with the IP address currently registered by the calling user e.g. compare $CHANNEL(peerip) with $SIPPEER($CHANNEL(peername),ip). This wouldn't be as robust as approach (2) - there would probably be moments when a second device could make a call - and so I don't really encourage it. -- _ -- 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] Looking for ideas for nice **Asterisk** home phone system
> Great discussion, all of it. Thanks, people. > > How much power does the home asterisk box need ? > > I'm using Asus Eee Box (1012Ps) as Myth front ends in another project. > About $280 with 320 Gb hard drive and 2 GB RAM. Atom 510 processor. Built > in Wifi. Nearly silent. Runs F15 nicely. Would one of them suffice ? I'm running my small home Asterisk system on an Itox motherboard with an Atom N270, at 1.6 GHz. No CPU-related problems noted. In fact, I'd run it fairly successfully on a Pentium Pro 200, and it worked well enough for simple uses (e.g. no fancy codecs or transcoding). > It looks like I am going to need an ATA for the fax machines. Two. My wife > informed me yesterday she wants her own in her office. VOIP handles fax > machines, right ? This could very well be the most problematic (heart-breaking, frustrating) part of your whole intended installation. Fax -> modem -> very sensitive to jitter and dropouts. Making fax work over VoIP (using A-law or u-law) is often feasible within a LAN environment, because the jitter and packet-loss rates are low. Making fax work decently on VoIP over the Internet is much harder... jitter and packet-loss rates which would be slightly annoying for a voice conversation can seriously disrupt or abort a fax call. Some (relatively few) VoIP providers support a specialized mode called T.38. in which their "far end" equipment intervenes in the fax protocol in order to "smooth out" the process of making fax work over a lossy/jittery/high-latency VoIP connection. This isn't common and seems to be hard to count on. I suspect you'll be better off either: (1) maintaining one analog land-line, and using it for fax (and perhaps backup for VoIP), and/or (2) subscribing to a commercial "fax to email" gateway service, in which people send their faxes to a number owned by the service provider, and the resulting fax is converted to a compressed PDF and then emailed to you. I imagine that some of these providers also have an "email to fax" service, operating in the reverse direction... you email a PDF or other file to an address alias they provide, and it's faxed out for you. You *can* operate a sort of hybrid system in your house, if that's convenient to you... e.g. a SIP ATA for your fax machine, to Asterisk, to an analog land-line (via either a dedicated PCI bus card, or an outbound port on a channel bank or certain ATA devices). The jitter and delay on the home LAN would be low enough that this should work reliably. You could also run a combination of hylafax, and iaxmodem on the Asterisk system, and thus use the Asterisk server as a fax-to-email / email-to-fax / document-to-fax gateway. > I'm wondering what phones everyone is using. Should I stick with analog > wireless handsets or are there some good SIP wireless phones out there that > I don't know about ??? Several companies make DECT SIP phones and systems... typically I think they'll handle 4 to 6 DECT handsets, and a couple of independent SIP calls at any given moment. These may or may not be less expensive than buying some one- or two-analog-line SIP systems, and some ATAs; they'd definitely involve less equipment and wiring. -- _ -- 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] Strange network issue
> They've got a bunch of Grandstreams that seem to be rock solid... until > 7:00pm. At 7:00, some of the phones become unavailable, and stay down. Call > quality is solid almost all the time. But right at 7:00, things go bad. > Only > some of the phone lines go down and they stay down until the phone is > rebooted. > > I'm not even sure what to look for when I go to the site. Any ideas? I'd look to see if there are any electrical circuits (lights, fans, etc.) which are on a timer of some sort, and are automatically powered off at 7 PM. If somebody mistakenly plugged a piece of network kit into such a circuit, it would lose power at that time, and your network might end up being partitioned, or routing (switch or IP-level) might change abruptly. If (for example) the phones were being DHCP-provisioned with network numbers and a "here is your default gateway" configuration, and that gateway were to lose power, the phones would lose connectivity, and might not recover until they discarded their DHCP credentials and routing information, and broadcast for a new configuration... which would happen if they were power-cycled, or (if not then) many hours later. Similar things could happen if (for example) a janitor were to plug a floor polisher into a power circuit shared with servers or network equipment... the turn-on / turn-off power sags and spikes might knock networking gear off-line. [This is not a hypothetical example... numerous cases of this sort of thing have been reported over the years.] If these phones are being DHCP-provisioned, you might want to check each phone and see what configuration has been acquired... i.e. if it got its information from the "real" DHCP server, or from some other source. I've had network problems in the past result from people plugging some sort of "all-in-one" appliance or server into an existing net... the appliance starts trying to provide DHCP service and routing on its own. This can seriously disrupt the network... either immediately (if the appliance's configuration is incompatible with the network) or at a later time (if e.g. the appliance is acting as a router, and is then powered off). -- _ -- 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] Using Firewall to protect Asterisk
>> > I need to keep out all connection from 5 countries, which originate >> > most of the Denial of Service attacks. The entries are around 9000 if >> > used as xx.xx.0.0/16. I heard that there is a smarter way to do this >> > by using User Tables in iptables, that will keep the speed equal to >> > LOG(x). I already tried using a straight list and it kills the box. Yeah, it would - running through 9000 separate rules for each packet would be prohibitive. >> > Unless a smarter way us found, there is no way to use iptables. Ideally, what you'd want to do is to somehow "pre-load" one of the really efficient matching modules in iptables (e.g. a hash table) with a list of the network numbers in question, and then be able to do a fast hashed lookup using each incoming packet's upper 16 bits... a hit in the table would indicate a reject, a miss would mean that the packet was OK for further inspection and processing. It looks to me as if there *is* a way to do this, but may require adding an iptables/netfilter module that is not part of the standard distribution. It's called the "set" module. Take a look at http://ipset.netfilter.org/ and I think you'll like what you see... it'll do what you want. Briefly, you'll need to: - Build this module for your kernel, and load it - Use the "ipset" command to create an IP-address set, and populate it with the 9000 different /16 entries you want to match against. I think the "ipmap" type is what you would want, as this can store up to 65536 entries and uses a single bit for each same-sized address range... lookup time would be constant. "iphash" is another possibility. - Use a single "iptables" rule to match incoming packets against this set. > iptables is just a user-space configuration interface to the Linux > kernel netfilter. The netfilter uses complex hash tables and other data > structures to ensure that packet forwarding rules are looked up in as > close to O(1) as possible, not even LOG(n)--LOG(n) would be way too > expensive. > > Other than conventional Cisco router access lists (notwithstanding > compiled lists an TurboACL), I don't know of any other packet filter in > the universe that does not do similarly. No packet filter would apply a > flat list, not the Linux netfilter, not the BSD packet filter, not even > Windows. The trick is using the right filtering approach. Doing it the naive way (one separate iptables rule per /16) would indeed kill the system's performance pretty badly. The right approach which will work, is one which can match incoming addresses against a complex set of yes/no criteria in constant or near-constant time. I don't believe that the standard "iptables" distribution contains a module which can do this... but the "ipset" extension module can, and is probably what the original poster wants. I may have to play around with this approach myself. Federico, do you mind if I ask which countries you're blocking, and which source you used to locate the /16 blocks in question? -- _ -- 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] 1.8.3 - IAX - echo - jitterbuffer
> I'm using iaxagent on a Droid X to connect by IAX to 1.8.3 at the > office. 1.8.3 has sip phones. The audio is fine on the Droid X side. On > the office side, they hear an echo of _their_ speech, not mine. > > The office uses sip-providers generally without any echo problem. > > Where do I start to figure this out? How do I narrow it down? Can I > figure out if it is an iaxagent problem? Could using jitterbuffer cause > this? One thing you must consider, is that this echo they're hearing may be entirely an acoustic one, within (or around) the Droid itself. It's very possible for the microphone in a handset to pick up sound being emitted by the handset's speaker. This acoustic feedback can occur within the handset itself (sound from the speaker "leaks" through the chassis of the handset and reaches the microphone from behind), via mechanical coupling through the handset body, or by the mic picking up the sound from the outside (after it has come out of the speaker into the air). The best way to determine whether this is the case, is probably to shut down the speaker and isolate the mic... plug in an earphone which has a separate mic on its cord, and see if the callers still report the echo. If they do, it's due to electronic or digital goofs somewhere, but if they do not, it's due to acoustic feedback at the handset. There are (in principle) three ways to reduce or eliminate the echo: - Damp it out physically - block the acoustic feedback pathways. In a small USB phone handset I have, I found it necessary to "stuff" the open spaces inside the handset with cotton and foam, to block the back-wave from the speaker before it reached the microphone. - Use software which has some sort of VOX (voice-operated switch) detection or squelching... so that when the sound level at the microphone is less than you'd get by speaking into the mic, the handset "cuts off" the mic audio pathway entirely, and sends only silence (or sends nothing at all, although Asterisk doesn't always deal gracefully with this). - Use a better handset. -- _ -- 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] Hide the plain text password
> How about encrypt the whole hard drive? > > If I built a server and give to other people, there is no easy way to > stop them reset the root password or just mount my drive to read > everything on it. But if build an encrypt OS then it will be secure. It will be more secure. However, you (personally) will need to be present at the server, every time it is powered up, in order to enter the appropriate decryption key. You can't place the key in a file on the hard drive, or as part of the GRUB or LILO boot configuration, or on a USB stick or floppy, because if you do, the people you give the server to will have the information they need to break the encryption. You would have just "pushed the problem back" by one step. The only way to keep the encrypted disk (and server) secure, is to retain physical control of the necessary decryption key. > My > question here are: <1>Is this against Asterisk GPL? That depends. If all of the software on the system is under GPL Version 2 (or the LGPL equivalent), then distributing such a system would be no different than distributing a system which didn't encrypt the disk. Under the terms of the GPL you would have to provide copies of the source code to the GPL'ed components to the system upon request, but you would not have to disclose the key used for a particular installation, If you include software which was under GPL Version 3, you might have to disclose the key. Ask a lawyer about that. ><2>How about the > performance on such a system? Anywhere from poor, to perfectly fine, depending on how much disk I/O you do, whether a hardware encryption accelerator is available, and what encryption algorithm you choose. If your Asterisk implementation isn't doing a lot of recording and playback of audio files to/from disk, and it isn't running other applications at the same time, I suspect you wouldn't notice a really significant difference between encrypted and unencrypted operation, once the system had booted up and was running in a "steady state". -- _ -- 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 on Debian Lenny with timerfd
> I know this is an {*} list but does anyone know if simply adding the Squeeze > repository to my sources.lst and running an 'aptitude > upgrade/safe-upgrade/full-upgrade" will just upgrade Lenny -> Squeeze > without me having to rebuild the system from scratch? In my experience: you're likely to run into a few things which need some amount of manual fiddling, after an upgrade of this sort, but it's usually quite manageable. The Debian people seem to be very good about making sure that stable-version-to-stable-version upgrades go smoothly... the process isn't perfect (from what I've seen) but it's usually quite close. The upgrade path is usually tested out quite well before the release team throws The Big Switch, and there normally are good release notes which describe the corner cases which may need manual intervention. I have several systems which have been through multiple major Debian upgrades, without having to be slagged down and rebuilt from the ground up. That's better than I ever achieved with (e.g.) Red Hat, which (in my experience) really didn't take at all well to in-place upgrades... I usually had to do a fresh install and then port my personal files over. Things may not be as smooth when jumping from Stable to Testing, precisely because this isn't an official-release pathway, and the packages in Testing are usually in somewhat of a state of flux. Even upgrades *within* the Testing distribution can leave you with a system which doesn't fly right... this isn't common but it does happen. For example, a recent upgrade within Stable pulled a bunch of the firmware files out of the kernel package and moved them to a separate "non-free" package - if I hadn't noticed an error message during RAMdisk rebuilt, my next boot would have left me with a non-functioning wired Ethernet adapter. If you decide to follow this route, follow the Debian instructions for upgrading... back up your package configurations, and (I suggest) everything in the /etc/ directory hierarchy, as well as all of your personal files. This will give you a much better chance to invoke the spirit of the ancient pagan god DoOver, if something goes wrong during the upgrade. -- _ -- 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 on Debian Lenny with timerfd
> In the meantime, does anyone have a nice way to update a stable/stock lenny > installation with the updated glibc as well as the latest kernel Scary and risky, as others have noted! There is an official "backports" release kit associated with Debian, which contains newer versions of many packages which have been back-ported to be mostly-drop-in-compatible with current Debian "stable" distribution. You can find information about it at http://backports.debian.org/ However, it does not appear to contain an updated release of glibc - likely for the reasons that other folks have alluded to (the stability risks outweigh the benefits). I suspect that unless you're willing to put a lot of blood, sweat, tears, and toil into the effort of getting the newer glibc into Lenny, you're either going to have to switch to the "testing" distribution (Squeeze) or wait until Squeeze is officially released as the new "stable" distribution -- _ -- 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] context problem
> I may be wrong here, but I think you can only register once. The last > registration received will overwrite the first one. You will need to > specify a second entry and register that one separately. This is the > same reason you cannot register two devices to the same extension. Yes, that's very likely what is happening. The provider is seeing two SIP registrations arrive, for the same provider account, from the same peer at the same IP address. It is very likely that the second registration is (by design) replacing the first. Then, whenever someone dials a DID associated with this provider account, the provider is routing the call based on the information in the most current registration... it's either going to the context and extension specified in that registration (if their is one) or to the "s" extension for the relevant context. (Some providers do allow multiple registration for a given account, and will INVITE all of them when an incoming call arrives, but (if I recall correctly) the registrations have to come from different IP addresses (and perhaps different peers) in order to be recognized as being distinct.) There are probably several ways around this: (1) Use two different provider accounts, and associate each DID with a different account. Use two "register" statements, one per account, and specify different routing extensions on these. (2) Use a provider which will let you register once, and will "pass through" the DID number which was dialed as the target extension. (3) Use a provider which will let you set up your DIDs for hardwired-IP-address routing (i.e. no "register" being required) and who passes through the DID as the extension to be called. I recently set up an account with Vitelity, and they support option (3). I simply entered the public IP address of my SIP server for the routing, and everything works correctly... the incoming INVITE requests say "sip:MYDID@MYIPADDRESS". Asterisk then uses "MYDID" as the desired extension in my dialplan, and routes the call appropriately. I'd suggest that the OP ask the current SIP provider whether they handle (2) i.e. whether it's possible for different DIDs associated with a single account to have different information in the INVITE requests sent to the registered client. -- _ -- 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] problems inserting dahdi modules using Debian Leni
> FATAL: Error inserting dahdi (/lib/modules/2.6.26-2-686/dahdi/dahdi.ko): > Unknown symbol in module, or unknown parameter (see dmesg) > [25991.968325] dahdi: no symbol version for crc_ccitt_table > [25991.968330] dahdi: Unknown symbol crc_ccitt_table I think the message "no symbol version for crc_ccitt_table" may be the key here. It's possible (and fairly common) for Linux kernels and modules to be compiled using an option which explicitly adds some "version number" information to each symbol which is imported or exported. The "symbol version" information identifies the exact version of the kernel which was built, or against which a module was compiled. This is done in order to provide some assurance that the implementations in the kernel (used by the module) are exactly those against which the module was compiled. It helps prevent situations in which a module which was compiled against (e.g.) an older version of the kernel, isn't loaded and run in the environment of a newer kernel versions whose APIs or data structures have changed in an incompatible way. The use of this versioning feature is optional... you can use it or not... but you have to make sure that you either enable it in *both* the kernel and module compile environments, or in *neither*. I think that modprobe/insmod is complaining that you have not followed this rule. One of the two builds (either the kernel, or dahdi) was compiled using kernel versioning, and the other was not. You'll have to restore consistency to your compilation environments, before you can produce a dahdi module which will load. -- _ -- 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] [headset/mic] Volume too low + echo in * (Gilles)
> > Different brand/model, but similar as they are both el cheapo, > entry-level headsets. I tried using them on a laptop, and I get > marginally better microphone output, even with its volume cranked all > the way up + automatic gain control enabled. > > I guess those on-board soundcards by Realtek aren't as good as a > quality microphones. I'll get a USB headset instead and see how it > goes. It does sound as if the mic-input gain is too low for those headsets. > Right after the connexion is made between the PC with the headset and > a Siemens IP phone located on the same LAN. Both are using SIP. It's > light, but a bit noticeable. I'll try again with a USB headset and see > if it goes away. Hmmm. The traditional cause of echo on analog phone lines is the presence of impedance mismatches... the electrical signal "reflects" when it hits a point where the impedance of the transmission line changes, and returns to the origin (where it is heard as an echo). This situation really shouldn't exist at all, in the digital stages of transmission (i.e. between the SIP endpoints). The causes would have to lie elsewhere. One source of echo I've observed on SIP calls in the past is purely acoustic... cheap handsets/headsets. It's possible for acoustic feedback to occur within such a device... the microphone picks up a fraction of the sound being generated by the speaker/earpiece, and is transmitted back towards the point of origin. I had this problem with a cheap little USB handset I use here at work... its case is mostly hollow, and channeled sound from the speaker to the mic. When I called my wife and home she complained of hearing her voice echoing. I opened the handset, stuffed the open areas with cotton wadding, and added a few small pieces of left-over car-door-damping sticky-sheet to the inside of the case. Problem gone - no more echo. So, once again, you may be having a headset/handset-related problem! > I noticed, something, though: While I only kept G11u on both the XLite > and Siemens, I noticed that sound coming from the Siemens contains > some reverb when running Asterisk (1.4.4) on an Atcom appliance > (www.atcom.cn/IP01.html), while the reverb is gone when running > Asterisk (1.6.2.5) on a regular PC with Ubuntu. I guess codecs sound a > bit different depending on what hardware they're running on. That's odd... the U-law codec is about as simple and deterministic as it gets, and really shouldn't have an effect on any echo behavior. Is it possible that "silence detection" settings were different in these cases? If a phone endpoint was configured to detect "silence" and stop sending RTP audio packets, it could have the side effect of suppressing low-level acoustic echo occurring within the phone handset/headset, since the level of this would fall below the silence-detection threshold. > Thanks much for the education :-) Quite welcome! -- _ -- 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] [headset/mic] Volume too low + echo in *
> I'm having the following problem when using a headset on XP > connected to an on-board Realtek soundcard on an AsusTek M2N68-AM Plus > motherboard: > > - Using any sound recorder (Windows', Audacity, XLite), the level is > just too low when speaking at a conversational level, even with the > microphone level pumped all the way up (line displayed totally flat in > Recorder) > http://img704.imageshack.us/img704/7981/headsetlowvolumeecho.jpg > > - In addition, when making a call with XLite and Asterisk, I get a bit > of echo > > - Same issues when trying with a different headset Same headset model, or different headset model? > > - Enabling "Auto gain control AGC" in XLite makes no difference. > > Any idea what can be done? Should I use a different soundcard? > Amplified headset? Most computer mic inputs these days, are designed to work with mics and headsets using electret microphone elements. These microphone elements normally have a built-in FET buffer/amplifier, and have a respectably high audio output level. The FET amplifier requires some DC power to operate; this is normally provided by the sound card, as a resistor-coupled DC voltage applied to the mic input pin inside the jack (it's usually in the 3-9 volt range). Some headsets use "dynamic" (electromagnetic) microphones... essentially little loudspeakers operated in reverse. These do not require DC power from the sound card to operate, but they have a significantly lower audio output level. They do require amplification in order to drive an input designed for electret microphones. Some sound cards have mic inputs which are switchable... the DC power feature can be enabled or disabled, and there's a "gain boost" setting which switches in a preamplifier stage (often around 10-20 dB) for use with a dynamic mic. You may be attempting to use a headset with a dynamic mic, with a sound card whose mic input was intended only for use with electret mics and doesn't have a preamplifier. If this is the case, switching to a headset with an electret mic and its built-in FET buffer-amp would probably be your easiest solution. If that's what you mean when you refer to an "amplified headset", then yes, that's probably what you should do. You wouldn't need a headset with a separate amplifier-box... the FET amplifier is usually build right into the microphone element. It's also possible you have a bad PC sound interface... try using a different PC with the same headset(s) and see if the problem persists. You can probably buy or build a preamp for your existing headset (I recently built one for a similar purpose) but considering how inexpensive "A/V" comm/gaming headsets are these days it's certainly cheaper to buy one. Another option would be to buy a USB-connected headset... these have all of the necessary gain electronics in them, as well as a "USB sound card" chip. There's only one plug to plug in, and (once the necessary USB sound drivers are installed) you could be confident of having the same sound level and quality on any PC into which you plug it. >Can something be done in Asterisk about the echo? How quickly after you speak, do you hear the echo? Is it near-instantaneous, or significantly delayed? What's your outgoing voice connection (SIP, IAX, or an actual hardwired phone line with some sort of terminal adapter)? Does the caller at the far end hear an echo from what s/he says? Or does the echo affect only you? -- _ -- 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] TCP port, VPN and resolving the cutting voice problem
> I know understand the latency due to the resending .. But if the link was > have a good speed internet, then resending will make a big latency? > > Maybe this latency better than having a cutting voice? Fundamentally, TCP's congestion-avoidance and loss-recovery logic simply won't work well with voice, unless you're willing to accept a really horrendous latency (hundreds of milliseconds) and then perhaps not even then. TCP is designed to ensure reliable data delivery and reasonable network efficiency (i.e. avoiding congestion and avoiding an excessive number of retransmissions) and is simply not well suited for isochronous (or close-to-isochronous) data streams such as VoIP. > What if we reduce the packet size and make it TCP, so resending might cause > acceptable delay? > > But again, what about running IAX in TCP port, this is possible? Sure, it is *possible*. I don't think anyone has implemented it, because everyone who might is probably pretty well aware that it would not work well. > Any other solution to resolve the cutting in the voice while others doing > download and browsing? I'd recommend the following general approach (not my own ideas, just ones I've adopted from other peoples' recommendations): - Deliberately "throttle" both inbound and outbound TCP connections, so that they do not consume all of your link bandwidth. Set aside some amount of the link bandwidth for VoIP traffic (SIP or IAX2) traveling over UDP. For outbound traffic, what you need is a rate-limiting traffic shaper which supports multiple queues. Linux can do this with its advanced traffic shaping modules. For inbound traffic, what you need to do is prevent the sending TCP stack (at the far end) from being able to queue up and transmit an excessively large amount of traffic. Since you have no *direct* control over the remote systems, you have to do it indirectly... and the way you do it is by "input policing". This simply means that when incoming TCP packets start consuming more than a specific percentage of your inbound bandwidth, you start dropping them... artificially creating a "lost packet" error, which then causes the sending system to reduce its transmit window and enter a congestion-avoidance process. This also can be done using the Linux traffic-shaping modules. - Prioritize the packets you send, with VoIP packets being transmitted before TCP packets. This can be done using a combination of traffic-shaping modules (to set up and prioritize the queues and set their transmit rates) and iptables (which can be used to mark VoIP packets as needing expedited delivery). Take a look at http://lartc.org/howto/ - it's a complex subject but a well-designed traffic shaping configuration can have really excellent benefits. -- _ -- 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 Asterix right tool for me?
> Hi , > I am a newbie with Asterix and not sure if Asterix is a right tool for my > needs. > > Let's suppose this scenario : > I have a telephone line in one office( all calls are paid to telephone > operator). > In other offices I have only internet connections. > Is it possible to use Asterix so that I can make telephone calls from ALL > offices( without > direct telecom connection) ? if so, what telephone equipment would they have > to use (VoIP > telephones?) Yes, indeed, Asterisk can give you this capability. There are several different approaches which can be used - which one you choose will depend on your needs. You'll need to equip your office users with VoIP telephones. These can be either dedicated IP-capable phones (usually running the "SIP" voice protocols), or "softphone" software packages running on their PCs (again, implementing SIP). Dedicated "hard" IP phones can be had for anywhere from $50 on up. Softphone programs range from completely free to significant amount of money, depending on what capabilities you want. Simple ones will emulate a one-line phone (often with a built-in contact list and autodialer) while more complex ones can emulate a multi-line business phone. You would probably want to equip each PC with a handset or headset of some sort rather than depending on the built- in microphone and speaker. USB-connected handsets are widely available; they're usually marketed as being for Skype, but most of them simply register as USB audio devices and will thus work with almost any soft-phone. You'll want at least one system running Asterisk, to act as the "hub" for your offices. If you have a large number of users in a particular office, and if they will wish to phone one another within the office or working region, it may make sense to place an Asterisk server in that office so that phone-to-phone traffic stays within the office and doesn't have to travel over the public Internet... this will reduce voice latency (delay) and perhaps reduce your Internet bandwidth costs. Each "hard" or "soft" IP phone will register with one of the Asterisk servers, so that it can receive calls through that server. Urgent advice: assign each such phone a unique, difficult-to-guess username (*not* just the extension number you are planning to assign to it) and assign it a *very* difficult- to-guess "secret" (password). Long, randomly-generated strings of letters, digits, and symbols make the best secrets. You *really* do not want somebody from outside your system to be able to guess a phone's username and password, or they'll be able to make calls overseas for which *you* will be financially responsible (this can be a *very* expensive problem if you don't take care!) As to getting back onto the PSTN (public switched telephone network), there are several different approaches you can take. As others have suggested, the best is probably to purchase a SIP account from one of the many different VoIP providers available. Prices, services, and quality vary. You'll probably be best off picking one which is known to provide good service in your area, and has an Internet-to-PSTN interchange switch close to you (network-wise). This SIP provider can do two things for you: - They can accept outbound SIP calls from your Asterisk server (and/or directly from your IP phones) and route these calls onto the PSTN. This is what you'll want to do, in order to allow your offices that have only Internet connections to make phone calls. - They can provide you with any number of PSTN phone numbers, (in your own country or elsewhere) and route calls to these numbers to your Asterisk server. Phones in your Internet-connected offices could make calls out to the PSTN via any of several methods: - They could place calls directly to the SIP provider's servers. This would have the least latency and overhead, but the worst security problems (every phone would have to have an authorized account with the provider, or share a single outbound account and secret... not a good idea). - They could register with, and then place calls through your organization's main (or only) Asterisk server. The server can restrict call destinations on a per-phone basis if necessary, provide centralized logging, etc. - Offices which have their own Asterisk server, could place calls through that server and out to the SIP provider, rather than going through the main company server. This would provide somewhat better delay and call quality in many cases, and still give you a limited number of somewhat-centralized servers which would manage call security and authorization. -- _ -- 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 UNSUB
Re: [asterisk-users] TDM 400p and Noise on the line
> Hi > > I wonder if anyone has any sugestions > > > I have had a TDM400 for a couple of years, and I have always had problems > with noise on the line, so tonight I have been doing some research and have > found that if I load the CPU dahdi_test has almost perfect results and no > noise > > dahdi_test > Opened pseudo dahdi interface, measuring accuracy... > 99.997% 99.999% 99.998% 99.997% 99.999% 99.998% 99.998% 99.998% > 99.998% 99.998% 99.998% 99.997% 99.998% 99.997% 99.998% 99.998% > 99.998% 99.998% 99.998% 99.997% 99.999% 99.998% 99.998% 99.997% > 99.998% > --- Results after 25 passes --- > Best: 99.999 -- Worst: 99.997 -- Average: 99.997895, Difference: 100.002028 > > > > but when the CPU is not loaded there is white noise low volume and the > results of dahdi_test > > dahdi_test > Opened pseudo dahdi interface, measuring accuracy... > 99.992% 99.988% 99.951% 99.991% 99.992% 99.992% 99.992% 99.992% > 99.991% 99.991% 99.992% 99.991% 99.991% 99.952% 99.992% 99.992% > 99.992% 99.992% 99.951% 99.992% 99.992% 99.992% 99.992% 99.950% > 99.991% 99.991% 99.991% 99.992% 99.992% 99.951% 99.992% 99.992% > 99.992% 99.991% 99.952% 99.992% 99.992% 99.991% 99.992% 99.951% > 99.991% > --- Results after 41 passes --- > Best: 99.992 -- Worst: 99.950 -- Average: 99.984461, Difference: 100.001168 > > > Could you explain how I can improve the call quality without running the > CPU at 99% al the time? > > running the latest Dahdi 2.4.0 Echo Canceller: OSLEC and asterisk 1.6.2.13 I suspect that you might be seeing some effect of the CPU going into, and out of an IDLE state... possibly due to the use of the HLT instruction in the kernel's idle loop, or possibly due to the ACPI BIOS (or the operating system "cpufreq" support code) changing the CPU clock rate or voltage. These sorts of changes in processor state might have several sorts of effects on the TDM400P card and the audio it is processing: - Changes in processor state (e.g. core voltage or clock speed) can cause a brief interrupting in processing... the CPU instruction processing must sometimes be halted in order to allow the clock PLL to re-lock at a different rate and for the core voltage to stabilize. This might possibly be adding enough latency to interrupt service time to affect the card (e.g. losing some audio samples), or skewing the timing enough that OSLEC's echo cancelling algorithms exhibit different behavior. - Changes in the amount of power being drawn by the CPU, when it goes from flat-out processing to idle, can be quite substantial in modern CPUs. Some of today's multi-core CPUs dissipate on the order of 100 watts during full-speed processing but drop down far below that when idle. The amount of current being drawn by the processor will cause changes in the voltage on the motherboard's +12 and +5 supply lines, and these voltage changes are likely to reach the TDM400P. If the TDM400P doesn't have good on-board voltage regulation and noise filtering (and I suspect that it might not), then some of the voltage noise on the supply rails could leak into the audio. Similar problems exist with many PC on-the-motherboard audio interfaces. As to how to fix it? Well, you're going to have to experiment. The first thing I'd suggest trying, would be to see if you can disable any sort of ACPI- or kernel-based "power saving" adjustment of the CPU's clock speed and core voltage. This might involve disabling SpeedStep (or the equivalent) in the BIOS, or switching Linux from using the "ondemand" power governor to a single-speed one (either "performance" or "powersave" or "usermode"). Possibly, running Asterisk at a real-time priority might reduce the issue, if it's timing-related. If it's simply a matter of noise on the power rails, you may not be able to get rid of it at all easily... might have to change motherboards, power supplies, or switch to an external phone interface device which is inherently immune to electrical noise within the PC chassis. -- _ -- 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 1.62.13 - CPU spikes every 10 minutes
For what it's worth... I also observed an unusually high level of CPU activity on my small (home-system) Asterisk installation, shortly after I switched to 1.6.2.13. The pattern in my case was (as best as I could tell) a CPU load of 2% to 10%, pulsing upwards every few seconds. I couldn't resolve it any more finely than that, at the time I saw it. This is a very small Asterisk install (just two or three SIP extensions registered at the time, no calls in progress, no significant activity noted on the net interfaces at the time), running on an Atom N270 CPU system. I am using the "internal_timing = yes" option (pthreads timing rather than dahdi). I did a "core restart when convenient", Asterisk restarted, and the CPU load dropped to negligible levels. It has remained low ever since (about 7 minutes of CPU used, over the space of a couple of days). I have a hunch that in 1.6.2.13, some resource isn't being cleaned up properly after calls terminate or extensions de-register, and that the system is spending a significant amount of time "chasing its tail" navigating through these obsolete resources. Just a hunch, though... nothing to back this up. -- _ -- 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] OpenVPN tunnel and one-way audio - Do I still need a SIP proxy? (bruce bruce)
> I don't think it's an endpoint issue. I think the SIP packet headers get > over-written by the tunnel (openvpn) protocol. I'd be rather astonished if OpenVPN itself were responsible for this. As far as I know, OpenVPN doesn't do higher-level-protocol rewriting of any sort. It just provides the "bit pipe" through the tunnel. I'd suggest several other possible culprits: (1) Server B might be doing higher-level protocol rewriting (i.e. SIP border gateway stuff) prior to routing the SIP packets through the OpenVPN tunnel. This might happen if Server B were configured to use the Linux "iptables" features, with a SIP protocol module and Network Address Translation features. The fix would be to disable NAT and boundary processing in Server B's routing functions. (2) The SIP endpoints (phones) might be configured to "discover their external address", via STUN or a similar mechanism. The fix would be to change the endpoint device configuration. I think you'll need to use Wireshark or a similar sniffer, to see what the SIP traffic looks like at several points along the path, so you can locate the earliest point at which the wrong address is in the SIP packet payload. Several examination points come to mind: - Right after the packet leaves the endpoint device. I'd suggest using a laptop running Wireshark as a passive packet sniffer... connect the endpoint device and the laptop to an Ethernet hub (not a switch!) and sniff the packets before any router gets its hands on them. - As the packets enter Server B - use Wireshark on Server B and have it tap into the incoming Ethernet interface. - As the packets are pushed out of Server B's routing layer into the OpenVPN tunnel. Use Wireshark to monitor the "tap" or "tun" virtual interface, to which the kernel transmits the packets that OpenVPN is to convey. - As the packets come out of the tap/tun device on Server A. In scenario (1) I described above, you'd see the packets be correct at the first and second Wireshark sniffing points, and incorrect at the third and fourth (i.e. the modifications are being performed in Server B's routing/NAT'ing layer). In Scenario (2), they'd be incorrect at every point, including just after they come out of the IP-phone. In the scenario you described, they'd be correct at the first, second, and third points, and wrong at the fourth. -- _ -- 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] What can make G.729a codec hostid change?
> Yes. Just the lone integrated NIC that's always been there. NO hardware > changes. Still eth0 with the same MAC address. Do you have any additional, "soft" network interfaces defined? For example, have you enabled OpenVPN, and thus loaded either the "tap" or "tun" network-interface drivers? Do you have an IPv6-over-IPv4 tunnel defined (and thus loaded the "sit" driver)? Note that "ifconfig" will not necessarily show all of your interfaces (hard- or soft-) - only the active, configured ones. Take a look at /proc/net/dev and see if anything shows up, which ought not to. Also, check the "ifconfig" for each interface, and see if the HwAddr is exactly what you would expect. It's conceivable that your network driver changed, and is (for some reason) reporting a longer hardware address string (e.g. one padded with zeros). -- _ -- 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] MAC Address prefixes of Voip equipment
> Is there a database of MAC address prefixes used the common VoIP > devices. I see the Linksys Sipura devices state with 00:0E. > > Does the same apply to other Linksys VoIP equipment? The Ethernet prefixes ("OUIs") are three octets long. Linksys / Cisco has been assigned a number of OUIs, one of which is 00-0E-08. You can download the current list of OUIs from the following URL: http://standards.ieee.org/regauth/oui/oui.txt I don't know whether Linksys/Cisco uses this particular OUI only for VoIP devices, or for a whole range of device types... I suspect the latter. > Is there some way VoIP equipment allow themselves to be identified by > requesting data from some ports? If you have a SIP dialog going with the equipment, you may find that it sends either "Server:" or "User-Agent:" headers with some amount of useful information. -- _ -- 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 stop intruder from registering sip?
> That would only be true if you used random characters in your 17-character > passphrase. In fact, English text has somewhere between 0.6 and 1.5 bits of > randomness per letter, whereas an SHA1sum has no more than 4 bits of > randomness per letter. Let's assume the higher number of randomness for > your English text, which gives us 1.5 * 17, which is 25.5 bits of randomness. > Note that the prefix 3 characters have ZERO randomness per character, as they > are deterministic from the extension. That gives an even less 21 bits of > randomness. SHA1 cryptographic sums have no more than 160 bits of randomness. > > I say "no more than", because, given knowledge of the algorithm used to > determine passwords, the sum is reduced to the number of bits of randomness in > the source material. You cannot generate randomness by applying a > deterministic algorithm. However, given that the source material for the hash > sum is of a smaller bit strength than the comparative strength of the hash > algorithm, your difficulty of guessing the password is not reduced any by > using the hash algorithm for generative purposes. Agreed, on all points. Any deterministic method of this sort (e.g. hashing together the extension name with a constant-per-site salt) is vulnerable to a brute-force guessing attack against the salt. If the person who set it up used a ordinary, easily-remembered phrase as the salt, then the security of *all* of the secrets is tied to the guessability of this phrase. Brute-force dictionary attacks against plain-language words and phrases have been quite successful in the past... I've heard it said that on any multi-user system having more than a handful of users, the odds of one of those users having a guessable password are often 50% or better. I'm not in favor of using this sort of deterministic scheme (e.g. HASH(salt + public info)) for determining per-station secrets, no matter which hash algorithm is used. Instead, I recommend the scheme I originally proposed - use a random- number generator (or a cryptographically-string pseudorandom generator, fed with some entropy from an external unpredictable source) to generate individual secrets. I make three arguments: - The resulting secrets (i.e. strings of hexadecimal digits) are equally hard, or equally easy, for the end-users to deal with (assuming that we're talking about equal numbers of digits). Neither scheme has an advantage here. - Once set up, both systems are equally easy to use and administer... press a button and generate a secret. - The random- or pseudo-random method produces secrets which don't depend at all on the extension numbers (or user names, or other public information), are independent from one another, and are essentially immune to dictionary and other guessing attacks. The only way to break them is via a full brute-force search... and successfully finding one extension's secret by brute-force search doesn't help you at all in finding any other extension's. Assuming a good random-number generator, the amount of entropy (randomness) in the secrets is essentially equal to (2 ^ number-of-bits). None of these things is true of a deterministic-hashing scheme... if the salt can be guessed or determined, *every* extension's secret has been broken, and you have to immediately change *every* configuration in order to secure your system. Salts based on dictionary words and phrases have far less randomness in them than their length would imply, and that means that the resulting secrets are less random... generating longer "secret" strings doesn't fix this, and can simply give a false sense of security. - -- _ -- 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] one for your filters
> I'm still trying to figure that out. Our SIP usernames are seven digit > phone numbers, so not really difficult to guess, but the passwords are 7 > char alpha-numeric strings, auto generated. We don't at present restrict > people to their addresses, as some are dynamic. If the extension in question is one that is normally accessed via a SIP soft-phone of some sort, you should check the PC(s) on which this softphone is run for any sort of malware infection. There have been more than a few malware packages (viruses or trojans) which contain payloads that search the compromised system for various forms of authorization credentials. It's possible that this extension's password wasn't cracked by brute force, but was stolen from the soft-phone configuration file on a user's PC. -- _ -- 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] one for your filters
> I'm still trying to figure that out. Our SIP usernames are seven digit > phone numbers, so not really difficult to guess, but the passwords are 7 > char alpha-numeric strings, auto generated. We don't at present restrict > people to their addresses, as some are dynamic. If they're randomly generated (which might not be the same as "auto generated") then that *ought* to be a big enough namespace to provide reasonable resistance to cracking... 78 billion combinations at least (assuming upper-case alpha and numeric characters). Do your logs show a lot of failed registrations? A brute- force password-guessing attack ought to show up in this way (and is thus good fodder for a Fail2Ban auto-jailing). You should check your Asterisk configuration to make triple-sure that: (1) Inbound "guest" calls go only to a restrictive context which will allow calling of only your own specific extensions, and (2) You don't have DISA enabled on any extension... a short DISA passcode and a guessable DISA extension number could be an expensive vulnerability. -- _ -- 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 stop intruder from registering sip?
> As I mentioned, I'm not inclined to mess with the secrets, too much > hassle for users. I'm afraid that I have to consider that attitude to be a bit like saying "It's too much hassle for us to insist that our employees lock their desk drawers and the front door... or wash their hands after going to the bathroom... or cover their mouths when they sneeze. Oh, yeah, we keep the combination to the corporate safe on a yellow sticky-note on the bulletin board, so that anyone who forgets it can figure it out quickly." There are ways to make stronger secrets easier to work with. One method creates secret phrases by concatenating a bunch of randomly-chosen dictionary words. If you have enough such words in the dictionary you can create phrases which have enough randomness to survive brute-force attacks but which aren't too difficult to type in correctly. For example, such a gibberish-generator might output fizzy.basal.nerfy.dogma.colma.flinx It's your choice... but these basic security principles about setting secrets/passwords have the fruits of many peoples' expen$ive experience at the high cost of *not* doing things properly. If the cost of doing things securely is that you have to spend a few minutes of IT-guru time setting up each user's phone or softphone, or need to write a document-generator which prints out step-by-step instructions for each user with the necessary user-name and secret included... it could be a *very* good investment. > That's why I'm considering deny/permit. > Does that solve my problem? *Only* if you have complete physical control over *every* network on which those phones will be used, *and* all of your employees are completely trustworthy. It's really no solution at all if you need to have "road warriors" using soft-phones on networks across the world, since you won't be able to deny IP addresses meaningfully in that case. All it would take would be one such employee using a softphone via an insecure network (e.g. open WiFi access point), somebody sniffs the protocol and sees the registration and records the extension number and then does a brute-force secret-guessing attack. Boom. You're out hundreds or thousands of dollars of calling costs before you can react. Scammers can use your SIP system to make calls to "premium" phone numbers that cost several dollars per minute... and the scammer may well get a portion of this revenue. Big companies have ended up losing tens of thousands of dollars to this sort of attack against their PBX systems. Or, worse... your SIP secrets end up in the hands of a cybergang which starts using your system for criminal activities (e.g. drug-trafficing, making scam calls to homeowners, etc.), and you find your company facing investigation by law enforcement, or your SIP provider cuts you off due to abuse complaints. The secondary cost of either of these to your business could be severe. As Dirty Harry said, "How lucky do you feel?". You've already been hit once. > But I'm struck with your notion of having sip user ids different from > extensions. That would not require any user effort, or messing with each > phone. But... > > We use a combo of aastra 9133i and 57i's. Don't the user id and the > extension HAVE to be the same? I had thought the aastra's used the > extension as the SIP id to register. By no means - at least, not in the 9133i, and I'd be surprised if the 57i had that requirement. Look in the Administration manual for the 9133i, Appendix A, "SIP Basic, Global Settings", "SIP Global Authentication". This is where you can set the "authentication name" and "sip password", which are what the phone uses to register with the server (e.g. the SIP user name and secret). Make this name *different* from the extension name, and provide a good secret. You can also set the "SIP display name", which is what shows up on the screen, and is sent as the "From" field in the SIP protocol. You can set this to the user's primary extension number. A bit further down, there are per-line registration fields which do the same thing for individual line-presence buttons... screen name (also used for From:), user name (for SIP registration), password (SIP registration secret). -- _ -- 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 stop intruder from registering sip?
> If you leave your asterisk box open to the world with passwords like > you deserve to be hacked.. Well, without making a moral judgment, I will agree that you are *going* to be hacked if you do this! The O.P. seems to have made two (fairly common) mistakes: - Used a "secret" so obvious that it could be guessed... and even if not, so short that it could have been determined by a very simple brute-force attack. - Used the user's extension number as the SIP user ID... and thus making it easy to figure out which user IDs on which a password attack could be carried out. Doing a brute-force SIP-registration attack against all possible 3- and 4-digit extensions, using a handful of obvious "secret" strings ( through , 1234, 4321, same number as the extension) wouldn't take an attacker very long at all. Nor would trying to call all of these numbers once to figure out which extensions exist, then doing a brute-force password attack against those which exist. I have no doubt that there are numerous crackers out on the net doing just these sorts of attacks on a regular basis. The cure for these problems is, obviously, "don't do that": (1) SIP user IDs should not be based on the extension number, and preferably should not be based on the owner's name or user login. Make 'em hard to guess or brute-force! (2) Make the secrets equally hard to guess or brute-force. No short strings of numbers, no dictionary words or simple leet-speak transforms of them, etc. One of your best tools is a program or script to generate random sequences of letters and digits and other legal- in-SIP-names characters. Try something like dd if=/dev/urandom bs=512 count=1 | base64 and then copy some 10- or 12-character substrings out of this mass of gibberish and use 'em for SIP secrets. With this many bits of randomness in the secrets, they'll be effectively invulnerable to guessing or brute force attacks. > Are your travelling people using softphones? If they are VPN would be a good > idea.. A very good idea, and not just for security reasons. Running SIP over a VPN tunnel can be a very effective remedy for all sorts of firewall- and NAT-related problems. I've found that running OpenVPN between my various SIP clients, and my Asterisk server, produces far better results than depending on STUN or on SIP-aware routers and firewalls. -- _ -- 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 1.6 and OpenVPN RTP problem
> Thank you for your reply. > > > The first proposed solution has resolved the problem for a test in the local > network. Another test is planned today later with a client in the same NAT > and another in the public internet with a public static ip address. > > Do you have any advice for that case? That case should work out fine if you've specified "directmedia=no" for the client(s) on the NAT/OpenVPN side, as long as the Asterisk server has a public IP address. Asterisk will forward the RTP between the client on the public Internet, and the client on the OpenVPN tunnel. You won't need to have a routable connection directly between the two clients. I run my own setup this way. All clients on my home LAN, and my OpenVPN'ed mobile (Nokia N810) specify "directmedia=no". I can make calls (RTP both ways, no trouble) between them, between one of them and a client on the public Internet, and between them and various VoIP providers' systems. Using OpenVPN, and depending on Asterisk to forward the RTP, seems to be a *lot* more reliable than trying to do direct SIP/RTP and depending on STUN or SIP-aware NAT gateways. -- _ -- 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 1.6 and OpenVPN RTP problem
> Hello All, > > I have installed Asterisk 1.6 with openVPN in the same machine. I have set > up a VPN connection between 2 SIP clients and Asterisk using x-lite. > > The 2 clients connects to Asterisk. SIP signaling goes ok over the vpn > tunnel. > > When attempting to make a call between the clients, the siganling part of > the call goes well. But, when the call is set up, some RTP packets are > exchanged at the beginning and then the RTP flow stops (no RTP is exchangd). > > Wireshark demonstrates no problem with SIP signaling. > > I am using OpenVPN 2.1.1. > > Has anyone had such a problem. I had a vaguely-similar problem, getting a Nokia N810's Telepathy- based SIP client to talk to Asterisk over an OpenVPN connection. The problem in that case turned out to be the fact that the Nokia was sending all of the packets to the Asterisk server, using its primary-network (WiFi) IP address, rather than the address to which its end of the OpenVPN tunnel was bound. The SIP packets from the Asterisk server had no way to get back to the client. The fix for this was to stick a couple of scripts into the Nokia, to be executed when OpenVPN started or stopped the VPN tunnel. The "up" script changes the SIP configuration, setting its "local IP address" parameter to that of the Nokia end of the tunnel, while the "down" script clears this override. Works fine. That doesn't sound like exactly the problem you're having, though, since you're getting SIP through the tunnel OK. The problem sounds more as if the RTP packets from one client are either not being send through the tunnel at all, or are being dropped prior to getting to the other. There may be a couple of ways to fix this: (1) As another poster suggested, specify "canreinvite=no" (or, in 1.6, "directmedia=no") for each of your SIP clients. This will prevent them from trying to send the RTP "directly" to one another, instead sending it to Asterisk for forwarding. This is probably the most reliable approach. It's also probably the only one which will allow reliable connections between these clients, and SIP endpoints which aren't part of your own local IP-address space. (2) If you really do want to try to allow directmedia connections between the clients, you'll need to make certain of two things: [A] Your OpenVPN setup, for each client, must install a route on each client which directs the client to send all packets for any address on the entire VPN back to the VPN server. Without such a route being installed, it's likely that the OpenVPN-installed routing would only channel packets for the OpenVPN server itself into the tunnel. Packets for other IP addresses in the OpenVPN range would end up being sent out through the client's normal IP route, and probably lost forever in the grand stew of the Intertube. [B] Make sure that your OpenVPN setup allows direct client-to- client communications. There's a parameter which can disable this, and permits only client-to-server packets to survive... make sure you haven't set this. (3) You may need to make sure that your iptables (or similar) configuration isn't accidentally NAT'ing packets which are trying to come in through the OpenVPN tunnel and then go back out through another OpenVPN tunnel. -- _ -- 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] OpenVPN on phones?
> Anyway - is there someone out there that know the behaviour of OpenVPN in > regards of retransmits and such? A VPN that retransmits will at some point > hurt you if you transmit media over it, especially if you scale it up. OpenVPN is well-behaved in that way. It uses SSL over TCP for its "administrative" communications between peers - authentication and key exchange and other protocol negotiations. The VPN traffic itself - the payload - isn't sent over TCP. Instead, the incoming packets are tagged, encrypted, and transmitted via UDP, on the usual best-efforts basis. OpenVPN will not, itself, retransmit those payload packets. It's up to the endpoint protocols to do so, if they so choose. I've had quite good luck carrying SIP traffic over OpenVPN... used it between a hotel in Norway, and my home in California, a couple of weeks ago, Even with the hotel end of the connection being over WiFi, I didn't notice any significant packet loss problems. -- _ -- 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] odd issue with the with SIP over VPN
> I've run into a odd issue where inbound calls to the SIP client work > fine, but outbound from the SIP client do not. > > The path between the client and the server is as below. > > N900 SIP client <-- OpenVPN --> Asterisk > > The version of Asterisk in question is 1.6.0.18. > > Any suggestions? You may have run into a problem I've encountered with the SIP client in the N810, or something related to it. One of the complexities/weaknesses of the SIP protocol, is that each SIP node puts its own IP address into the protocol packets it sends to its peer. The peer uses this IP address (embedded in the SIP headers) rather than the IP address in the actual IP headers, to manage the conversation. This means that each SIP peer needs to know what IP address to announce and it has to be an IP address which is usable to the peer, or the protocol won't work. The SIP client on the N810 (and the N900 I imagine) will, under normal circumstances, *always* specify the IP address of the main IP interface (wireless). This happens even if the call is being routed through a VPN. Or, if you have STUN support turned on, it may specify whatever IP address the system deduces is the "visible" public IP address of whatever NAT it's living behind. Neither of these IP addresses is likely to be usable, if the conversation is taking place through a VPN. What you probably want, in this case, is for the SIP packets to contain the N900's VPN endpoint address. The Maemo SIP client doesn't know how to do this, at least not without assistance. Fortunately, it's possible to assist the client, via some scripts or push-commands in your OpenVPN configuration. The methods differ a bit depending on whether one is running OS 2008 (Diablo) on the N810, or Fremantle on the N900, but the principle is the same. See https://bugs.maemo.org/show_bug.cgi?id=1860 for a discussion of the problem, and for some sample scripts. I've been using this approach with my N180, and (via manual configuration) with a Linux laptop with OpenVPN and Twinkle. It works fine, and seems more reliable than trying to use STUN. -- _ -- 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 throws error using the alsa, module
> this i got from syslog: > > puppy:~# grep pulse /var/log/syslog | tail -3 > Dec 14 20:32:45 puppy pulseaudio[25967]: main.c: Unable to contact D-Bus: > org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch > terminated abnormally without any error message > Dec 14 20:32:46 puppy pulseaudio[25967]: alsa-source.c: > snd_pcm_mmap_commit: The device or resource is busy > Dec 14 20:39:11 puppy pulseaudio[26368]: main.c: Unable to contact D-Bus: > org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch > terminated abnormally without any error message > > > Hmmm, since aplay / arecord are working fine - is it maybe that asterisk > wants to lock the soundcard exclusively? That would be the case if the ALSA device you were trying to use was "hw:" or "plughw", since these access the hardware directly. By using a PCM device of "pulse" you ought to be preventing Asterisk from attempting to open the sound card directly (either exclusively or shared). Instead, it should be directing the audio I/O through a network/socket connection to the pulseaudio server. Two further thoughts: [1] According to what I've read, pulseaudio requires that all users who are going to be using it must belong to a special user-group. If the user-ID under which you are running the Asterisk server isn't a member of this group, then I think that attempts by Asterisk to connect to the pulseaudio server might very well fail. Check /etc/group, and see if you need to add the pulseaudio group to the definition for your Asterisk daemon user-ID. [2] Are you by any chance running Asterisk in a chroot'ed jail? If so, it may not be able to find some of the programs or sockets that it requires. ___ -- 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 throws error using the alsa, module
>> See if it plays back properly. > > Running aplay as asterisk user seems to be no problem: > > aster...@puppy$ aplay /usr/share/sounds/alsa/Front_Center.wav > Playing: WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit > Little Endian, Rate: 48000 Hz, mono > aster...@puppy:~$ aplay -Dpulse /usr/share/sounds/alsa/Front_Center.wav > Wiedergabe: WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit > Little Endian, Rate: 48000 Hz, mono > aster...@puppy:~$ aplay -Ddefault /usr/share/sounds/alsa/Front_Center.wav > Wiedergabe: WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit > Little Endian, Rate: 48000 Hz, mono > > pulseaudio spawns itself as it should: > > aster...@puppy:~$ ps -A | grep pulse > 23820 ?00:00:00 pulseaudio > > > this works as defined in /etc/asound.conf: > > aster...@puppy:~$ cat /etc/asound.conf > pcm.pulse { > type pulse > } > > ctl.pulse { > type pulse > } > > pcm.!default { > type pulse > } > > ctl.!default { > type pulse > } I haven't used pulseaudio myself, nor the ALSA plugin to redirect audio through it. I infer that by default you're routing ALSA connections through the pulseaudio plugin/connector, and that the pulseaudio daemon has been configured to send its output to a different ALSA device (e.g. to hw: or plughw:)? Best I can suggest, at this point, is that you check to see whether you can turn on some sort of debugging in the pulseaudio daemon, to see what sort of connections it's receiving from clients, and what it's doing with them. It's possible that there's some sort of access-permission problem in pulseaudio and it's refusing to allow connections from asterisk for some reason. > > i've acticated the alsa plugin for asterisk: > > puppy:/etc/asterisk# grep -E 'alsa|oss' modules.conf > load => chan_alsa.so > noload => chan_oss.so > > puppy:/etc/asterisk# grep default alsa.conf > input_device=default > output_device=default Might try setting these to "pulse" rather than "default", perhaps? > i'm running pulseaudio on top of alsa. through setting /etc/asound.conf as > above any calls to alsa should be redirected to pulseaudio (at least that's > what i thought). > Asterisk Ready. > *CLI> console dial s > *CLI> [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read > error: Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [Dec 14 02:12:36] ERROR[24945]: chan_alsa.c:456 alsa_read: Read error: > Input/output error > [repeated indefinitely until killed] Hmmm. Since these are occurring when reading a channel, it indicates that it's the attempt to read audio from pulseaudio which isn't working. Have you confirmed that pulseaudio is in fact working correctly in both directions (using e.g. both aplay and arecord)? ___ -- 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 throws error using the alsa module
> [Dec 8 18:24:48] ERROR[10571]: chan_alsa.c:693 alsa_read: Read error: Resource temporarily unavailable I agree, this looks like some form of conflict for the sound device. The first thing I'd suggest doing, is trying to reproduce the error with a command-line tool, with asterisk out of the loop entirely. You'd use a command such as aplay -D default /path/to/demo-congrats.wav See if it plays back properly. A "resource temporarily unavailable" error from ALSA would tend to suggest one of two sorts of conflicts: [1] A low-level (e.g. IRQ) conflict for the sound device itself. This could occur as a result of motherboard misconfiguration... for example, if the sound card/chip was configured to use IRQ 2 or 3, and there was also a serial port in use which made use of this interrupt. Check (e.g.) /proc/interrupts to see if you can find such a conflict. [2] A higher-level conflict for use of the sound card, e.g. between two different (and incompatible) ALSA accesses, or between a "native" ALSA access and a user of ALSA's OSS driver- or library-level API emulation. One not-uncommon culprit is having an X Window desktop up and running. Some of the newer desktop packages have their own sound-management architecture (e.g. ESD, the Enlightenment Sound Daemon, or the JACK audio toolkit, or PulseAudio). These management systems often open the underlying sound device (in a non-shared mode) and then provide their own APIs for arbitrating access, mixing multiple outputs together, etc., and a separate "native" ALSA access from Asterisk will often be unable to share access to the card. When doing "native" ALSA access, it's often possible to share access to the sound card (playing back two or more sounds simultaneously). Some sound cards have this capability in hardware. Many do not... and for those that do not, you can resolve the conflict by telling all of the playback apps to use the "dmix" plugin. This is a software mixer... it opens the underlying sound-card PCM output in an exclusive- access mode, and then accepts connections from any number of ALSA clients and mixes the audio together before sending it to the sound card. The trick about "dmix" is that *all* of the clients have to agree to use it. If the first client to open the sound card doesn't use dmix (but opens the default hardware device directly), then any further clients (dmix or otherwise) will be locked out. Similarly, if "dmix" is in use. any attempt by an ALSA client to access the hardware directly will probably be rejected (unless the hardware itself can do the mixing for it). On older versions of ALSA, it's necessary to specify the "dmix" device manually e.g. aplay -D dmix /foo/bar/baz.wav On some more recent versions of ALSA, using the "default" device will give you the hardware device directly *if* the hardware can handling mixing... and will give you the "dmix" device otherwise. Any sound client which is manually configured to access the hardware directly (via e.g. "hw:") or the direct rate-and-format-conversion plugin (e.g. "plughw") will not be going through the "dmix" plugin. ___ -- 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] SIP source address error
> It's set to bind to 0.0.0.0, which IIRC is nothing strange. > > The question remains: how can a remote Asterisk server be receiving > SIP packets that still contain the private net IP address of a client? It sounds to me as if the client hasn't been told to use its gateway's public IP address in the SIP conversation, and as if the client isn't sending its outbound packets through a gateway/NAT which is SIP-aware and can rewrite the SIP data accordingly. There are several approaches which can work: - The gateway is properly configured to forward its external ports to the client, and the client is manually configured to use the gateway's external IP address in its SIP protocol exchanges. - The gateway does port forwarding and NAT properly, and is also SIP-aware - it intercepts and rewrites the contents of the outbound SIP packets, changing the IP address and port given by the client to its own IP address and whatever external port it has NAT'ed / redirected to the client. - The gateway does port forwarding and NAT properly, and the client is configured to use STUN to figure out what public IP address/port its packets are being NAT'ed to. - The client doesn't talk directly to the outside peers, but goes through a SIP proxy running on the gateway. In your case, it sounds as if the client and gateway aren't doing one of these things. As a result, the client's SIP protocol packets still contain its private-net IP and port, at the time they reach the remote server. ___ -- 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] OT - How to organize TFTP root directory ?
> Great idea ! > I didn't know it could be possible to run several instances of xinetd, each > binded to a specific IP address. > Is this specific to xinetd or does openbsd-inetd also support this feature ? > Anyway, I'll check this in openbsd-inetd doc myself and (hopefully) report > my findings here. xinetd will let you do multiple bindings of a single port, with a single instance of xinetd running. You would define two service entries in the config file, with the same service name, different ids (e.g. "tftp1" and "tftp2"), and different "bind" addresses (one for each interface). Each service entry would then run a different server program, or the same server program with different server_args. As far as I know, standard BSD (and Linux) inetd doesn't have this capability. ___ -- 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] New thread - SIP over VPN
>> Isn't an SSL based tunnel all TCP? > Not in the case of OpenVPN. I'm not sure about the commercial > offerings. Correct. My recollection is that OpenSSL uses TCP for the setup and management of the tunnel (e.g. authentication and key exchange) and uses UDP to carry the actual payload... each tunneled IP packet is wrapped in a UDP datagram. That way, the UDP transport "mimics" the basic characteristics of normal IP transport - it's best-efforts, order not guaranteed, and no built-in retries. The number of lost (or out-of-order) packets in such a tunneled connection shouldn't be significantly different than what you'd see if you weren't using a tunnel at all. There seems to be a good deal of feeling (and evidence) that trying to use TCP as the container for a tunnel is likely to cause more trouble than it solves. Yes, the TCP layer will make the tunnel "reliable" - but at the expense of adding unpredictable amounts of latency, due to TCP's built-in exponential-backoff retry timing. Things get *really* nasty if you try to wrap one TCP connection in another, because both connections will be independently retrying any lost or delayed packets - you'll end up retransmitting quite a bit more data than you would if you simply used TCP/IP (or TCP/IP wrapped in UDP/IP) and throughput will suffer. I've been using an OpenSSL tunnel to connect my Nokia N810 internet tablet to my Asterisk server, for about a year now. It works very nicely, eliminating NAT- related problems (no need to STUN) and allowing me to use VoIP from most WiFi networks I can log onto. ___ -- 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] IPKall and FWD
> Searching their "support" forum, posted today is the fact they are > discontinuing any VM The message saying that they are discontinuing their offering of voicemail was posted on August 24, 2007 - two years ago. That doesn't seem to be a new issue. ___ -- 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] Echo and static on PRI with errors
> Could someone tell me how to set which IRQ the ISDN card picks up? It's a multi-stage process. Each PCI slot has four interrupt pins: INTA through INTD. A PCI card can choose to use any of these four (or even more than one of them, as some multi-port serial cards do). Most PCI cards use only one pin: usually INTA. The motherboard routes four interrupt lines between the pins in the slots it provides. The motherboard usually does *not* route a line to the same pin on all slots... for example, INTA on slot 1 might be routed to INTB on slot 2 and INTC on slot 3, and then back to INTA on slot 4. This "mix 'em up" routing is done to help compensate for the fact that most PCI cards use only INTA - it keeps all the cards from pounding on the same interrupt line. This is also why one way to move a PCI card to a different IRQ, is to move it to a different slot. The motherboard must then route the interrupt lines to one or more IRQs. On "classic" PCI motherboards, with traditional PC interrupt controllers, there are only a very limited number of IRQs available (up through IRQ15) and many of these IRQs have dedicated functions and cannot be shared (e.g. any IRQ assigned to an ISA device can't be shared). As a result, these motherboards tend to route multiple PCI interrupts to only one or two IRQs - as in your case, where a whole boatload of things are being routed to IRQ11. On these traditional motherboards, all of the IRQ routing is under the control of the BIOS. Hence, the second way to un-burden IRQ11 would be to change your BIOS settings (as previously suggested). You would want to disable any unused devices - in particular, any IRQ-using ISA devices such as the parallel and serial ports - and mark these IRQs as "available, not reserved for ISA". A good BIOS would then change the PCI-INT-to-IRQ routing and spread out the interrupt load. Unfortunately, it sounds as if the HP BIOS is of the "Father Knows Best" variety, and won't let you control your settings. Unless you can find an "expert" menu, or a separate configuration program for the BIOS data (sometimes vendors make a DOS or self-booting program available, rather than putting the full BIOS configuration in the BIOS itself) you're stuck here. There's a third possibility: APIC, the "Advanced Programmable Interrupt Controller". This is a newer interrupt-controller architecture, present on SMP systems and on many modern uniprocessor systems. It provides the hardware and the OS with much more flexibility, and with quite a few additional IRQ numbers not supported by the traditional controller. You could try building a custom Linux kernel for your system, using a current stable kernel version (a 2.6 spin, at the moment). Enable APIC support, including the "APIC on uniprocessor" and "local APIC" support features. Boot this kernel, do an lspci -v, and see where your various cards and devices end up IRQ'ing. You may find that the APIC support has allowed the kernel to map these devices onto a wider range of IRQ numbers than previously. Unfortunately even this approach may not help on some motherboards. If the vendor has wired all of the INTA pins on the slots to the same line, and has also used this same line for the interrupts from the internal (non-slotted) PCI devices, then you'd be completely out of luck - it would be physically impossible to distribute the interrupts from these devices to different IRQs. My guess is that your biggest conflict is between the PRI card, and the network interfaces, since both are likely to be generators of lots of interrupts. Ugh... I just noticed something else... it looks as if the motherboard in question is using at least one PCI-to-PCI bridge: 81:01.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface Note the bus number: 81 hex. I think that this means that the card is sitting on the far side of a bridge chip... these are often used if a system has more PCI devices or slots than a single bus can support. I've had some bad experiences with bridged PCI systems in the past - some bridge chips seem to add quite a bit of latency to PCI bus access, or reduce bus throughput by quite a lot. Apparently the individual read and write transactions through the bridge suffer from a significant per-transaction overhead. I wonder whether IRQ latency/delay might not also be a problem here, or whether the bridge architecture might be forcing interrupts from some cards to use a single line/IRQ. ___ -- 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] QoS & VPN
> I would think that VoIP over VPN is a bad idea as UDP packets need to be > in realtime not corrected by the TCP of the VPN. That depends very much on the VPN in use. OpenVPN doesn't suffer from this problem. Although it's SSL-based (and one might think it does everything through SSL-over-TCP), it actually sends the VPN traffic via UDP... it uses TCP only for the negotiation and administrative aspects of setting up the VPN connection. As far as I know, OpenVPN makes no attempt at all to re-order the packets that it encapsulates and transmits. It simply accepts the IP packets it is to carry, encrypts them individually, wraps them in UDP, and retransmits them to its peer. The peer receives the UDP, decrypts, and forwards. No re-ordering. There may be other VPNs which actually carry all of the VPN'ed data in a single TCP stream... but I think this is generally agreed to be a Bad Idea for several reasons. I run SIP over OpenVPN between my Nokia N810 handheld, and my Asterisk server at home. I have not noticed any difference in call quality between SIP-over-OpenVPN, and non-VPN'ed SIP, between these two endpoints... except, of course, when the OpenVPN-encapsulated traffic gets through, and non-VPN'ed traffic doesn't due to firewall or NATing problems at a particular wireless network access point. ___ -- 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-users Digest, Vol 58, Issue 17
> BTW, can someone explain to a libart major like me (;-)) where echo > comes on in a telephone conversation? I seem to recall it's due to the > length of the line between the CO and the local party, but I'm not > sure. I'll try. Echo occurs when part of the signal traveling in one direction on the phone line, is reflected back in the opposite direction. It's similar (in effect) to the echo you hear when you speak in a large room, and your voice reflects from a wall... but it's occurring in the electrical domain rather than in the air-pressure domain. It's also similar to the way in which radar detects the presence of an airplane, by bouncing a high-frequency radio signal off of the plane. A signal reflection can occur whenever a signal, which is traveling through a transmission medium (air, wires, etc.) encounters an impedance change. In the case of a spoken echo, the impedance change is between the air (whose molecules move fairly easily in response to sound pressure) and the wall (whose molecules are bound together, and thus form a "stiff" material). In the case of radar, it occurs when the radio pulse tries to move from free space, into the metal surface of the plane. In the case of a phone connection, the echo occurs when the incoming electrical signal (e.g. from the CO) reaches the end of the phone wire (which has a certain characteristic impedance) and tries to move into the receiver circuitry (the telephone, or the line card in an Asterisk system). In each of these cases, if there's a difference in impedance between the transmission medium, and the "termination" (whatever is at the end of the medium), only a portion of the incoming signal flows into the termination. The other portion of it is reflected back towards its origin - an echo of one sort or another. In the case of an Asterisk line card with a mismatched impedance, the person calling into the Asterisk system will hear a significant echo ("far-end echo" from their point of view). The spacing of the echo (between the time they speak, and the time they hear themselves in the echo) will depend on the length of the phone path between you and them... signals in the phone line travel at less than the speed of light. Far-end delay over satellite phone links can be very obvious! Echo can also occur in the other direction... the audio signal being sent out by the Asterisk system can reflect right back into the card (partially, at least) the moment it hits the different impedance in the phone line - a "near-end echo". Eliminating the echo can be done in a couple of ways. The most thorough way is to exactly match the impedances involved (e.g. match the line card to the line impedance) so that there is no tendency to reflect. If that's not possible, it's possible to analyze the echo behavior and use DSP to cancel it out... e.g. you can prevent your system from generating a far-end echo that the other guy hears, by sampling his incoming audio signal (what you receive), and deliberately retransmit a small amount of it... just enough (and with the right phasing relationship) to cancel out the portion of his signal which is reflecting off of your line card's impedance discontinuity. > Is there a way to keep track of this issue, and overtime, to configure > it to answer a call by expecting such and such echo, and thus, avoid > starting sampling from scratch every time? To some extent, yes, I believe it's possible at least in part. If you can measure the extent and character of the near-end echo being created in signals you transmit, you can calculate the nature of the impedance discontinuity and figure out what you need to transmit to compensate for it, and thus prevent the generation of echo. If the line characteristics change, though, you may have to start over again, or adapt your current behavior. Canceling out far-end echo (from anything beyond your own CO) is a different matter, because it's likely to be different on every call you make. ___ -- 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] Is there a public blacklist of hackers' IPaddresses?
> SIP was written in such a way that the hashes it sends for passwords > could, with only a trivial rewrite of the server code, be SHA1 instead > of MD5 -- which would increase security to the level that, currently, it > would be far more trouble than it's worth to even bother to attempt to > crack. I strongly doubt that the known weaknesses in the MD5 hash are the "weak point" in SIP account security. Weak passwords are almost certainly much more of a problem. Performing a dictionary attack is going to be a lot faster than attempting a brute-force mathematical attack against MD5... and switching from MD5 to SHA-1 provides no significant defense against dictionary attacks. The only good way to keep passwords secure against dictionary attacks, is to make sure that the passwords aren't guessable by that means... no common words, no names, no simple permutations or birthdates or anything like that. Use a decent random-number generator and number-to-character conversion algorithm to generate SIP passwords that are sufficiently long and very dtr8fbwf_==...@\.-+!n$ and you'll be well defended. ___ -- 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] life safety system and VOIP
> In Florida some new subdivision developers have sold the > phone/cable/internet rights to a provider. They run fiber to each house > and then have the uplink to provider which isn't a traditional telco. > You can't get another provider as satellite dishes are limited in > covenants and restrictions (CCR). Those CC&Rs may very well be legally void and unenforceable. Some years ago, Congress passed legislation which affirms the right of individuals to install over-the-air television antennas, satellite-TV antennas, and "fixed wireless" antennas, in areas of their property which (1) they own, or (2) they lease or rent, and which are part of their "exclusive use" areas. The "exclusive use" phrasing covers areas like private patios, private walkways, balconies, and some roofs and exterior walls - the latter depends on the actual business arrangement). The wording which explicitly permits antennas for "fixed wireless signals" says specifically that it includes wireless signals for telephone service or high-speed Internet service. Local and state zoning regulations, rental agreements, and CC&Rs which forbid the installation of antennas under these conditions are null and void. They cannot be legally enforced. These sorts of rules cannot even be used to require installation in ways which substantially increase the cost of an installation. There are *some* situations under which such CC&Rs can be enforced. For example, they can prohibit installation of antennas in "shared" areas of a building structure (e.g. the roof of a townhome complex, if the roof is considered common property of the townhome membership association). This is sometimes a problem in practice - e.g. an apartment dweller located on the north side of a building may not have any spot in her apartment which has a clear view of the satellites in the south sky. Same problem with wireless internet service - if you don't have a clear path to the provider's antenna site you may not be able to get a usable signal. As I understand it, the whole idea behind this legislation was to prevent landlords from signing "sweetheart deals" with specific telco and cable providers, and thus locking their tenants into a specific provider. Congress apparently felt that competition, and consumer freedom of choice, was in the better public interest. See http://www.fcc.gov/mb/facts/otard.html for details. ___ -- 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] WiFi SIP phone w/VPN?
> Hi, all. My subject line says it all: is there a WiFi SIP phone with VPN > abilities? Failing that, a WiFi phone that runs Linux? I already know > one phone that does meet my requirements -- the iPhone. The new software > comes with a Cisco VPN client, and a SIP client can be had from > third-party vendors for jailbroken phones. And, while I'm not averse to > the idea, > a) it ain't cheap, and > b) it's a bit hack. > > I've googled my heart out, but haven't found anything else that (I'm sure) > meets all three requirements. The Nokia N810 "internet tablet" might fit your requirements. It runs Linux, much of the software kit is open-source, it has WiFi, it has a built-in SIP phone application, and it has an OpenVPN client available. The SIP phone app will support multiple SIP accounts. I use mine fairly regularly to connect with my home Asterisk server when in restaurants and stores that have WiFi access for their customers. The use of the OpenVPN connection makes life *much* simpler, as the VPN can successfully create a tunnel through most NAT routers, and doesn't require STUN support. I have two different account definitions on my N810 - one for my own Asterisk server (via the tunnel) and another which registers directly with my telco origination provider. The latter will establish a more direct connection when I dial out onto the PSTN (since the traffic doesn't go through my home-DSL line twice) but is somewhat less certain to work at any given wireless site (since it's dependent on STUN and on the settings of that site's firewall/router). Getting the OpenVPN/SIP setup working requires a bit of fiddling, as it's not straightforward: - You must add one or two additional Maemo software repositories to the Application Manager, - You must use the "blue pill" mode of the installer to add OpenVPN to the system (install the OpenSSH or Dropbear SSH client and server at the same time) - You must create your OpenVPN certs on your OpenVPN server and then download them to the N810 and install them in the right directories. - Accessing the Asterisk server via the OpenVPN tunnel requires changing the SIP-phone account definition via a shell command line tool, to force the SIP phone to use the tunnel's IP address rather than that of whatever WiFi connection you are using at the time. Fortunately, this can be done automagically when the tunnel starts up, via some "up" and "down" shell scripts... I can provide samples upon request. - If your OpenVPN tunnel doesn't terminate on the same machine that runs your Asterisk server, you may need a SIP proxy running on the tunnel-termination server. I wouldn't have bought the N810 for use solely as a WiFi phone, but having this feature added to an otherwise-very-useful lightweight Internet access device / GPS is extremely handy. ___ -- 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] VPN and Asterisk
> One of my user was asking, can he use VPN to access asterisk ? > What does it mean ? > > And its possible ? > > How ?VPN Yes, it's possible. As one example: I have the OpenVPN software installed on my Asterisk server, and on my Nokia N810 wireless Internet tablet. The tablet is configured to use the VPN's server-side IP address as its SIP server. A similar sort of system could be set up with other VPN packages (e.g. CIPE, Cisco's offerings, etc.), This approach has several advantages, compared to the alternative (not using a VPN, and turning on STUN support in the client): - All of the SIP and RTP traffic to/from the tablet is encrypted, and thus relatively resistant to evesdropping. - The tablet and the Asterisk server have IP addresses for each other which are being established by the VPN software, and don't need to be (and aren't) altered or translated by access-point or corporate routers. This pretty much eliminates the common "I can't get audio in one or both directions" problem with using SIP through private IP networks and NAT routers. - Most network firewalls will pass VPN traffic, even if they haven't been configured to pass "raw" SIP and RTP. There are some disadvantages, though: - Some amount of CPU overhead at both ends, and perhaps some increased latency (the latter is minor, I believe). - The RTP traffic must flow through the VPN/Asterisk server... it cannot be "reinvited" into a direct connection between the tablet and the destination, because the tablet is using an IP address for the connection which exists only on the VPN and isn't externally reachable. This sort of VPN setup (where the Asterisk client is on the same system that's running the VPN software) is the one you'd want to use for many "road warrior" setups. VPNs can also be used to set up secure IP tunnels between two different, remotely-located networks. This might be done to tie together (e.g.) two different offices, each having its own Asterisk server. ___ -- 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
> I may be over simplifying but I would have a serial number object that > gets incremented anytime it is called and will be set to 0 at start-up. > I would then use it to generate a UUID like this: > MAC.serialid.64bit timedate I suggest reviewing RFC 4122, which discusses UUID formats in some detail. Your suggestion is very close to a standard "version 1" UUID, which includes the host's MAC address, 60 bits of time information, and a 14-bit "clock sequence value" (which is set randomly at startup, and incremented if the system clock value is adjusted forwards or backwards or if the node ID changes). The time value has a 100-nanosecond resolution, which sets a lower limit to the amount of time which may be allowed to pass between UUID generation events. By my math this field won't wrap until after the year 5,000 C.E., so we have a while to prepare for the "Y5237" wraparound problem :-) ___ -- 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] lock SIP Account after too many failed logins
>> I want to detect brute-force password hacking attacks - thus if there >> are too many failed login attempts for a SIP account I want to "lock" >> this account. > >> Does somebody have any ideas how this could be implemented? The usual method (I think) is to monitor the log files, and detect repeated patterns of suspicious actions occurring within a given period of time. A program such as logwatch (www.logwatch.org) might work, or you could write something in Perl. If you're logging via syslog, you can have syslog write new messages into a pipe as well as into a log file, and thus parse and evaluate new messages immediately with no buffering delay. > Bad plan? Could quite easily turn into a DoS. If the reaction is to lock the account, I agree, it might leave you prone to a denial-of-service attack. A better way would be to use iptables to start dropping packets from the IP address(es) involved in the attack... this will still allow the legitimate user of the account to access it. The block-IP-address-only method won't defend effectively against a "slow scan" botnet-based crack attempt, where each password-guessing attempt comes from a different IP address in the botnet. A lot of current SSH password-guess probes are of this sort. I don't think there's any terribly good defense against this except to select *good* passwords - e.g. 20 or more alphanumeric characters selected by a good random-number generator. To be pro-active, I'd suggest that you acquire a password quality-evaluation program (the Perl Data::Password class from CPAN might be a useful starting point) and check the password quality of all of your SIP accounts. Require a password change for any password of unacceptably low quality. ___ -- 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] SIP to IAX2 with delayed echo
> Coming from outside the network, setting up for a couple rounds of > NATting isn't going to work well. They are not seeing it between > phones. Others, using the polycom phones have reported echo between two > SIP on a 4ms ping trip. Could this be due to a purely acoustic echo within the Polycom handsets? I encountered a nasty echo / hollow sound when using a cheap USB "telephone" to connect to my Asterisk system (via KPhoneSI). The echoing was due to acoustic feedback - the handset body acted as a very nice channel for sound waves from the back side of the speaker down to the microphone cartridge. I opened up the handset, added some damping materials (panel- vibration-damping and soft-foam sheeting, left over from a car stereo speaker installation I did), closed it back up, and the echoing was gone. You might not notice in some calls, if the Polycom phones have silence-detection turned on for those calls and if the amount of feedback falls below the phones' silence threshold. If the phone silence-detection algorithm were turned off on other calls, the echo would then be audible. ___ -- 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] FWD $30 membership-fee
> I just received an email notice from FWD about $30 membership fee. > My question: Is the email genuine? Did anybody else receive it? > > I'm just trying to be sure that it is real and not a scam. > The (FWD) does not do anything to authenticate such emails (implementing > GPG/PGP signature etc.) > > If the email is genuine, I hope they will improve their service; as of now > their IAX server is not working. I received the same email. It was sent to a tagged email address that I had used only when signing up for FWD last month, and never gave to anyone else. It seems to have been sent out through a mass-mailing service (MagnetMail)... they feel slightly on the "this might possibly be an outfit whose service could be used for spamming" side of things but are not overtly crooked or bogus as far as I can tell. My guess is that the email is probably legitimate. Although there's nothing new on the FWD website to confirm that free accounts are going away (as the email implies), the statements in the email seem consistent with the info on the FWD website about a "re-launch" and "spin-off". Any service such as FWD is going to need a source of revenue in order to keep their servers running. I don't think FWD ever got around to launching an FWD-based "dial out onto the PSTN" service with a per-minute charge from which they could earn revenue... and the VOIP market for such things seems to be extremely competitive and perhaps cut-throat. Since FWD seems to be spinning off and will need independent revenue, they're likely to have to do *something* to keep the lights on! The interesting thing will be to see if people find it worthwhile to pay $30/year, primarily for a SIP registration service that doesn't provide either outdial-to-PSTN or indial-from-PSTN. If not, FWD might cease to exist. If the email is legit, I do think that FWD really ought to update their web site Real Soon Now, to reflect that the services now available "for free" will no longer be free. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 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] TOS and security
> I'm preparing for a client install of * by doing a fresh one in-house. > Unlike my earlier installation that runs asterisk as superuser, my > current experimental box runs without such privilege. This is causing > it to moan that it can't set TOS. I absolutely don't want to install it > on the client LAN without this capability. If need be, I'll set the > binary to run setuid root. > > But I'm looking for something more elegant. While googling, I found a > suggestion to use iptables mangle rules to set TOS for all packets going > out of the box on ports like 5060 and 1:2. Not a bad hack, but > indiscriminate and this box will be handling other traffic besides the > RTP. I'd like to do better. It is possible for an iptables filter/rule to match packets in the OUTPUT chain based on the UID or GID of the process which created them, if you have the "owner" module loaded. You should be able to add a rule to the OUTPUT chain of the mangle table which will set the TOS properly for any and all outbound packets generated locally by the non-root user ID which you're using to run Asterisk. Come to think of it, I think I need to do this myself. I'm using the "ultimate Linux traffic conditioning" configuration (modified very slightly) to prioritize my system's outbound traffic into multiple queues by TOS, and it's probably mis-queueing the RTP traffic because my Debian install of Asterisk is running under a non-root UID. > I thought of using POSIX access control to enable asterisk to do TOS > setting without being root (would this be CAP_NET_RAW?), which sounds > perfect, but so far I'm operating with stock ubuntu hardy, and I would > like to avoid a kernel build to add this capability. > > Any other ideas? Seems like "iptables -t mangle -A OUTPUT -m owner --uid-owner $ASTERISK" would be along the lines of what you want? Mark the packets with the TOS you want... and then consider using the Linux traffic-shaping system to make sure that they really do get transmitted ahead of non-urgent packets: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.ultimate-tc.html ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 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
[asterisk-users] Delaying SIP disconnect after incoming call hangs up?
I'm looking for a way to delay the disconnection of a call to a SIP extension (or pad it with silence) for a few seconds, after an incoming call to that extension hangs up. Rationale: I have an Asterisk PBX (current 1.4.20 codebase), with a Leadtek BVP8051S ATA hooked to an analog phone which has a built-in answering machine. Incoming SIP connections to the appropriate extension are dialed to this SIP ATA, the phone rings, and the answering machine picks up... all as it should be. However, when the caller hangs up, the ATA immediately starts generating a fast-busy disconnect/congestion beeping. The answering machine doesn't recognize this as a hang-up situation (it expects to hear the line go silent) and it keeps recording beeps until its message-length timer expires and it hangs up the line to the ATA. Unfortunately, I can't change the answering machine's behavior, and I don't think it's possible to change the Leadtek BAP8051S to just go silent. So, what I'm hoping, is that there is some way within Asterisk to change the PBX behavior when the incoming call disconnects, so that it can defer sending the disconnect event to the SIP extension for 10 or 15 seconds... enough "quiet time" for the answering machine to recognize end-of-call and hang up. I think that either sending nothing (no RTP stream) to the SIP extension, or sending "silence" or "comfort noise" frames, would work fine. I've looked through the documentation and through a fair bit of the source code, and haven't found anything which actually works. I tried adding an "h" hangup rule to the dialplan for this extension, with a Wait(10) action, but this seemed to have no effect. Either the "h" rule isn't working, or the disconnect frame has already been processed and a SIP BYE has been sent. I've only been able to figure out one approach which *may* work... use an "h" hangup rule for the extension, which runs a DeadAGI() script, which contacts the SIP ATA via its http administrative interface and reboots the ATA (which immediately drops the line). This may very well work, but is about as elegant as a bag-full of wet tree sloths, and I'd like to do a better job than this. Is there any provision in Asterisk for being able to "catch" the hangup/disconnect of the far end of a connection, and either wait (with no activity) for a fixed period of time, or do the equivalent of a Play() to send the contents of an audio file to the remaining extension (the target of the Dial() in the extension dialplan)? Currently, the SIP extension in question is behind a NAT, and I've set "canreinvite=no", so I believe that all of the SIP and RTP traffic is going through Asterisk. It seems to me that it *ought* to be possible for Asterisk to catch the end-of- connection situation and react in some way other than immediately disconnecting the receiving SIP peer, but I'm not sure that any such capability has been implemented. I realize that the outside-the-box answer to this would be "Why use an answering machine? Use the PBX voicemail!" but that's not entirely desirable in this situation. Since the phone / answering machine is analog, it has no "message waiting" light available to let us know that a call has come in, and we'd also lose the ability to "jump onto" a call which is in the process of being recorded. My wife is comfortable with how the existing answering machine system works, and I'd rather present her with an IP-based solution which doesn't change the behavior she's used to... she's not the most technophilic person around. Thanks in advance for any ideas you can throw my way! ___ -- 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