That's a different part of the equation.
If Asterisk could interpret the Via: headers like the Cisco phones
do, that would solve the Asterisk-behind-a-NAT problem to a large
degree. Perhaps it already does; I've never tried putting Asterisk
behind a NAT, only SIP clients.
JT
Please don't
On Wed, 2003-07-02 at 04:26, John Todd wrote:
You may be correct about the Via: header, but you're incorrect in the
concept as to how it relates to Asterisk, notably in your reversal of
what side of the transaction is putting data in the Via: header to
make SIP work correctly.
This is
Date: Tue, 1 Jul 2003 14:37:20 +1000
From: Andrew Radke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Asterisk-Users] A solution for SIP and NAT
...
So I've started a really simple SIP and RTP proxy project, SaRP, on
sourceforge.net. Yesterday we uploaded 0.2 of the perl based release.
Patrick wrote:
[snip]
Hi John,
[snip]
How about Asterisk and NAT? Can you please comment if the examples below
also work.
1x SIP phone - NAT box - Internet - NAT box - Asterisk
10x SIP phone - NAT box - Internet - NAT box - Asterisk
This all depends on the NAT boxes that you use. The SIP phone.
Klaus Darilion wrote:
[snip]
The project can be found at http://sarp.sourceforge.net/
There is also a similar project called siproxd:
http://sourceforge.net/projects/siproxd/
regards,
klaus
It has a broadly similar goal on the surface but a very very different
approach. siproxd relies on a
Instead of this make notes of some of the faults in SIP that cause you
problems and start working towards SIP/2.1 or SIP/3.0. Just because you
weren't one of the people involved in designing the existing protocol
doesn't mean you can't work to change it.
SIP 2.0 has some unbeleivably braindead
Andrew Radke wrote:
Ok I guess it's time for me to weigh in on this since I started the
whole thing and am the main developer of SaRP.
NAT and SIP _can_ work okay under very very restricted circumstance.
Multiple SIP UAs behind one NATed IP _can_ work okay with a very
intelligent
Hey Jim , you are correct in respect to the Service provider must pay for
the bandwidth as I/we will be hair pinning calls back into the Internet. As
far as voice quality is concerned (which is my biggest concern) the
solution(box) FWD uses will not be the solution I will implement. I am
I'm uncertain why you're not able to get SIP working for your user
agents (SIP clients.) With Cisco equipment, as an example, it works
quite well and almost every 79xx or ATA-186 I have is behind a NAT,
and this configuration is duplicated across a dozen or more systems
now running behind
Hello, NAT/Firewall is truelya problem in the
ITSP arena. Thereisone solutionIknow of that works
wellas an integrated DHCP/NAT/Firewall into a SIP aware
firewall. Check out www.intertex.se and look at the IXX66 products. They even have a
device that integrates DSL/NAT/Firewall. Or, one can
Could you give some details about setting up a stun server?
I'm doing some tests, and were successful using snom + stund
from vovida . But I got a no-go with budgetones
(that needs stund on a standard port that's 3478).
When my snom contacts the stund server, I get a lot
of info about the
Sorry, I still don't know what you're talking about.
Clients behind NAT can talk to Asterisk without difficulty, and I use
that functionality all the time. If that is not the case for you,
I'm afraid you'll have to be much more specific about your problems
for anyone to help you. Despite
Get a trace using Ethereal when the phone boots up and look in the warning
field of the sip message, if it lists your firewall type as symetric theres
a good chance your out of luck using that firewall. I'm a bit confused
regarding your port selection, as 3478 is cleared stated as the broadcast
Sorry to answer your question, you need to down load the source from vovida
and compile it. Follow the instrustion in the readme on the main page. Do
not use ports indicated 1 and 1000x. Use 3478 and 3479. Oh for the
alternate stun server (-a option) add 127.0.0.1. It's really straight
Maybe I mis-understood the question or the architecture. I assumed (I
know), the SIP UA sat behind the NAT and Asterisk sat on the public IP
network.(there are inhererent signaling problems in this scenario and will
not work without either the device having the ability to learn the WAN IP
address
John,
When you say you have SIP clients working behind NAT is this with ports
mapped from a public ip to the phone? I.e. can many phones sit behind 1
public ip and recieve incomming calls, and make outgoing calls?
- Justin
On Tue, 1 Jul 2003, John Todd wrote:
Sorry, I still don't know what
No, it works fine. SIP UA behind the NAT. Asterisk outside the NAT.
nat=1 set on the SIP peer. Works fine. Really. It does.
I use Cisco equipment for my UA's. The catch might be that the Cisco
devices are more clever than their counterparts, and will compare
the Via: header against their
Yes, I have one location where there are a dozen or so behind the
same NAT. Things work fine for inbound and outbound. I'm sure there
is a theoretical limit based on what an 8 or 16 bit integer can hold,
but I'm not worried about hitting that problem any time soon.
JT
John,
When you say
Your correct, Cisco devices stuff the WAN address in the Via: header which
in turn allows the proxy to correctly register the UA for an incoming call
attempt to that UA. If Mark is mentioning STUN as I said before, the only
devices I'm aware of are the SNOM 100 and Grandstream 101. These devices
You may be correct about the Via: header, but you're incorrect in the
concept as to how it relates to Asterisk, notably in your reversal of
what side of the transaction is putting data in the Via: header to
make SIP work correctly.
This is cluttering up the list. Talk to me off line if you
Please don't take the discussion of SIP interactions off list. I already
have NATed SIP clients working with *, but * still has problems where
its own external IP is not public and it is trying to use external SIP
services. A full discussion on list could spawn an Asterisk SIP FAQ -
and I think
Hi all.
I have come to the conclusion that there just isn't anything out there
for allowing SIP and NAT to work together nicely. This is rather amazing
considering that as far back as March 2000 there are documents
describing how to do it.
So I've started a really simple SIP and RTP proxy
22 matches
Mail list logo
