Well, there is a valid reason for embedding the IP and port inside SIP.
First, SIP can be proxied multiple times (a chain, the proxy of your
provider talks to other proxy and so on until you reach the other
person provider's proxy), this is the way it was designed and still
used, so if you detect the IP address using layer 3 means, you may be
connecting to a proxy, no the endpoint. The SIP conversation is always
relayed via the proxy chain (never directly), and the proxies
add/delete things as the proxy passes thru them.
The ip and port embedded inside SIP tell the endpoints where is the
real other endpoint.
Second, SIP as it's name indicates Session Iniciation Protocol, is not
a media protocol, in that case it would be called something like
"voice carry protocol"; SIP only carries the signaling to
create/destroy media sessions, capabilities negociation, etc (not only
voice, but multple video, games, messaging, presence,...), but doesn't
carry the media. Also SIP normally is implemented in TCP and this is
planly BAD for media streams, because of the delays and retries that
tcp incurrs to deliver a ordered and complete stream of data.
So the media streams can't be carried over tcp because of it's
time-delay sensibility. So? you carry media sessions over UDP. So, if
a packet doesn't arrive? sorry it's lost forever. a packet arrives
late? simple, drop it, but doesn't stops the delivery of the future
packets, as if you did it over tcp. The RTP packets go end to end
directly, not via the proxy chain, using a shorter route, and usually
carrying TOS flags and are applied QoS.
Adobe flash video streaming is a example of doing strange things; to
be compatible with web an browsers, they did an implementation of a
RTP protocol over TCP (the server has to explicitly watch receipts
timestamps, and only transmit the most up to date data, skiping
delayed data), usually works fine, but when things go wrong, they go
VERY wrong and the video suffers until you can clean the bottleneck.
Also there is no obligation of using RTP as a real time media
companion to SIP, you could use SRTP, ZRTP, or other propietary
prococol; for other things like games, the only games in town are
propietary media protocols.
This works wonderfully in the plain old internet, but in the NAT'ed
paranoid internet of our days, the clients put their private address
in the SIP fields, and the other end can only laugh because the
address is unreachable. There is the usefulness of STUN and TURN, to
detect you NAT type and external ip address and port so the incoming
RTP stream can reach the endpoint via a NAT provided "hole" (ip
address and port that forwards to the endpoint [internal] ip address
and port). Also an administrator can put a proxy in the network's
boundary that rewrites SIP requests and eliminate the use of STUN.
But problems don't end there, for certain types of NAT, firewalls and
network setups, there is NO incomming way. This is the point where
things become really difficult.
That is the use of STUN. You should read a little more to understand
the basics of the prococols, more if you work for an ITSP.
> Message: 1
> Date: Fri, 3 Aug 2007 20:24:17 +0500
> From: "Rizwan Hisham" <rizwanhasham at gmail.com>
> Subject: Re: [asterisk-users] How to use stun server?
> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
> <asterisk-users at lists.digium.com>
> Message-ID:
> <4809880c0708030824g5dceb47dibdcadfff30e88301 at
mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'm sure there was a perfectly good reason for encoding the devices IP
> address inside the SIP data when they invented it, but right now, I
can't
> think why
> one thing i still dont understnd. if the device we are using is a computer,
> and we r running a softphone on it. and side by side we are also surfing
the
> net. then why is it so that web content is coming into the computer without
> any problem but rtp data is not. i think both the web application and
> softphone are using computer's local ip address in their requests. So
whats
> the reason for this?
>
> I understand how stun works but thanx for explaining it in so simple and
> concise way.
>
> One other question which has been bothering me is:
> If the client phone is behind nat, that means there is NATTING going on
> between public internet and local net. Then why do we need stun? NATTING
> should handle the problem itself as it does for other applications running
> on the same computer where softphone is also running.
>
>
> On 8/2/07, Gordon Henderson <gordon+asterisk at drogon.net> wrote:
> >
> >
> > On Thu, 2 Aug 2007, Rizwan Hisham wrote:
> >
> > > hi again.....well i have been trying to know what is the
relationship
> > > between asterisk and stun. what i mean is, i understand that a
client
> > > requests stun server to know whether its behind a nat or not. if
its
> > not,
> > > then its ok. if it is behind nat, then what? Now client knows
what kind
> > of
> > > nat it is behind, what is the roll of asterisk in it. asterisk
already
> > knows
> > > client's public ip whether its behind nat or not, if the
client is
> > > registered. So how does stun simplify things if there are nat
problems.
> >
> > There is no relationship between asterisk and STUN.
> >
> > > After requesting stun server and recieving the required
information from
> > > stun server.....what happens next?
> > > I hope im clear in stating my problem.
> >
> > I'm not a STUN/SIP protocol gury by any means, but this is my
> > understanding (and it might be a bit simplistic)
> >
> > When something communicates with something else using SIP, the sending
> > device (eg phone) puts it's own IP address inside the SIP data
packet.
> > That IP address is the IP address of the device - it doesn't know
anything
> > about anything else, just the IP address it has. This would work well
if
> > NAT hadn't been invented, unfortunately it was.
> >
> >
> > The listening side (eg. asterisk), extracts this IP address and uses
it to
> > send data back.
> >
> > So if the originating device is behind NAT, and it's on (eg)
192.168.0.42
> > then the other end, gets that IP address and tries to send data back
to
> > it.
> >
> > Which, as 192.168.0.42 is on a private network, it can't do.
> >
> > Oops.
> >
> > So the original device uses a STUN server to poke a few bytes over the
> > interweb and the STUN server replys back with some information - such
as
> > the real external IP address and port numbers it's using.
> >
> > The STUN server is a tiny bit of software running on a host somewhere
with
> > a real IP address (or 2!) and is (or can be) quite independant of the
> > asterisk server.
> >
> > Original device can then put those values returned from the STUN
server
> > inside the SIP data packets (rather than it's 'real'
natted IP address)
> > and send them off to the other end, which can then use them to send
the
> > replys back to.
> >
> > The device should only need to access the STUN server once in it's
life,
> > but devices periodically check, just in-case things have changed. They
do
> > not relay data through the STUN server.
> >
> > So that's for device to asterisk box.
> >
> > Asterisk boxes are supposed to be directly connected to the Internet
with
> > no NAT and a real live IP address. (or at least that's the best
possible
> > way to do it!)
> >
> > If they aren't ... Then the first thing you need to do is arrange
> > port-forwarding from the firewall to the asterisk box. You'll need
to
> > forward the ports you need - eg. for SIP it might be 5060-5069 and for
RTP
> > it might be 10000-20000.
> >
> > But the asterisk server still needs to know what it's real
external IP
> > address is so it can put that in the SIP packets rather than it's
own
> > NATted address, and as asterisk can't use a STUN server, you need
to
> > explicitly tell it - this is in the sip.conf file and looks like:
> >
> > nat=yes
> > localnet=192.168.2.0/24
> > externip=1.2.3.4
> >
> > So now the asterisk server knows that anything that originates from
the
> > local network doesn't need to be translated, but anything going
out needs
> > to have the SIP data re-written with the real external IP address.
> >
> >
> > Now (AIUI) some SIP proxys can look inside SIP data packets and see
that
> > the IP address given by the device is not the same as the IP address
that
> > the packet came from and adjust things accordingly.. Asterisk, not
being a
> > SIP proxy doesn't do this, so if your phone is talking to a server
via a
> > proxy, then you may not need to tell the phone about a STUN server.
The
> > people running the asterisk+SIP proxy will tell you if this is the
case.
> >
> > I'm sure there was a perfectly good reason for encoding the
devices IP
> > address inside the SIP data when they invented it, but right now, I
can't
> > think why... See http://www.ietf.org/rfc/rfc3261.txt for the details!
> >
> > Gordon
> >
> > _______________________________________________
> > --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
> >
>
>
>
> --
> Best Regards
> Rizwan Hisham
> Software Engineer
> Axvoice Inc.
> www.axvoice.com