Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-11-01 Thread C F

Seems to me that you have a routing problem, asterisk should not know
how to send packets to an outside IP using the NATed network. Make
sure that the internal (NAT) interface doesn't have a gateway to it.

On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote:


I've read a lot of the descriptions of handling NAT with Asterisk,
and the use of both the nat and canreinvite flags.  I am very
familiar with Sip and NAT but have not seen an answer to the following
question.


My Asterisk server runs on a machine with two ethernets.  One is
an external net, with exposed IP addresses.   The other is an internal
net with natted IP addresses.   Thus the server has two addresses.

The server is _not_ the NAT gateway.  That's a linksys box which has
its own external IP to gateway traffic from the internal natwork.

The phones are on the internal NATwork.   Asterisk talks to them over
it.   Outside peers, such as SIP termination providers etc. talk
to the Asterisk server via its outside address, which is as you
would expect.

However, from time to time I get the famous one-way audio because
Asterisk has decided to do a native bridge between a natted SIP
phone and an external SIP peer.   It sends the internal IP of
the SIP phone in the SDP and of course the outside service can't
send packets to that.

I could just turn off reinvites on the internal phones, but this
would cause them to route all traffic through the asterisk box,
even on internal calls between phones on the same ethernet, which
seems foolish to me.   I don't want to turn off reinvites to the
external peers -- if a call comes in from a SIP originator for example,
and is send back out to a SIP terminator (call forwarding) I want
a native bridge for sure.(Handling the internal traffic is not
so much of a burden though sometimes I hear latency because of it, but
routing external traffic through the asterisk box is a bad thing.)

So what I want is for Asterisk to use native bridges when connecting
two channels behind the NAT, or two channels on the real internet, but
not to do so when connecting an internal and external channel.

It should be able to see the IP addresses, and know the difference between
natted and external ones and know they can't talk to one another.
(The ICE protocol would handle this someday.)

Is IAX smarter about this?

Of course I might even want to get smarter about this.  Is it possible,
typically by configuring stun in the phones, to have them be aware of their
external IP and tell Asterisk about it?  With a full cone NAT, it would
work to do a native bridge between the internal and external devices
so long as the external device is given the right address and port of
the NAT box, not the internal address of the phone.   However, we don't
want to do this on internal to internal calls -- many NATs can't hairpin.


I would think this would be a common situation (though perhaps more
commonly the asterisk server IS the firewall/NAT.)   Is there a
solution that does the right thing most of the time?
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-11-01 Thread C F

Sorry for my previous post I misunderstood the problem.
You should set canreinvite=no to all sip peers that connect from outside.

On 10/31/06, C F [EMAIL PROTECTED] wrote:

Seems to me that you have a routing problem, asterisk should not know
how to send packets to an outside IP using the NATed network. Make
sure that the internal (NAT) interface doesn't have a gateway to it.

On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote:

 I've read a lot of the descriptions of handling NAT with Asterisk,
 and the use of both the nat and canreinvite flags.  I am very
 familiar with Sip and NAT but have not seen an answer to the following
 question.


 My Asterisk server runs on a machine with two ethernets.  One is
 an external net, with exposed IP addresses.   The other is an internal
 net with natted IP addresses.   Thus the server has two addresses.

 The server is _not_ the NAT gateway.  That's a linksys box which has
 its own external IP to gateway traffic from the internal natwork.

 The phones are on the internal NATwork.   Asterisk talks to them over
 it.   Outside peers, such as SIP termination providers etc. talk
 to the Asterisk server via its outside address, which is as you
 would expect.

 However, from time to time I get the famous one-way audio because
 Asterisk has decided to do a native bridge between a natted SIP
 phone and an external SIP peer.   It sends the internal IP of
 the SIP phone in the SDP and of course the outside service can't
 send packets to that.

 I could just turn off reinvites on the internal phones, but this
 would cause them to route all traffic through the asterisk box,
 even on internal calls between phones on the same ethernet, which
 seems foolish to me.   I don't want to turn off reinvites to the
 external peers -- if a call comes in from a SIP originator for example,
 and is send back out to a SIP terminator (call forwarding) I want
 a native bridge for sure.(Handling the internal traffic is not
 so much of a burden though sometimes I hear latency because of it, but
 routing external traffic through the asterisk box is a bad thing.)

 So what I want is for Asterisk to use native bridges when connecting
 two channels behind the NAT, or two channels on the real internet, but
 not to do so when connecting an internal and external channel.

 It should be able to see the IP addresses, and know the difference between
 natted and external ones and know they can't talk to one another.
 (The ICE protocol would handle this someday.)

 Is IAX smarter about this?

 Of course I might even want to get smarter about this.  Is it possible,
 typically by configuring stun in the phones, to have them be aware of their
 external IP and tell Asterisk about it?  With a full cone NAT, it would
 work to do a native bridge between the internal and external devices
 so long as the external device is given the right address and port of
 the NAT box, not the internal address of the phone.   However, we don't
 want to do this on internal to internal calls -- many NATs can't hairpin.


 I would think this would be a common situation (though perhaps more
 commonly the asterisk server IS the firewall/NAT.)   Is there a
 solution that does the right thing most of the time?
 ___
 --Bandwidth and Colocation provided by Easynews.com --

 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users



___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


[asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Brad Templeton

I've read a lot of the descriptions of handling NAT with Asterisk,
and the use of both the nat and canreinvite flags.  I am very
familiar with Sip and NAT but have not seen an answer to the following
question.


My Asterisk server runs on a machine with two ethernets.  One is
an external net, with exposed IP addresses.   The other is an internal
net with natted IP addresses.   Thus the server has two addresses. 

The server is _not_ the NAT gateway.  That's a linksys box which has
its own external IP to gateway traffic from the internal natwork.

The phones are on the internal NATwork.   Asterisk talks to them over
it.   Outside peers, such as SIP termination providers etc. talk
to the Asterisk server via its outside address, which is as you
would expect.

However, from time to time I get the famous one-way audio because
Asterisk has decided to do a native bridge between a natted SIP
phone and an external SIP peer.   It sends the internal IP of
the SIP phone in the SDP and of course the outside service can't
send packets to that.

I could just turn off reinvites on the internal phones, but this
would cause them to route all traffic through the asterisk box,
even on internal calls between phones on the same ethernet, which
seems foolish to me.   I don't want to turn off reinvites to the
external peers -- if a call comes in from a SIP originator for example,
and is send back out to a SIP terminator (call forwarding) I want
a native bridge for sure.(Handling the internal traffic is not
so much of a burden though sometimes I hear latency because of it, but
routing external traffic through the asterisk box is a bad thing.)

So what I want is for Asterisk to use native bridges when connecting
two channels behind the NAT, or two channels on the real internet, but
not to do so when connecting an internal and external channel.

It should be able to see the IP addresses, and know the difference between
natted and external ones and know they can't talk to one another.
(The ICE protocol would handle this someday.)

Is IAX smarter about this?

Of course I might even want to get smarter about this.  Is it possible,
typically by configuring stun in the phones, to have them be aware of their
external IP and tell Asterisk about it?  With a full cone NAT, it would
work to do a native bridge between the internal and external devices
so long as the external device is given the right address and port of
the NAT box, not the internal address of the phone.   However, we don't
want to do this on internal to internal calls -- many NATs can't hairpin.


I would think this would be a common situation (though perhaps more
commonly the asterisk server IS the firewall/NAT.)   Is there a
solution that does the right thing most of the time?
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Leo Ann Boon

Brad Templeton wrote:

I've read a lot of the descriptions of handling NAT with Asterisk,
and the use of both the nat and canreinvite flags.  I am very
familiar with Sip and NAT but have not seen an answer to the following
question.


My Asterisk server runs on a machine with two ethernets.  One is
an external net, with exposed IP addresses.   The other is an internal
net with natted IP addresses.   Thus the server has two addresses. 


The server is _not_ the NAT gateway.  That's a linksys box which has
its own external IP to gateway traffic from the internal natwork.

The phones are on the internal NATwork.   Asterisk talks to them over
it.   Outside peers, such as SIP termination providers etc. talk
to the Asterisk server via its outside address, which is as you
would expect.

However, from time to time I get the famous one-way audio because
Asterisk has decided to do a native bridge between a natted SIP
phone and an external SIP peer.   It sends the internal IP of
the SIP phone in the SDP and of course the outside service can't
send packets to that.

I could just turn off reinvites on the internal phones, but this
would cause them to route all traffic through the asterisk box,
even on internal calls between phones on the same ethernet, which
seems foolish to me.   I don't want to turn off reinvites to the
external peers -- if a call comes in from a SIP originator for example,
and is send back out to a SIP terminator (call forwarding) I want
a native bridge for sure.(Handling the internal traffic is not
so much of a burden though sometimes I hear latency because of it, but
routing external traffic through the asterisk box is a bad thing.)

So what I want is for Asterisk to use native bridges when connecting
two channels behind the NAT, or two channels on the real internet, but
not to do so when connecting an internal and external channel.

It should be able to see the IP addresses, and know the difference between
natted and external ones and know they can't talk to one another.
(The ICE protocol would handle this someday.)

  

Have you tried setting the externalip and localnet parameters?

Leo

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Brad Templeton
On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote:
   
 Have you tried setting the externalip and localnet parameters?
 
Localnet makes some sense, and is set (should be the default anyway, no?)

externalip, as I understand it, is for an Asterisk which is behind
a NAT.  This asterisk is not behind a NAT to anybody.  The
phones are behind a NAT to the outside world but not to the
Asterisk box, which has two ethernets on it, one for the internal
natwork and one for the real internet.

It uses bindaddr=0.0.0.0 and listens to both addresses.  


 Sorry for my previous post I misunderstood the problem.
 You should set canreinvite=no to all sip peers that connect from outside.


That's precisely what I don't want to do.  This would block native
bridging in the one case where it's most important.


The correct behaviour, as I see it is:

a) Native bridge when connecting two external channels -- everybody is on 
the real internet
b) Native bridge when connecting two internal channels -- everybody is on 
the 192.168.* network
c) Route RTP through Asterisk when connecting internal and external
d) When a channel is to a device behind a remote NAT, the usual rules apply
   (either use STUN or other smart NAT, or route RTP through Asterisk)

The super correct behaviour, which I don't expect but would be nice is

e) Clever native bridge between internal and external by being aware that 
the device
   talks to the outside world using a different address than it talks to 
you.
   (Possibly if the phones use STUN they will tell Asterisk their external 
IP, which
   is not the same as Asterisk's though it's on the same subnet)



I have used localnet=192.168.* and nat=yes on a local device and it still
attempts an incorrect native bridge between internal and external, with
one-way audio.

If I do canreinvite=no on the local devices then it works of course, but
now means the local phones will never native bridge amongst themselves.
In a larger network, that would be a problem, and it's a poor result in any
network.

This is the latest svn of 1.2, by the way.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread C F

On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote:

On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote:
 
 Have you tried setting the externalip and localnet parameters?

Localnet makes some sense, and is set (should be the default anyway, no?)

externalip, as I understand it, is for an Asterisk which is behind
a NAT.  This asterisk is not behind a NAT to anybody.  The
phones are behind a NAT to the outside world but not to the
Asterisk box, which has two ethernets on it, one for the internal
natwork and one for the real internet.

It uses bindaddr=0.0.0.0 and listens to both addresses.


 Sorry for my previous post I misunderstood the problem.
 You should set canreinvite=no to all sip peers that connect from outside.


That's precisely what I don't want to do.  This would block native
bridging in the one case where it's most important.


The correct behaviour, as I see it is:

a) Native bridge when connecting two external channels -- everybody is on 
the real internet


It might not work if one of them is NATed. Therefore the correct way
to do this is to use canreinvite=no


b) Native bridge when connecting two internal channels -- everybody is on 
the 192.168.* network


canreinvite=yes will take care of this.


c) Route RTP through Asterisk when connecting internal and external


Again by adding canreinvite=no to externals you have this.


d) When a channel is to a device behind a remote NAT, the usual rules apply
   (either use STUN or other smart NAT, or route RTP through Asterisk)


How will asterisk know? The correct *setting* (not behavior) is
canreinvite=no for the external devices.



The super correct behaviour, which I don't expect but would be nice is

e) Clever native bridge between internal and external by being aware that 
the device
   talks to the outside world using a different address than it talks to 
you.
   (Possibly if the phones use STUN they will tell Asterisk their external 
IP, which
   is not the same as Asterisk's though it's on the same subnet)



I have used localnet=192.168.* and nat=yes on a local device and it still
attempts an incorrect native bridge between internal and external, with
one-way audio.

If I do canreinvite=no on the local devices then it works of course, but
now means the local phones will never native bridge amongst themselves.
In a larger network, that would be a problem, and it's a poor result in any
network.



Why are you so against having the RTP go thru asterisk?
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Leo Ann Boon

Brad Templeton wrote:

On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote:
  
 
  

Have you tried setting the externalip and localnet parameters?



Localnet makes some sense, and is set (should be the default anyway, no?)
  
I don't think it's set by default. Anyone know how we can see which 
localnets are in use from the CLI? sip show settings doesn't work even 
if I explicitly defined a localnet.

externalip, as I understand it, is for an Asterisk which is behind
a NAT.  This asterisk is not behind a NAT to anybody.  The
phones are behind a NAT to the outside world but not to the
Asterisk box, which has two ethernets on it, one for the internal
natwork and one for the real internet.
  
The way I understand it, externalip and localnet work hand-in-hand. I do 
agree with you that this is commonly used for Asterisk behind a NAT. I 
believe these parameter just helps asterisk determine what to do. In 
your case, you don't lose anything - the external IP would still have to 
be written into every outbound packet.


It uses bindaddr=0.0.0.0 and listens to both addresses.  
  

externalip doesn't affect the bindaddr.

Leo.

___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Brad Templeton
On Tue, Oct 31, 2006 at 04:51:44PM -0500, C F wrote:
 The correct behaviour, as I see it is:
 
 a) Native bridge when connecting two external channels -- everybody is 
 on the real internet
 
 It might not work if one of them is NATed. Therefore the correct way
 to do this is to use canreinvite=no

Of course, if the external peer or user is natted, you would want to
turn on nat and canreinvite=no for such channels.   However, I do not
wish to set canreinvite=no for an external peer like another asterisk
box with an external IP, or a SIP termination provider.

More than do not wish -- this is the most important case.

 
 b) Native bridge when connecting two internal channels -- everybody is 
 on the 192.168.* network
 
 canreinvite=yes will take care of this.

Of course, but the point is that the internal channels (local SIP phones)
are involved in connections to both local phones, and to external peers.
 
 c) Route RTP through Asterisk when connecting internal and external
 
 Again by adding canreinvite=no to externals you have this.

But this defeats the entire purpose.  Here are two situations where you would
most definitely not want to have canreinvite=no

a) Call comes in via SIP origination, and you direct it back out to a PSTN
phone via your SIP termination.   You want the RTP to go directly from
the originating point to the termination point, not to hairpin through
your asterisk box, which would just add latency and eat bandwidth.

b) Click to call APP I have where I connect two PSTN endpoints.  Again,
it's necessary not to hairpin the RTP.

c) Double all this with some advanced providers who, once they figure
where the call is actually being terminated, do their own native bridging
and direct your RTP to the actual PSTN entry point.  There it's possible
to get the RTP to go by the shortest (and lowest latency) path it can.

But not if you hairpin it.
 
 d) When a channel is to a device behind a remote NAT, the usual rules 
 apply
(either use STUN or other smart NAT, or route RTP through Asterisk)
 
 How will asterisk know? The correct *setting* (not behavior) is
 canreinvite=no for the external devices.

I would have to differ.  That's the right setting for external user devices
behind NAT. Do you believe it's correct for devices not behind NAT?

Asterisk can tell if a device is behind NAT if the device has been made
in the last few years, because such devices support a variety of techniques
to inform the server they call that they are behind NAT, and even what
their external IP is if need be.

However, reinvite is not safe with a symmetric nat unless there is really good
cooperation.  So I understand turning off reinvite for any external device
behind NAT.

(Of course a clever box can notice that it sees two devices that have
NAT addresses on the same subnet and both are using the same external
IP.  In that case, it can tell them to send their RTP directly to one
another which is very much the best thing to do.  This allows things
like a branch office using a head office Asterisk server and calls
within the branch staying on the LAN.

This is what the ICE protocol is supposed to solve, of course.)

 
 Why are you so against having the RTP go thru asterisk?

For external connections?  There are a ton of reasons, some outlined above.
An asterisk box with proper use of native bridging can handle a virtually
unlimited number of calls.Put the RTP through it and it can handle only
a modest number, and reduces the quality of those calls significantly.

Having internal calls go through the asterisk box is not as much of a problem,
but I have noticed latencies because of it even on my internal LAN, though I
have not pieced together exactly why, it's almost certainly because of the
RTP bridging.   Which I always get when I call IAX to SIP of course.  It's
not because of load. 

Anyway, my main question is, has anybody figured out how to make Asterisk
do the right thing here.  I am surprised if my configuration is that
unusual.  Having both an internal and external network is pretty common
at a lot of places.   And a server that's on both is, I think, quite common,
so I had not expected this to be a difficult thing to figure out how to do.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time

2006-10-31 Thread Brad Templeton
On Wed, Nov 01, 2006 at 08:10:29AM +0800, Leo Ann Boon wrote:
 Brad Templeton wrote:
   
 The way I understand it, externalip and localnet work hand-in-hand. I do 
 agree with you that this is commonly used for Asterisk behind a NAT. I 
 believe these parameter just helps asterisk determine what to do. In 
 your case, you don't lose anything - the external IP would still have to 
 be written into every outbound packet.

It's called externip I think, not externalip.  I have set both externip
to be my external IP address, and localnet to be the natwork, and even
set canreinvite=no and nat=yes and the SDP I get back from an invite to
[EMAIL PROTECTED]  still has 192.186.* in it.


 
 It uses bindaddr=0.0.0.0 and listens to both addresses.  
   
 externalip doesn't affect the bindaddr.

Would not expect it to.  Just trying to be clear to people that
the machine has two ethernets.   I was hoping Asterisk would
just automatically say, Wait a minute, I'm taking an SDP with
addresses in the localnet, and sending it out to a peer on the
outside internet.  That's not going to work!   


Now one of my tests has a SIP program I have written attempt to
call Asterisk.  It sits on port 5061 invites to Asterisk on 5160
of the machine with the external address as follows:


INVITE sip:[EMAIL PROTECTED]:5160;transport=udp SIP/2.0^M
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE^M
From: Voxable sip:[EMAIL PROTECTED];tag=3445^M
To: Party Leg1 sip:[EMAIL PROTECTED]:5160^M
Via: SIP/2.0/UDP 
198.144.201.82:5061;branch=z9hG4bK6563eba5fd430b5af93579617a44450e^M
Max-Forwards: 12^M
Contact: Caller App sip:[EMAIL PROTECTED]:5061^M
Date: Wed, 01 Nov 2006 04:52:07 GMT^M
User-Agent: Voxable 0.1^M
Content-Type: application/sdp^M
Content-Length: 154^M
^M
v=0
o=capp 1162356727 1 IN IP4 198.144.201.82
s=CApp3PCC
c=IN IP4 198.144.201.82
t=0 0
m=audio 5308 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PMCA/8000

Asterisk sends this on to the phone, but rewrites the SDP
to present a local one:
o=root 26391 26391 IN IP4 192.168.123.10
s=session
c=IN IP4 192.168.123.10
t=0 0
m=audio 10856 RTP/AVP 0 97 8 101
 

I answer the phone and it responds to this SDP with an OK

o=brad 8000 8000 IN IP4 192.168.123.18
s=SIP Call
c=IN IP4 192.168.123.18
t=0 0
m=audio 5004 RTP/AVP 0 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11 
 


Asterisk then sends back this SDP without rewriting it.
Is it only doing that because it knows the traffic came from
the same machine?

Asterisk forwards this OK back.  Note the SDP

SIP/2.0 200 OK^M
Via: SIP/2.0/UDP 
198.144.201.82:5061;branch=z9hG4bK94e379b15dbd22f8594fa6e88a4cfcc0;received=198.144.201.82^M
From: Voxable sip:[EMAIL PROTECTED];tag=3445^M
To: Party Leg1 sip:[EMAIL PROTECTED]:5160;tag=as62de8d32^M
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE^M
User-Agent: Caller Asterisk^M
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
Supported: replaces^M
Contact: sip:[EMAIL PROTECTED]:5160^M
Content-Type: application/sdp^M
Content-Length: 199^M
^M
v=0^M
o=root 26391 26391 IN IP4 192.168.123.18^M
s=session^M
c=IN IP4 192.168.123.18^M
t=0 0^M
m=audio 5004 RTP/AVP 0 8^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:8 PCMA/8000^M
a=silenceSupp:off - - - -^M
a=sendrecv^M

My software then forwards that SDP on to an outside location, where the 
SDP is useless.

It works if the outside provider I forward the SDP to has my asterisk
box set with some flags (nat=yes I presume?) though I can't figure why.
That box is presumably, seeing the internal address, routing the
audio to some port on the * box, and asterisk is forwarding it but I
can't see how this is happening.  Odd.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users