<p dir="ltr">I have noticed the same behaviour on behind-nat devices. It really is the router's causing the mess here. There are 2 workarounds - the nldb way with the connectile disfunction( this breaks at least one thing - SIMPLE messaging) and decreasing the session timers or the keepalives to the UAs. This will keep the portholes in tact. Both have pros and cons. And i still would suggest leaving stun enabled.</p>
<div class="gmail_quote">On Jun 4, 2013 9:28 PM, "Michael Jerris" <<a href="mailto:mike@jerris.com">mike@jerris.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>On Jun 3, 2013, at 11:57 PM, Steven Ayre <<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>> wrote:</div><br><blockquote type="cite"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
1. Why does FreeSWITCH initially send "Unauthorized" reply?</blockquote>
<div><br></div><div>It's required. SIP authentication is similar to HTTP authentication, it's based on challenge response. The first request fails and the response contains a nonce. The 2nd request sends a digest of the password combined with that nonce. That means you authenticate without sending your password over the internet plaintext and since the nonce is time-limited without that digest being able to be reused by an attacker.</div>
<div><br></div><div>If you see yourself calling into FS without that then you are either a) authenticating via IP address not password or b) calling into a SIP profile that doesn't require authentication (eg one for receiving calls).</div>
<div><br></div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br></div></blockquote><div><br></div><div>This is not 100% correct. If the other end already has a nonce, it can send the auth headers in the request and not be challenged.</div>
<div><br></div><br><blockquote type="cite"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Does anyone know why some phones change their port during registration from behind a NAT? </blockquote><div><br></div><div>That could be your NAT router changing the port mapping between requests (each REGISTER and INVITE is a separate SIP dialog).</div>
<div><br></div><div>SIP with NAT can work, but will be messy. Mostly because not everything supports it, supports it well, or does it in the same way. You can also encounter situations where the phone and router are both trying to workaround the NAT issues which causes more problems than it solves.</div>
<div><br></div><div>Generally FS does a good job of working around many of the issues, and has a few NDLB options for handling devices that don't handle NAT well. See <a href="http://wiki.freeswitch.org/wiki/NAT_Traversal" target="_blank">http://wiki.freeswitch.org/wiki/NAT_Traversal</a></div>
<div><br></div><div>For starters you should disable SIP ALG on your router and enable STUN in the SIP client, if it's supported.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. Should I file a Jira ticket to have FreeSWITCH change UA's registered contact info when the UA sends a message with a different Contact header?</blockquote><div><br></div><div>But what would it change it to?</div>
<div>
<br></div><div>For handling broken devices there are some NDLB options, some do try rewriting the Contact to where the packet came from. That's not correct in all cases, but perhaps is in many. <a href="http://wiki.freeswitch.org/wiki/NDLB" target="_blank">http://wiki.freeswitch.org/wiki/NDLB</a></div>
<div><br></div><div><br></div><div>-Steve</div><div><br></div><div> </div></blockquote></div><br></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div>