[Freeswitch-users] Issue with changing phone SIP port

[Michael Jerris]

On Jun 3, 2013, at 11:57 PM, Steven Ayre <steveayre at gmail.com> wrote:

> 1. Why does FreeSWITCH initially send "Unauthorized" reply?
> 
> 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.
> 
> 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).
> 
> 

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.


> 2. Does anyone know why some phones change their port during registration from behind a NAT? 
> 
> That could be your NAT router changing the port mapping between requests (each REGISTER and INVITE is a separate SIP dialog).
> 
> 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.
> 
> 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 http://wiki.freeswitch.org/wiki/NAT_Traversal
> 
> For starters you should disable SIP ALG on your router and enable STUN in the SIP client, if it's supported.
> 
> 
> 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?
> 
> But what would it change it to?
> 
> 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. http://wiki.freeswitch.org/wiki/NDLB
> 
> 
> -Steve
> 
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130604/331ca19c/attachment.html