Re: [asterisk-users] recording not working to NFS

[Dave Platt]

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

[Dave Platt]

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

[Dave Platt]

>> 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

[Dave Platt]

> 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

[Dave Platt]

> 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 ?

[Dave Platt]

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)

[Dave Platt]

> 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

[Dave Platt]

>>> 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

[Dave Platt]

> 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/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

[Dave Platt]

> 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)

[Dave Platt]

>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

[Dave Platt]

> 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

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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: xx...@sedwards.com, 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

[Dave Platt]

 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 ?

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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?

[Dave Platt]

 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)

[Dave Platt]

 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

[Dave Platt]

  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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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:

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

  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

[Dave Platt]

 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

[Dave Platt]

 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: 1Is 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.

2How 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

[Dave Platt]

 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] Asterisk on Debian Lenny with timerfd

[Dave Platt]

 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] context problem

[Dave Platt]

 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] [headset/mic] Volume too low + echo in * (Gilles)

[Dave Platt]

 
 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 *

[Dave Platt]

   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

[Dave Platt]

 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?

[Dave Platt]

 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 UNSUBSCRIBE or update options 

Re: [asterisk-users] TDM 400p and Noise on the line

[Dave Platt]

 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] OpenVPN tunnel and one-way audio - Do I still need a SIP proxy? (bruce bruce)

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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] one for your filters

[Dave Platt]

 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] How to stop intruder from registering sip?

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 [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

[Dave Platt]

 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 ?

[Dave Platt]

 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

[Dave Platt]

  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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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?

[Dave Platt]

 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

[Dave Platt]

 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 CCRs 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 CCRs
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 CCRs 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?

[Dave Platt]

 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

[Dave Platt]

 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] lock SIP Account after too many failed logins

[Dave Platt]

 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] Simple CDRs

[Dave Platt]

 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] SIP to IAX2 with delayed echo

[Dave Platt]

 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

[Dave Platt]

 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

[Dave Platt]

 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?

[Dave Platt]

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