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?
----------------- subset of my ser.cfg ------------------------- # ----------- global configuration parameters ------------------------
(skip something........) # -- mediaproxy params -- modparam("mediaproxy", "natping_interval", 30) modparam("mediaproxy", "sip_asymmetrics", "/usr/local/etc/ser/sip-asymmetric-clients") modparam("mediaproxy", "rtp_asymmetrics", "/usr/local/etc/ser/rtp-asymmetric-clients")
# -- usrloc params -- modparam("usrloc", "db_mode", 1) modparam("usrloc", "timer_interval", 60) modparam("usrloc", "desc_time_order", 1)
# -- registration params -- modparam("registrar", "nat_flag", 2) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 86400) modparam("registrar", "default_expires", 3600) modparam("registrar", "append_branches", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route {
(skip something........)
# ------------------------------------------------------------------------ # NAT Test Section #1 # ------------------------------------------------------------------------ if (method=="REGISTER" && client_nat_test("3")) { fix_contact(); force_rport(); setflag(2); };
# ------------------------------------------------------------------------ # Registration Section # ------------------------------------------------------------------------ if (method=="REGISTER") {
# allow all requests from user 700 - the Click2Dial controller if (!isflagset(14)) { if (!is_from_local()) { sl_send_reply("403", "Unknown Domain"); break; }; if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; # To - Use To username and (optionally) domain to check if (is_user_in("To", "demo-disabled")) { sl_send_reply("403", "Your evaluation period has expired"); break; }; # To - Use To username and (optionally) domain to check if (is_user_in("To", "disabled")) { sl_send_reply("403", "Your account has been disabled"); break; }; };
# snom sip phones use this header to start their # keep-alive mechanism for NAT bindings append_to_reply("P-NAT-Refresh: 15\r\n");
if (!save("location")) { sl_reply_error(); }; break; };
(skip something........)
# ------------------------------------------------------------------------ # NAT Tear-Down Section # ------------------------------------------------------------------------ if ((method == "BYE" || method == "CANCEL")) { end_media_session(); };
# ------------------------------------------------------------------------ # Record Route Section # ------------------------------------------------------------------------ if (!method=="REGISTER") { record_route(); };
# ------------------------------------------------------------------------ # Loose Route Section # ------------------------------------------------------------------------ if (loose_route()) { route(2); break; };
# ------------------------------------------------------------------------ # NAT Test Section #1 # ------------------------------------------------------------------------ if (client_nat_test("3") && !search("^Record-Route:")) { force_rport(); fix_contact(); };
# ------------------------------------------------------------------------ # Alias Routing Section # ------------------------------------------------------------------------ lookup("aliases"); if (!uri==myself) { route(2); break; };
(skip something........)
route[1] { (skip something........) }
route[2] { log(1, "SER: SIP Call On-Net section route(2)\n"); if ((method=="INVITE") && !allow_trusted()) { if (!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); break; } else if (!check_from()) { log(1, "Spoofed SIP call attempt"); sl_send_reply("403", "Use From=ID"); break; } else if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Please register to use our service"); break; }; }; if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; };
if (method=="INVITE" || method=="ACK") { use_media_proxy(); };
t_on_failure("1"); t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); };
}
onreply_route[1] { # Not all 2xx messages have a content body so here we # make sure our Content-Length > 0 to avoid a parse error if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:\ 0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_contact(); }; } ---------------- END HERE ---------------------------------------
---------------- default mediaproxy's ser.cfg ---------------- # Example ser.cfg for mediaproxy functionality
loadmodule "/usr/lib/ser/modules/registrar.so" loadmodule "/usr/lib/ser/modules/domain.so" loadmodule "/usr/lib/ser/modules/mediaproxy.so"
modparam("mediaproxy", "natping_interval", 60) modparam("registrar", "nat_flag", 2)
route{ if (!mf_process_maxfwd_header("10")) { if (method!="ACK") { sl_send_reply("483", "Too many hops"); }; break; };
if (msg:len >= max_len) { if (method!="ACK") { sl_send_reply("513", "Message too big"); }; break; };
if (method=="REGISTER") { if (is_from_local()) { # Mark as NAT'ed if (client_nat_test("3")) { setflag(2); force_rport(); fix_contact(); };
if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; } else if (!check_to()) { sl_send_reply("403", "Username!=To not allowed"); break; };
if (!save("location")) { sl_reply_error(); }; } else { sl_send_reply("403", "This domain is not served here"); };
break; };
if (method=="INVITE") { if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Relaying is forbidden"); break; }; t_on_failure("1"); } else if (method == "BYE" || method == "CANCEL") { end_media_session(); };
if (loose_route()) { if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; # end media session for BYE and CANCEL is done above # before entering the loose route. no need to call it here t_relay(); break; };
# Force subsequent messages to pass trough this proxy if (method == "INVITE") { record_route(); };
if (client_nat_test("3") && !search("^Record-Route:")) { # Mark as NAT'ed force_rport(); fix_contact(); };
if (method=="INVITE") { t_on_reply("1"); };
if (is_uri_host_local()) { # join with next if? if (!lookup("location")) { sl_send_reply("404", "User not found"); break; }; };
if (method=="INVITE" || method=="ACK") { use_media_proxy(); };
if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; }
failure_route[1] { end_media_session(); }
onreply_route[1] { if (status=~"(183)|(2[0-9][0-9])") { if (client_nat_test("1")) { fix_contact(); }; use_media_proxy(); }; }
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?
----------------- subset of my ser.cfg ------------------------- # ----------- global configuration parameters ------------------------
(skip something........) # -- mediaproxy params -- modparam("mediaproxy", "natping_interval", 30) modparam("mediaproxy", "sip_asymmetrics", "/usr/local/etc/ser/sip-asymmetric-clients") modparam("mediaproxy", "rtp_asymmetrics", "/usr/local/etc/ser/rtp-asymmetric-clients")
# -- usrloc params -- modparam("usrloc", "db_mode", 1) modparam("usrloc", "timer_interval", 60) modparam("usrloc", "desc_time_order", 1)
# -- registration params -- modparam("registrar", "nat_flag", 2) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 86400) modparam("registrar", "default_expires", 3600) modparam("registrar", "append_branches", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route {
(skip something........)
# ------------------------------------------------------------------------ # NAT Test Section #1 # ------------------------------------------------------------------------ if (method=="REGISTER" && client_nat_test("3")) { fix_contact(); force_rport(); setflag(2); };
# ------------------------------------------------------------------------ # Registration Section # ------------------------------------------------------------------------ if (method=="REGISTER") {
# allow all requests from user 700 - the Click2Dial controller if (!isflagset(14)) { if (!is_from_local()) { sl_send_reply("403", "Unknown Domain"); break; }; if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; };
# To - Use To username and (optionally) domain to check if (is_user_in("To", "demo-disabled")) { sl_send_reply("403", "Your evaluation period has expired"); break; };
# To - Use To username and (optionally) domain to check if (is_user_in("To", "disabled")) { sl_send_reply("403", "Your account has been disabled"); break; }; };
# snom sip phones use this header to start their # keep-alive mechanism for NAT bindings append_to_reply("P-NAT-Refresh: 15\r\n");
if (!save("location")) { sl_reply_error(); }; break; };
(skip something........)
# ------------------------------------------------------------------------ # NAT Tear-Down Section # ------------------------------------------------------------------------ if ((method == "BYE" || method == "CANCEL")) { end_media_session(); };
# ------------------------------------------------------------------------ # Record Route Section # ------------------------------------------------------------------------ if (!method=="REGISTER") { record_route(); };
# ------------------------------------------------------------------------ # Loose Route Section # ------------------------------------------------------------------------ if (loose_route()) { route(2); break; };
# ------------------------------------------------------------------------ # NAT Test Section #1 # ------------------------------------------------------------------------ if (client_nat_test("3") && !search("^Record-Route:")) { force_rport(); fix_contact(); };
# ------------------------------------------------------------------------ # Alias Routing Section # ------------------------------------------------------------------------ lookup("aliases"); if (!uri==myself) { route(2); break; };
(skip something........)
route[1] { (skip something........) }
route[2] { log(1, "SER: SIP Call On-Net section route(2)\n"); if ((method=="INVITE") && !allow_trusted()) { if (!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); break; } else if (!check_from()) { log(1, "Spoofed SIP call attempt"); sl_send_reply("403", "Use From=ID"); break; } else if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Please register to use our service"); break; }; }; if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; };
if (method=="INVITE" || method=="ACK") { use_media_proxy(); };
t_on_failure("1"); t_on_reply("1");
if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); };
}
onreply_route[1] { # Not all 2xx messages have a content body so here we # make sure our Content-Length > 0 to avoid a parse error if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:\ 0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_contact(); }; } ---------------- END HERE ---------------------------------------
---------------- default mediaproxy's ser.cfg ---------------- # Example ser.cfg for mediaproxy functionality
loadmodule "/usr/lib/ser/modules/registrar.so" loadmodule "/usr/lib/ser/modules/domain.so" loadmodule "/usr/lib/ser/modules/mediaproxy.so"
modparam("mediaproxy", "natping_interval", 60) modparam("registrar", "nat_flag", 2)
route{ if (!mf_process_maxfwd_header("10")) { if (method!="ACK") { sl_send_reply("483", "Too many hops"); }; break; };
if (msg:len >= max_len) { if (method!="ACK") { sl_send_reply("513", "Message too big"); }; break; };
if (method=="REGISTER") { if (is_from_local()) { # Mark as NAT'ed if (client_nat_test("3")) { setflag(2); force_rport(); fix_contact(); };
if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; } else if (!check_to()) { sl_send_reply("403", "Username!=To not allowed"); break; };
if (!save("location")) { sl_reply_error(); }; } else { sl_send_reply("403", "This domain is not served here"); };
break; };
if (method=="INVITE") { if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Relaying is forbidden"); break; }; t_on_failure("1"); } else if (method == "BYE" || method == "CANCEL") { end_media_session(); };
if (loose_route()) { if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; # end media session for BYE and CANCEL is done above # before entering the loose route. no need to call it here t_relay(); break; };
# Force subsequent messages to pass trough this proxy if (method == "INVITE") { record_route(); };
if (client_nat_test("3") && !search("^Record-Route:")) { # Mark as NAT'ed force_rport(); fix_contact(); };
if (method=="INVITE") { t_on_reply("1"); };
if (is_uri_host_local()) { # join with next if? if (!lookup("location")) { sl_send_reply("404", "User not found"); break; }; };
if (method=="INVITE" || method=="ACK") { use_media_proxy(); };
if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; }
failure_route[1] { end_media_session(); }
onreply_route[1] { if (status=~"(183)|(2[0-9][0-9])") { if (client_nat_test("1")) { fix_contact(); }; use_media_proxy(); }; }
--
Best Regards Charles
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?
Marian,
Thank you very much for your explain. So, if a client side with STUN support and setting it correctly, is it not necessary to use media proxy(outboumd proxy setting)? If yes, my clients with STUN should can talk to each other without setting outbound proxy.
But in fact, I test this with two X-Pro running on two NATed PCs. I find out they are always send its RTP to my SER not send to each other directly. So it will add my SER's loading. Can you tell me how to change my ser.cfg to avoid such condiction? Please....
On Tue, 22 Mar 2005 19:26:35 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
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
Hi Charles,
It's correct, if _all_ clients use STUN (and a correct implementation) you don't need mediaproxy or nathelper.
Best regards, Marian
Charles Wang wrote:
Marian,
Thank you very much for your explain. So, if a client side with STUN support and setting it correctly, is it not necessary to use media proxy(outboumd proxy setting)? If yes, my clients with STUN should can talk to each other without setting outbound proxy.
But in fact, I test this with two X-Pro running on two NATed PCs. I find out they are always send its RTP to my SER not send to each other directly. So it will add my SER's loading. Can you tell me how to change my ser.cfg to avoid such condiction? Please....
On Tue, 22 Mar 2005 19:26:35 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
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
That's actually not true -- STUN clients fail to traverse symmetric NAT (see RFC3489) without a media proxy.
-jiri
At 08:08 PM 3/22/2005, Marian Dumitru wrote:
Hi Charles,
It's correct, if _all_ clients use STUN (and a correct implementation) you don't need mediaproxy or nathelper.
Best regards, Marian
Charles Wang wrote:
Marian, Thank you very much for your explain. So, if a client side with STUN support and setting it correctly, is it not necessary to use media proxy(outboumd proxy setting)? If yes, my clients with STUN should can talk to each other without setting outbound proxy. But in fact, I test this with two X-Pro running on two NATed PCs. I find out they are always send its RTP to my SER not send to each other directly. So it will add my SER's loading. Can you tell me how to change my ser.cfg to avoid such condiction? Please....
On Tue, 22 Mar 2005 19:26:35 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
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
-- Voice System http://www.voice-system.ro
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Hi Jiri,
Indeed, in real world scenarios, to be able to cop with all types of NATs in the most efficient way, you need to use a combination of server and client NAT traversal.
Best regards, Marian
Jiri Kuthan wrote:
That's actually not true -- STUN clients fail to traverse symmetric NAT (see RFC3489) without a media proxy.
-jiri
At 08:08 PM 3/22/2005, Marian Dumitru wrote:
Hi Charles,
It's correct, if _all_ clients use STUN (and a correct implementation) you don't need mediaproxy or nathelper.
Best regards, Marian
Charles Wang wrote:
Marian, Thank you very much for your explain. So, if a client side with STUN support and setting it correctly, is it not necessary to use media proxy(outboumd proxy setting)? If yes, my clients with STUN should can talk to each other without setting outbound proxy. But in fact, I test this with two X-Pro running on two NATed PCs. I find out they are always send its RTP to my SER not send to each other directly. So it will add my SER's loading. Can you tell me how to change my ser.cfg to avoid such condiction? Please....
On Tue, 22 Mar 2005 19:26:35 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
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
-- Voice System http://www.voice-system.ro
Yes, I use STUN client on my UACs and build a mediaproxy on my SER in order to solve these conditions.
On Wed, 23 Mar 2005 14:01:48 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
Hi Jiri,
Indeed, in real world scenarios, to be able to cop with all types of NATs in the most efficient way, you need to use a combination of server and client NAT traversal.
Best regards, Marian
Jiri Kuthan wrote:
That's actually not true -- STUN clients fail to traverse symmetric NAT (see RFC3489) without a media proxy.
-jiri
At 08:08 PM 3/22/2005, Marian Dumitru wrote:
Hi Charles,
It's correct, if _all_ clients use STUN (and a correct implementation) you don't need mediaproxy or nathelper.
Best regards, Marian
Charles Wang wrote:
Marian, Thank you very much for your explain. So, if a client side with STUN support and setting it correctly, is it not necessary to use media proxy(outboumd proxy setting)? If yes, my clients with STUN should can talk to each other without setting outbound proxy. But in fact, I test this with two X-Pro running on two NATed PCs. I find out they are always send its RTP to my SER not send to each other directly. So it will add my SER's loading. Can you tell me how to change my ser.cfg to avoid such condiction? Please....
On Tue, 22 Mar 2005 19:26:35 +0100, Marian Dumitru marian.dumitru@voice-sistem.ro wrote:
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
-- Voice System http://www.voice-system.ro
-- Voice System http://www.voice-system.ro