Temporarily Unavailable

For the past few days I have been forwarding my flynumber DID to two different SIP providers and I keep having issues with “Temporarily Unavailable” from you guys. The phone never rings even though from the phone itself I am able to dial out. I know its not a NAT issue because I do port forwarding for all SIP ports to the device itself and secondly, it works perfectly fine sometimes. However I get periods of complete blackout where the phone doesnt ring and I get these Temporarily Unavailable messages.

Secondly, this behavior happens with two different SIP providers so I am starting to look at flynumber a little closer to see what could be happening.

Could you tell me exactly what Temporarily Unavailable means and under what circumstances this error message is encountered?

I know that the device is able to reach the sip servers fine and the other way around since not only am I using NAT port forwarding but a STUN server as well.

Please help me out.


Sorry to hear…

We checked your number and its working OK, seems its the forwarding destination

This wouldn’t have anything to do with us as your current forwarding setup with FlyNumber is just for incoming calls

Is there anyway we can try without the STUN on?

Usually this would mean the sip uri we’re sending the calls is not accepting the connection for one reason or another. Perhaps your Voip provider requires some sort of authentication to send calls there?

It could be you haven’t added our IP’s to your system.

Here is a sample Asterisk and our IP addresses to help you set this up correctly

To see the more recent calls in call history set the “To” date to one day in the future ( known bug we are working on)

If the issue persists please PM or open a ticket and attach any error logs your system provides

Here is some generic info on NAT that may help your situation …

Network Address Translation (NAT) is a common practice used in networks, and it doesn’t play well with VoIP. Solving this problem requires an understanding of NAT, VoIP and your VoIP setup. The following focuses on the SIP protocol for VoIP using Asterisk, but problems and solutions are applicable to most other situations.

NAT can cause problems in several places. If one of the PBXes is behind a NAT gateway, the other PBX will not be able to contact it without some additional network setup. If one or more of the phones are behind a NAT gateway, the other phone will be trying to send audio to a non-routable address. This results in failed calls or missing audio.

The alternative to a re-invite is to have the PBX relay the voice packets between the two endpoints.

SIP client is behind a NAT gateway connecting to a server on the Internet

The client creates the translation entry for the SIP traffic when it first registers. As long as there is frequent communication between the two hosts, such as one packet per minute, the channel will stay open. The only configuration needed is to have the client use its external address in all SDP packets. On clients that support it, enable STUN (Simple Traversal of UDP through NAT), so the client can determine the external address dynamically, or enter it manually. Asterisk doesn’t support STUN at this time, so all NAT configuration must be done manually. The following commands in /etc/asterisk/sip.conf set up the NAT properly:


localnet= // or your subnet

externip=x.x.x.x // use your address

[YOURREMOTEPEER] // your peer’s name


qualify=yes // force keepalives

With this configuration, Asterisk uses the address defined by externip for all calls to the peers configured with nat=yes. The addition of qualify=yes causes Asterisk to test the connection frequently so that the NAT translations are not removed from the firewall. With these two commands, there always will be a communications channel between Asterisk and the peer, and Asterisk will use the outside address when sending SDP messages.

Multiple SIP phones and an Asterisk server behind a NAT gateway

Calls between the phones will work fine because NAT is not needed. For calls between you and other systems on the Internet there will be problems. Unless you register to the remote side as a client (as done in the previous example), you will not be able to receive SIP messages, so you will not be able to accept calls. Second, the address information in the call setup will point to the internal address of the phone, and the one-way audio problems mentioned previously will crop up.

The easiest solution to this is to avoid NAT entirely. If you have a public IP address available for your call server, use it. If your Asterisk server is connected to both the Internet and the internal network, the SIP port is reachable from both the inside and the outside, and the only problem is ensuring RTP flows properly. The PBX server does not need to be configured to route between the interfaces or provide masquerading; it simply needs to bridge the inbound and outbound voice calls.

As I mentioned earlier, the PBX either can stay in the voice path or get out of the way. In the latter case, the PBX tells both endpoints about each other after which the endpoints talk directly. However, Asterisk could have a call setup with both endpoints and relay the RTP packets on behalf of each endpoint. The inside host would be talking to the inside address, and the outside host would be talking to the outside address. The only configuration required to achieve this in sip.conf is to disable re-invites:


canreinvite=no // force relaying

This configuration works well because the Asterisk server can speak freely to the Internet to send and receive calls. It also can talk to the internal phones, and by some simple bridging, completely ignore NAT.

As it turns out, this relaying behavior also is required when the Asterisk server has only a private address. The RTP ports will have to be forwarded on the firewall too. RTP chooses random port numbers based on configured limits. Before the ports can be configured, they should be limited in range. Configuring the firewall rules is much easier if the range of ports is known beforehand.

The range of ports to be used for RTP is defined in rtp.conf. The following configuration will limit Asterisk’s choice of RTP ports from 10000 to 20000:


rtpstart=10000 // first port to use

rtpend=20000 // last port to use, rounded up if odd

Asterisk will need several RTP ports to operate properly. Only even ports are actually used, and disabling of re-invites causes two connections to be built per call. These ports and the SIP port must then be forwarded in by the firewall. The iptables syntax is:

iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 10000:10100 -j DNAT \


iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 5060 -j DNAT \


Replace eth0 with the outside interface of your firewall and with the address of your Asterisk server. These rules tell the Linux kernel to translate the destination address of any UDP packets in the given range that are entering the outside interface. This must happen at the PREROUTING stage as opposed to the POSTROUTING stage, because the destination address is being translated. At this point, any SIP or RTP packet from the Internet will be forwarded to the internal Asterisk server for processing.

When a remote station makes a call to Asterisk, the SIP packet will be forwarded in because of the iptables rules. Asterisk will stay in the media stream because of the canreinvite=no command and it will use the external address of the firewall in any SDP packets because of the NAT commands. Finally, the media stream will be forwarded to the Asterisk server because of the combination of iptables RTP forwarding and port ranges defined in rtp.conf.

Up to this point, the configuration has focused on getting Asterisk working behind a NAT gateway, with some extra details to make the phones relay through Asterisk. There are, of course, more general solutions.

If you can avoid NAT in the first place, it is in your best interests to do so because it avoids all the problems encountered so far.

The Asterisk gateway can have a very restrictive firewall policy applied to it – you just need to allow UDP 5060 for SIP and whatever port range is defined in rtp.conf. In this configuration, Asterisk can contact both the internal phones and the rest of the Internet.

If SIP is not a requirement, and you are using Asterisk, consider using the IAX protocol. IAX tunnels both the control traffic and the voice traffic over a single UDP conversation that can be port-forwarded, filtered or translated easily. This method is limited to a static set of tunnels, which is sufficient if you are connecting some PBXes over the Internet or connecting to a long-distance provider.

Sometimes the above solutions are not available to you. In that case, it might be advisable to move to a full-featured SIP proxy and use Asterisk only for voice applications, such as voice mail. SIP Express Router (SER) is a powerful SIP server that handles NAT well and is used by several high-volume services, including Free World Dialup. SER’s job is only in setting up calls between endpoints, so it must rely on other applications, such as specialized media proxies, to handle RTP streams if needed.

The step beyond a SIP proxy is a Session Border Controller (SBC), which is like a VoIP firewall. The SBC can intercede in either the signaling or RTP paths to add extra features, such as signaling protocol or codec translation, all while enforcing security policies. These are almost exclusively commercial products.

okay I will continue testing this weekend and update the thread as soon as I have more info. I tried with both STUN and NAT Keep Alive, but I have done port forwarding on incoming SIP 5060 and RTP traffic so STUN and NAT should not really be necessary in this case.

Secondly, I am forwarding flynumber to CWU and from different forums it seems this combination is okay as there are others using it out there. Finally, I have tried a different DID provider (other than DIDWW reseller) to make sure that the DIDWW servers reaching CWU is not the issue here.

I will keep this thread updated.
Thx for the response.

Correct, if we can keep STUN disabled while testing that could help

As long as your provider allows SIP traffic from outside providers you should be OK. Perhaps you want to ask them what are the requirements to send calls to their servers

We’re here for you if you need anything