How to accept direct inbound calls to your LinkSys/Sipura adapter, bypassing all VoIP providers!
- Does your registered provider not allow inbound SIP URI calls?
- Do you want to cut down on latency/echo, by bypassing your VoIP provider on inbound VoIP calls?
- Do you simply like the idea of allowing calls directly into your VoIP adapter?
If you said yes to any of the above, then this FAQ page may be for you. Here is a description of how to let your LinkSys/Sipura model adapter accept calls directly
from a SIP URI (internet VoIP address), bypassing all VoIP providers in the process. Here's how to do it:
- Setup your adapter for use behind a NAT router
- Setup STUN on your adapter (NOTE: STUN settings are on the SIP tab)
- Handle VIA received: no
- Handle VIA rport: no
- Insert VIA received: no
- Insert VIA rport: no
- Substitute VIA Addr: yes
- Send Resp To Src Port: yes
- STUN Enable: yes
- STUN Test Enable: no
- STUN Server: stun.voxalot.com:3478
- NOTE: You can replace the above STUN server with any STUN server you like...
- EXT IP:
- NOTE: Leave this setting blank, STUN will figure this out for you...
- EXT RTP Port Min:
- NOTE: Normally you can leave this blank, but you can set this if you have a specific need
- NAT Keep Alive Intvl: 45
- NOTE: Use an value SHORTER than the "timeout" value in your router.
- set "NAT Mapping Enable: yes"
- Set "Ans Call Without Reg: yes" on your adapter settings
- Make sure your adapter is on the default SIP port
- Make sure that SOMETHING is set for "User ID:"
- NOTE: If your adapter is "registered" with a VoIP provider, this will be your real "User ID"
- Make sure NOTHING is in "Outbound Proxy:" field on your adapter
- NOTE: This field is not normally needed if/when you have STUN setup (as above)
- Forward UDP port 5060 to your adapter
- NOTE: This may be easier if you use a static LAN address for your VoIP adapter
- Set up a "dynamic DNS" service for your LAN
- NOTE: The free service from "no-ip.com" works fine for this
If all of the above is setup correctly, then anyone on the internet can directly call your LinkSys/Sipura VoIP adapter by calling "sip:userid@dyamic_dns_address". For example, if your userid is "12345", and your dynamic DNS entry is "myaddress.no-ip.com", then your SIP URI is "sip:firstname.lastname@example.org".
NOTE: One useful purpose of this, is to point a free http://ipkall.com
number to your Sipura. You do this by logging into your IPKall account
, and filling in your "UserID" info (12345 in this example) for "SIP Phone Number:" and your dynamic DNS entry (myaddress.no-ip.com in this example) for the "SIP Proxy:" field. After saving these changes (and waiting the necessary hour for them to take effect), then calling your IPKall number will directly ring your VoIP phone (bypassing any service provider, including "Free World Dialup").
NOTE (added 2/7/2006):
Another poster mentioned that he needed to set "NAT Keep Alive Enable: yes
", or he got 1-way audio with his router. So if you are having problems with this trick (and you are not already telling your VoIP adapter to send "keep alive" packets), try turning the "NAT Keep Alive" setting on...
NOTE (added 2/7/2006):
After using this "trick" for some time, I have discovered that (while this often works very well), a minority of VoIP providers just don't like this setup.
The problem (when you run into a VoIP provider that just won't forward directly to your VoIP adapter, even though they do support SIP URI forwarding) appears to be with the details of the "dynamic DNS" service. The problem is, there are actually two DIFFERENT types of DNS records often used by VoIP SIP proxies (which is what you are having your adapter pretend to be, by this trick). DNS "A" records are the "normal type" of DNS entries (the type we use all the time, for example when visiting web sites), and also the type most dynamic DNS services (including the http://www.no-ip.com
service I use) offer. However, apparently there is also a special DNS "SRV" type record that some proxies use just for VoIP. And if your VoIP provider is using a picky enough SIP proxy, they will be unable to forward directly to your adapter, because they won't find a "SRV" record for your "proxy address" (even though your dynamic DNS service will have a "A" record for your IP). While most VoIP proxies either don't use SRV records or will happily use an "A" record if an SRV record isn't present, some proxies are just "too picky" about this little detail (and will therefore fail to forward directly to your adapter UNLESS you have DNS "SRV" record for your IP address).
Happily there is an easy "work around", if you already have your adapter's registered VoIP slots "full", and you want to add a VoIP service that has this "issue" (i.e. is picky about the SRV records). What I found works well (when you run into this problem), was to register for a free SIP Broker alias
that points directly to my adapter (via my dynamic DNS address). I then tell any VoIP service that has a problem with forwarding directly to my adapter, to instead forward to *email@example.com (where xxxxxxx is my SIP Broker alias
). This seems to work well as a "work around", because "sipbroker.com" appears to have the DNS "SRV" record that some VoIP proxies "need" and
SIP Broker can forward to a location identified just by a DNS "A" record. So the call essentially gets forwarded to SIP Broker, which forwards the call onto my adapter in that case. While this isn't quite as nice as going directly to your adapter, it is still an effective "work around" for when the VoIP proxy just refuses to forward directly to your LinkSys/Sipura.
Of course, you might as well try the "forward directly to your adapter" address first, and only resort to the SIP Broker alias
if/when the "direct" path doesn't work (as your call path will be slightly more reliable if the direct address works with your VoIP provider). And many places (including http://ipkall.com
) will happpily forward directly to your LinkSys/Sipura without any problems. But for those places that just don't like the DNS "A" records provided by dynamic DNS services, forwarding to SIP Broker (and then letting SIP Broker forward directly to your adapter) can be an effective "work around".