Hello Charles,
Just to give you the big picture about NAT traversal mechanisms:
STUN is used to perform the NAT traversal on the client side - the UAC
is NAT aware (via STUN) and sends SIP messages using the public IP. From
server side, the UAC will look like a public one, so there no logic
required on server for this case.
nathelper and mediaproxy are rather equivalent and implement NAT
traversal on server side - UAC has nothing to know about NAT and send
messages with private IP. The server takes care about detecting a
correcting messages coming from behind a NAT.
Best regards
Marian
Charles Wang wrote:
Hi, ALL:
I can't not make sure my view point between STUN and mediaproxy.
Please explain for me.
In my view, if NATed UACs want to make a call,
the solutions shall be nathelper, mediaproxy or building a STUN server.
If NATed UACs set their own STUN server's IP correctly,
and they want to talk with each other will be in a "direct"
(RTP will not pass through SER) mode, is it correct? And the STUN server
will tell our UACs what's their NAT gateway's IP(behind what kind
of network environment , and UACs will send these informations to SER?
In another word, it is not necessary to use media proxy to pass their
RTP channel?
If it is correctly, so we will not to set any mediaproxy daemon for
them, is it correct?
If it is not, can anyone tell me why it is not?
If ignore the STUN issue, I use the mediaproxy's ser.cfg as my template ser.cfg.
But I find all UACs's RTP packages will pass through my SER wether
behind NAT or not( read IPs ). How can I modify my ser.cfg and make a
call directly without pass through SER if two UACs are all real IPs?
--
Voice System
http://www.voice-system.ro