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
Subject: Re: [asterisk-users] How to use stun server?
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
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.
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.
Post by Gordon HendersonPost by Rizwan Hishamhi 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,
Post by Rizwan Hishamthen its ok. if it is behind nat, then what? Now client knows what kind
of
Post by Rizwan Hishamnat it is behind, what is the roll of asterisk in it. asterisk already
knows
Post by Rizwan Hishamclient'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.
Post by Rizwan HishamAfter 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
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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Best Regards
Rizwan Hisham
Software Engineer
Axvoice Inc.
www.axvoice.com