<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Hi, Bogdan:<br><br>I think I have found the problem.<br>I am using mediaproxy. If I kill that proxy.<br>suddenly the uac can get the message.<br>So it is quite obvious that my mediaproxy setting is not correct.<br>Just I don't know how to fix it. I modify it from my old rtpproxy setting.<br><br><br>George<br></div><br><div>/////////////////////<br><br><br>#### NAT modules<br>loadmodule "nathelper.so"<br>modparam("nathelper", "natping_interval", 10)<br>modparam("nathelper", "ping_nated_only", 1)<br>modparam("nathelper", "received_avp", "$avp(received_nh)")<br><br>#loadmodule "rtpproxy.so"<br>#modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME<br><br>loadmodule "mediaproxy.so"<br>modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock")<br>modparam("mediaproxy", "ice_candidate", "low-priority")<br><br><br><br></div><br>####### Routing Logic ########<br><br># main request routing logic<br><br>route{<br> force_rport();<br> if (nat_uac_test("23")) {<br> if (is_method("REGISTER")) {<br> fix_nated_register();<br> setbflag(NAT);<br> } else {<br> fix_nated_contact();<br> setflag(NAT);<br> }<br> }<br> <br><br> if (!mf_process_maxfwd_header("10")) {<br> sl_send_reply("483","Too Many Hops");<br> exit;<br> }<br><br> if (has_totag()) {<br> # sequential request withing a dialog should<br> # take the path determined by record-routing<br> if (loose_route()) {<br> <br> if (is_method("BYE")) {<br> setflag(ACC_DO); # do accounting ...<br> setflag(ACC_FAILED); # ... even if the transaction fails<br> } else if (is_method("INVITE")) {<br> # even if in most of the cases is useless, do RR for<br> # re-INVITEs alos, as some buggy clients do change route set<br> # during the dialog.<br> record_route();<br> }<br><br> if (check_route_param("nat=yes")) <br> setflag(NAT);<br><br> # route it out to whatever destination was set by loose_route()<br> # in $du (destination URI).<br> route(relay);<br> } else {<br> <br> if ( is_method("ACK") ) {<br> if ( t_check_trans() ) {<br> # non loose-route, but stateful ACK; must be an ACK after <br> # a 487 or e.g. 404 from upstream server<br> t_relay();<br> exit;<br> } else {<br> # ACK without matching transaction -><br> # ignore and discard<br> exit;<br> }<br> }<br> sl_send_reply("404","Not here");<br> }<br> exit;<br> }<br><br> # CANCEL processing<br> if (is_method("CANCEL"))<br> {<br> if (t_check_trans())<br> t_relay();<br> exit;<br> }<br><br> t_check_trans();<br><br> if ( !(is_method("REGISTER") ) ) {<br> <br> if (from_uri==myself)<br> <br> {<br> <br> } else {<br> # if caller is not local, then called number must be local<br> <br> if (!uri==myself) {<br> send_reply("403","Rely forbidden");<br> exit;<br> }<br> }<br><br> }<br><br> # preloaded route checking<br> if (loose_route()) {<br> xlog("L_ERR",<br> "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]");<br> if (!is_method("ACK"))<br> sl_send_reply("403","Preload Route denied");<br> exit;<br> }<br><br> # record routing<br> if (!is_method("REGISTER|MESSAGE"))<br> record_route();<br><br> # account only INVITEs<br> if (is_method("INVITE")) {<br> <br> setflag(ACC_DO); # do accounting<br> }<br><br> <br> if (!uri==myself) {<br> append_hf("P-hint: outbound\r\n"); <br> <br> # if you have some interdomain connections via TLS<br> ## CUSTOMIZE IF NEEDED<br> ##if ($rd=="tls_domain1.net"<br> ## || $rd=="tls_domain2.net"<br> ##) {<br> ## force_send_socket(tls:127.0.0.1:5061); # CUSTOMIZE<br> ##}<br> <br> route(relay);<br> }<br><br> # requests for my domain<br> <br> if (is_method("PUBLISH|SUBSCRIBE"))<br> {<br> sl_send_reply("503", "Service Unavailable");<br> exit;<br> }<br><br> if (is_method("REGISTER"))<br> {<br> <br><br> if ( proto==TCP || proto==TLS || 0 ) setflag(TCP_PERSISTENT);<br><br> if (!save("location"))<br> sl_reply_error();<br><br> exit;<br> }<br><br> if ($rU==NULL) {<br> # request with no Username in RURI<br> sl_send_reply("484","Address Incomplete");<br> exit;<br> }<br><br> <br><br> <br><br> <br><br> # do lookup with method filtering<br> if (!lookup("location","m")) {<br> <br> <br> t_newtran();<br> t_reply("404", "Not Found");<br> exit;<br> } <br><br> if (isbflagset(NAT)) setflag(NAT);<br><br> # when routing via usrloc, log the missed calls also<br> setflag(ACC_MISSED);<br> route(relay);<br>}<br><br><br>route[relay] {<br> # for INVITEs enable some additional helper routes<br> if (is_method("INVITE")) {<br> <br> if (isflagset(NAT)) {<br># rtpproxy_offer("ro");<br> use_media_proxy();<br><br> }<br><br> t_on_branch("per_branch_ops");<br> t_on_reply("handle_nat");<br> t_on_failure("missed_call");<br> }<br> if (is_method("BYE")) {<br> if (isflagset(NAT)) {<br> end_media_session();<br> }<br> }<br><br><br> if (isflagset(NAT)) {<br> add_rr_param(";nat=yes");<br> }<br><br> if (!t_relay()) {<br> send_reply("500","Internal Error");<br> };<br> exit;<br>}<br><br><br><br><br>branch_route[per_branch_ops] {<br> xlog("new branch at $ru\n");<br>}<br><br><br>onreply_route[handle_nat] {<br> if (nat_uac_test("1"))<br> fix_nated_contact();<br># if ( isflagset(NAT) )<br># rtpproxy_answer("ro");<br> if (is_method("INVITE")) {<br> if (isflagset(NAT)) {<br> use_media_proxy();<br> }<br> }<br> if (is_method("BYE")) {<br> if (isflagset(NAT)) {<br> end_media_session();<br> }<br> }<br><br> xlog("incoming reply\n");<br>}<br><br><br>failure_route[missed_call] {<br> if (t_was_cancelled()) {<br> exit;<br> }<br><br> # uncomment the following lines if you want to block client <br> # redirect based on 3xx replies.<br> ##if (t_check_status("3[0-9][0-9]")) {<br> ##t_reply("404","Not found");<br> ## exit;<br> ##}<br><br> <br>}<br><br><br><br><br><div></div><div id="divNeteaseMailCard"></div><br>ÔÚ 2014-10-15 15:13:00£¬"Bogdan-Andrei Iancu" <bogdan@opensips.org> дµÀ£º<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="moz-cite-prefix"><tt>Hi George,<br>
<br>
If your OpenSIPS fails to reach the UAC is because of two
reasons:<br>
- NAT pinhole is closed - but if pinging is done, it shouldn't
be<br>
- opensips is trying to contact UAC via wrong IP:port - can
you confirm that when calling the UAC, OpenSIPS sends the INVITE
to same IP and port as where the pingings are coming from ?<br>
<br>
TCP works as this part is "automatically" resolved because of
the connection (where the other pipe is known).<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
On 15.10.2014 03:24, george wu wrote:<br>
</div>
<blockquote cite="mid:4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com" type="cite">
<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br>
<div>Hi, Bogdan-Andrei:<br>
<br>
For udp, it fails when <tt>reaching the UAC even though the
UAC keeps pinging the server all the time.<br>
<br>
For tcp, although it works. I find something interesting.<br>
Only when the client pings the server, the invite message is
sent to the UAC.<br>
In my understanding, the server should be able to send
message to the UAC since the <br>
tcp connection is open. Actually the sip server is unable to
send message to the UAC.<br>
<br>
About the firewall type, I use opensipsctl ul show/rm to
check.<br>
I find every time when it register, i get the same ip/port</tt><tt><tt>
most of time</tt>. <br>
But occasionally it might get different ip/port.<br>
I believe it is nat within a cone.<br>
<br>
I am using ice, the ice only work after the first invite
message is delivered to the peer.<br>
My ice with mediaproxy works perfectly.<br>
<br>
</tt></div>
<br>
George Wu<br>
<br>
At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu"
<a class="moz-txt-link-rfc2396E" href="mailto:bogdan@opensips.org"><bogdan@opensips.org></a> wrote:<br>
<blockquote id="isReplyContent" style="PADDING-LEFT: 1ex;
MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="moz-cite-prefix"><tt>Hi George,<br>
<br>
NAT traversal is not only about pinging, but also about
mangling/correcting the SIP traffic (from private IPs
perspective) and ensuring the RTP flow.<br>
<br>
So you need to be sure that all 3 points are addressed.<br>
<br>
TCP versus UDP - there is only a difference at IP
transport level...like datagram versus connection, and
their implications at NAT level (being able to reach the
device behind the nat). Otherwise it;s the same.<br>
<br>
For UDP, can you see what fails ? the registration?
reaching the UAC ? <br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
On 14.10.2014 18:37, george wu wrote:<br>
</div>
<blockquote cite="mid:9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com" type="cite">
<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">
<div>My experience is for two uac (linphone) behind a
firewall,<br>
tcp/tls will always work.<br>
udp will never work.<br>
<br>
for both tcp/udp, my uac will send keep alive every 10
seconds.<br>
I don't understand what makes those difference.<br>
Can any one share your experience?<br>
<br>
George Wu<br>
<br>
<br>
</div>
</div>
<br>
<br>
<span title="neteasefooter"><span id="netease_mail_footer"></span></span><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</blockquote>
</div>
<br>
<br>
<span title="neteasefooter"><span id="netease_mail_footer"></span></span>
</blockquote>
<br>
</blockquote></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>