Clive, Are you sure that is all that you are changing? Clearly the one that authorizes successfully has Authorization: Digest username="095290110", realm="voip", nonce="60f381b0", algorithm=MD5, uri="sip:sip.kiwilink.co.nz;transport=udp", response="a00513b45bea998c2f5dcdc89e9d8194" in the first sip packet. The one that fails does not include the "Authorization" information in the initial packet. Without knowing anything else, I would have guessed that the one that fails has the gateway configured with <param name="register" value="false"/> I realized you have basically indicated that is not changing, but if there is ANY chance you are using separate configurations, I would check your sipinterfaces.xml Hth, Sean -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Clive Lansink Sent: Saturday, March 15, 2014 5:21 PM To: Freeswitch users list Subject: [Freeswitch-users] Mistified by a registration issue Hello listers. I have had Freeswitch running for quite some time now with few issues. But recently I installed a new router and came across this problem while configuring it. I have my Sofia external profile set to use port 5060 and my internal profile uses another port. So I followed my previous practice and set the router to forward UDP port 5060 to Freeswitch and that works properly. I decided on this occasion that itmight be a good idea to also open up ports 16384-32768 so these are also forwarded to Freeswitch, as these are the RTP ports Freeswitch is set to use. I quickly found to my surprise that Freeswitch would fail to register with the external provider once I did this, but as soon as I stopped forwarding ports 16384-32768, Freeswitch would again register as it should. This seems really weird since I don't see how ports 16384-32768 can have any impact on the registration process on port 5060, and in any case whatever might be happening on these ports only involves Freeswitch so how can setting up such a port forwarding impact on registration. I would be pleased if anyone out there can answer this. I have included two SIP traces from the log. The first, trace1.txt, is the registration sequence when the ports are not forwarded. You can see Freeswitch sends a register, and the provider responds with an unauthorised which I think is the usual way it works. Freeswitch then responds with a register again and the provider responds with an ok. There are also some options packets in the sequence. So this is the regular pattern I see when Freeswitch is registered and remains registered. The second, trace2.txt, shows what happens when the ports 16384-32768 are set in the router to be forwarded to Freeswitch. Here we see Freeswitch sends a register packet, though it doesn't have the authentication information. I presume this is because at this point the gateway knows that it is not registered so this is like the first step in registering from scratch. Then we see the provider respond with an unauthorised message including (as before) the instruction for how to authenticate. But then Freeswitch doesn't respond with a follow-up attempt to register and eventually we see that it just reports that it timed out trying to register. I'm not a SIP expert but I don't see anything in the second dialog to explain why Freeswitch doesn't follow up to complete the registration even though it clearly does receive the unauthorised message with the authentication information. It would be great if someone could suggest what might be going on here. Thank you. Clive Lansink Email: Clive@Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 Fax: +64 21 789-150