.

DD-WRT and VoIP telephony

networking-voip-telephonyPaying any amount for a mostly idle land line phone seems excessive when there are free alternatives.  This article will give an introduction to using Google Voice combined and SIP based Voice-over-IP (VoIP).  It then goes into the details of configuring these services, the edge router and the analog telephone adapter.

Introduction

Google Voice (GV) gives us free domestic calling.  It also forks incoming calls to one or more phones.  It is implemented as an interconnect for the traditional phone system (PSTN).  It routes the calls as follows:

  • Incoming calls: are forked to one or more phones.  I.e. your land line phone and a cell phone.  If the call is left unanswered, it rolls over to voice mail that it transcribes.
  • Outgoing calls: you setup a call through their web interface or by dialing your own number.  GV will first call you, and then call the party that you are calling.  It then cross connect the two.

While this approach works well, people like me want to not only free themselves from the long distance companies, but also from their land line phone.  However, at the time of this writing, Google Voice does not directly support VoIP.

We will work around this by using a VoIP/PSTN interconnect such as netgate.com.  This is known as Direct inward Dialing (DID).  The DID gives you a regular phone number that you can use with your VoIP phone.  Examples of VoIP phones are hardware SIP phones, software SIP phones such as x-lite, or regular phones hooked up through an Analog Telephone Adapters (ATA).  In this article we will look at the SPA2102 analog phone adapter.  Here we register our DID phone number as one of the phones with Google Voice.

Call routing using GV + SipGate is as follows:

  • Incoming calls: arrive at Google voice.  They will forward the call to your DID phone number that then rings your VoIP connected phone.
  • Outgoing calls: you setup a call through the Google Voice  web interface or by dialing your own number.  GV first calls your DID number that in turn rings your VoIP phone.  GV then calls the party that you are calling and connect the two calls.

The next step make our phones behave like regular phones when dialing out.  Instead of going through the web interface, we want to dial a number on the phone.  This can be done by enlisting yet-another service: sipsorcery.com.  This is called a called a back-to-back user agent (B2BUA).  This service sits in between your analog phone adapter (SPA2102) and the DID (sipgate.com).

A typical call is visualized in this call graph.  Call routing using GV + SipGate + SipSorgery is as follows:

  • Incoming calls: arrive at Google voice.  They will forward the call to your DID phone number (sipgate.com) that in turn forwards the call to sipsorcery.com that then rings your VoIP connected phone.
  • Outgoing calls: you just dial the number on your VoIP connected phone.  Sipsourcery requests Google voice to setup the call.

Drawbacks

  • With so many services involved, there are many points of failure.
  • Another drawback is that 911 may not work or at best will not automatically get your location.  You will need to adjust the dialing script on sipsorcery to route the calls through netgate.com and enable/pay for E911 service.

Edge router: DD-WRT firmware

Start by verifying that your network connection is VoIP-ready by running this test.

First things first, we need connectivity.  I use a Asus RT-N16 with DD-WRT firmware configured as follows:

  • Setup > Basic Setup
    • WAN Setup > Optional Settings
      • Router Name =rtr
      • Domain Name = vonk
    • Network Setup > Router IP
      • Local IP Address = 10.0.1.1
      • Subnet Mask = 255.255.255.0
    • Network Setup > Network Address Server Settings (DHCP)
      • DHCP Type = DHCP Server
      • DHCP Server = Enable
      • Start IP Address = 10.0.1.100
      • Static DNS 1 =8.8.8.8  # google public DNS
      • Static DNS 2 = 8.8.4.4
    • Network Setup > Time Settings (man)
      • Time Zone = UTC-8
      • Summer Time (DST) = 2nd Sun Mar – first Sun Nov
  • Setup > DDNS
    • DDNS
      • DDNS Service = no-ip.com
      • User Name = username
      • Password = password
      • Hostname = hostname
      • Do not use external ip check = no
  • Services > Services
    • DHCP Server (man)
      • LAN Domain = your sirname
      • Static Leases
        • press “Add”, enter the information, press “Save”, repeat until all added
        • press “Apply Settings”
    • DNSMasq (man)
      • DNSMasq = enable
      • Local DNS = enable
      • Additional DNSMasq Options
        • # Additional options
          domain-needed                    # don’t forward plain names
          bogus-priv                       # don’t forward private addresse
          bogus-nxdomain=64.94.110.11      # keep Verisign in control
          filterwin2k                      # filter useless Windows DNS requests
          # Local DNS name server
          local=/yoursirname/    # answer this domain from /etc/hosts
          expand-hosts    # add the domain to /etc/hosts entries
          dhcp-option=2,-28800             # UTC -8:00
          dhcp-option=7,10.0.1.202         # SYSLOG server
          #dhcp-option=42,10.0.1.1          # NTP server
          dhcp-option=43,01:04:00:00:00:02 # disable NetBIOS over TCP/IP
    • Secure Shell (man)
      • Password Login = false
      • Authorized Keys = paste your public ssh-rsa key
  • Wireless
    • Basic Settings
      • Wireless Physical Interface wl0
        • Wireless Mode = AP
        • Wireless Network Mode = NG-Mixed
        • Wireless Network Name = your SSID
        • Wireless Channel = auto
        • Channel Width = 40 MHz
        • Control Channel = upper
        • Network Configuration = bridged
      • Virtual Interfaces wl0.1
        • Wireless Network Name = public
        • AP Isolation = enable
        • Network Configuration = bridged
    • Wireless Security
      • Physical Interface wl0
        • Security Mode = WPA2 Personal
        • WPA Algorithms = AES
        • WPA Shared Key = your wpa shared key
      • Virtual Interfaces wl0.1
        • Security Mode = disable
  • Setup > Networking (man)
    • Bridging
      • Create Bridge
        • press “Add” to add bridge “br1″
        • press “Save”
        • IP Address  =10.0.0.1
        • Subnet Mask = 255.255.255.0
        • press “Apply Settings”, and wait a few seconds for “br1″ to show up in “Current Bridging Table”
      • Assign to Bridge
        • press “Add” to add bridge “br1″ on interface wl0.1
        • press “Apply Settings”
    • DHCPD
      • Multiple DHCP Server
        • br1, on, 100, 50, 3600
        • press “Apply Settings”
  • Administration > Management
    • Web Access
      • Enable Info Site = enable
      • Info Site MAC Masking = enable
  • Access Restrictions > WAN Access
    • Blocked Services
      • smtp
  • NAT/QoS > Port Forwarding
    • Forwards
      • press “Add”, enter the information, press “Save”, repeat until all added
      • press “Apply Settings”

Sipgate.com (DID) and Sipsorcery.com (B2BUA)

Details can be found in section 8 of Unlimited free calling with Google Voice.   Remember that your sipgate VoIP credentials are not your username and password.  Instead use sipgate.com > My Settings > SIP Credentials.

VoIP adapter (SPA2102)

Some popular analog telephone adapters (ATA) from Cisco/Linksys are

  • PAP2T-NA, an old time favorite that provides the basic functionality: VoIP adapter with two analog phone hookups.
  • SPA2102, same as PAP2T-NA, but adds a router
  • SPA3102, same as SPA2102, but supports a land line for fallback connection, also support multiple SIP accounts per line.

My configuration:

  • Voice > Line 1
    • SIP Settings
      • SIP Transport = UDP (default)
      • SIP Port = 5060 (default)
    • Network Settings
      • SIP ToS/DiffServ Value = 0x04 (Type-of-Service = high reliability)
      • RTP Tos/DiffServ Value = 0x10 (Type-of-Service = minimal delay)
      • Network Jitter Level = low (assuming that is true for your connection)
    • Proxy and Registration
      • Proxy = sip.sipsorcery.com
      • Register = yes
    • Audio Configuration
      • Silence Supp Enable = false (otherwise the other party notices the cutting in/out)
    • Proxy and Registration
      • Use DNS SRV = yes (use DNS to switch between SIP servers) (details) (def)
      • DNS SRV Auto Prefix = auto
  • Voice > SIP
    • RTP Parameters
      • RTP Packet Size = 0.020 sec (minimize delay at the cost of some overhead)

Examples of event sequences where the SIP phone has a route-able IP address can be found in Transport address in SIP and SDP messages.

VoIP adapter (SPA2102) behind a NAT router

The most logical place for the VoIP adapter would be in between the cable modem and the edge router.  This way it can prioritize VoIP traffic and keep security issues limited to the VoIP adapter itself.  However, the SPA2102 has some flaws.  The most obvious one affects active SCP and TFTP transfers.  It also maxes out at about 20 Mbps with small packet throughput far worse.

The alternative is to place the VoIP adapter behind the Edge Router.  This router very likely implements Network Address Translation (NAT) to share one public IP address with many local devices.  However, the SIP protocol predates NAT and requires some tweaks to make it work.  One of the tweaks is formalized in RFC3581 and extends SIP with support for outgoing calls over NAT.  In this the client adds an “rport” parameter to the Via header field.

The first configuration step should be to creates a static DHCP lease for the VoIP adapter, and enable web admin access.

  • On the DD-WRT router
    • Services > Services > Services Management > DHCP Server
      • add a static lease for the VoIP adapter’s WAN address, so we can easily access it
  • On the VoIP adapter
    • Voice > System
      • System Configuration
        • Web Admin Access = yes (also, remember to set the passwords)

As described in Transport address in SIP and SDP messages, placing the  VoIP adapter behind a NAT can be made to work, but requires the DID to support Symmetric SIP (RFC3581) and Symmetric RTP (RFC4961).

Signaling (SIP) behind NAT

There are several solutions to make the signaling protocol aware of network address translation:

solution 1

The signaling protocol (SIP, RFC5626 ) has a build-in mechanism to help traverse NAT.   This solution takes advantage of this mechanism.  In that the VoIP adapter learns the address and port on the external NAT interface through Via parameters.

  • On the VoIP adapter
    • Voice > Line 1
      • NAT Settings
        • NAT Mapping Enable = yes (use external IP address as the SIP Contact)
        • NAT Keep Alive Enable = no (my DID already does that for me)
    • Voice > SIP
      • NAT Support Parameters (documentation)
        • Handle VIA received = yes  (learn the public IP address from a received “Via: ….; received=publicIpAdd“)
        • Handle VIA rport = yes  (learn the public port number from a received “Via: ….; rport=publicUdpPort“)
        • Substitute VIA Addr = yes  (add “Via: …; received=remoteIpAddr)
        • Send Resp to Src Port = yes  (add “Via: …; rport=remoteUdpPort)
        • EXT RTP Port Min = (left blank)
        • NAT Keep Alive Intvl = 15 sec  (maximum inactive time for the NAT binding)

solution 2: SIP port forwarding

In addition to above described configuration, you can help SIP pass through the NAT by adding a static forwarding of port range 5060-5061.  This works even when the DID does not support the “VIA rport”.  It also allows for direct client to client calling because the external port number is static.  This however requires a similar port range to be forwarded for each SIP phone.

  • On the edge router
    • NAT/QoS > Port Range Forward
      • voip sip, 5060-5061, TCP and UDP, 10.0.1.10 (or whatever the addr for the VoIP adapter)
  • On the VoIP adapter
    • Voice > Line 1
      • SIP Settings
        • SIP Ext Port = 5060

solution 3: outbound proxy

Using a outbound proxy helps SIP bypasses the NAT and requires minimal configuration on the VoIP adapter.  The DD-WRT router contains the OpenSER  “MilkFish” service that works well.  It also allows for local registration of SIP phones.  For an example message trace refer to SIP/SDP trace using MilkFish as outbound proxy.  Remember to disable STUN on all the phones in the local network.  This to prevent one of these phones from grabbing external port 5060.  Alternatively, you can use the firewall to enforce this behavior (see this blog)

solution 4: ALG

Another approach that comes to mind is Application Level Gateways (ALG), but I have not seen one that functions correctly.

Media streams (SDP/RTP) behind NAT

Now that we have the signaling path taken care of, it is time to turn our attention to the media streams.  SIP messages that setup the RTP media path use the media description protocol (SDP, RFC 4566).  This SDP is not NAT-aware, and can only be used behind NAT with the help of other protocols.

solution 1

This solution assumes that the DID is “smart” about NAT.  By “smart”, I mean that it ignores the RTP port in the SDP payload and waits until it receives media packets from the NAT’d client.  It then look for the actual source port of the incoming RTP stream and start sending media there, instead.

solution 2: RTP port forwarding

If the DID is not “smart” about NAT, you add a static forwarding of external port range 16384-16482 for RTP.  This however requires the configuration on the NAT router for each SIP phone.

  • On the edge router
    • NAT/QoS > Port Range Forwardin
      • voip rtp, 16384-16482, UDP, 10.0.1.10 (or whatever the addr for the VoIP adapter)
  • On the VoIP adapter
    • Voice > SIP
      • NAT Support Parameters (documentation)
        • EXT RTP Port Min = 16384  (minimal RTP port used to replace private UDP port specified in SDP “m=” line)

solution 3: outbound proxy

For an example message trace refer to SIP/SDP trace using MilkFish as outbound proxy.  If incoming calls are unreliable, read this comment.

solution 4: ICE

This solution takes advantage of an external server to discover the external addr/port or to relay RTP streams.  It uses the Interactive Connectivity Establishment protocol (ICE, RFC 5245), that in turn relies on:

  • Traversal Using Relays around NAT (TURN, RFC5766) to both discover external addr/port and relay messages.  When no TURN server is available it falls back to:
  • Session Traversal Utilities  for NAT (STUN, RFC5389) to discover external addr/port

ICE allows the end-points (AKA agents) to discover enough information about their topologies to potentially find one or more paths by which they can communicate.  It prioritizes candidate pairs and checks the candidate pairs.  In the special case, where both end-points are behind NAT, it relies on both end-points first sending STUN requests for candidate pairs to create the binding.

Debugging and other notes

  • on the SPA2102:
    • Voice > Line 1 > SIP Settings > SIP Debug Option = full
    • Voice > System > Miscellaneous Settings > Debug Server = yoursyslogserver
  • or, use Wireshark
    • filter: port 5060 or udp portrange 16384-32767

For information on improving SIP routing using sipsorcery.com read these instructions.

Quality of Service (QoS) [work in progress]

VoIP phone calls are very sensitive to delay and jitter.  We are the mercy of the network for most of the route, but we do have control over our often congested edge router.  There the outgoing VoIP traffic has compete with other network traffic for limited bandwidth.  By applying simple traffic shaping we can prioritize VoIP and other interactive traffic such as SSH.

Suddenly, the old Type-of-Service (ToS) field in the IPv4 becomes more meaningful.   This paragraph describes how to use this field to label traffic types, and how to shape the outgoing traffic based on this field.  Most Linux and Windows applications use ToS for QoS.

Your DSL/Cable modem will likely relabel the QoS based on your service agreement.  Comment QoS methods for the core network are MPLS or Cisco’s Differentiated Services (DiffServ).  For more details read this overview or the DiffServ HOWTO.

Our DD-WRT edge router has priority based queuing enabled by default.  It also uses the VEGAS congestion control

netfilter rules (to be added)

…..

The priority based queuing discipline is very rudimentary.  High priority traffic will starve lower priorities.  The Linux Advanced Routing and Traffic Control HOWTO gives lots of ideas for improvements.

Google Voice probably gave you the choice of

·A Google voice number, that offers the full feature set.  This is what most people call “Google Voice”.  I will explain this more detail below.

·Using Google voice mail on your cell phone.

Google Voice (GV) is an interconnect for the old phone system (PSTN).

·Incoming calls: Incoming calls on your GV number are routed to one or more other phone numbers.  I.e. your house landline phone and a cell phone.  If the call is left unanswered, it rolls over to their voice mail.  When enabled, it does voice recognition and send you and email/SMS with the text.  You can also listen to the voice mail using the web interface.

·Outgoing calls: you setup a call through their web interface or by dialing your own number.  They first call your phone, and then call the party that you are calling.  They then connect the two calls.

While this works well, people like me want to replace their landline with VoIP.

I expect Google Voice to offer this functionality in the future, but meanwhile this can be done by using a VoIP/PSTN interconnect such as sipgate.com.  The interconnect with give you a phone number that you can then register with Google Voice.  At home, you put a VoIP adapter between the Internet and your phone.

·Incoming calls: arrive at Google voice.  They will forward the call to your interconnect phone number that then rings your VoIP connected phone.

·Outgoing calls: you setup a call through the Google Voice  web interface or by dialing your own number.  They first call your phone, and then call the party that you are calling.  They then connect the two calls.

While this works, I wanted to be able to just dial the number instead of dealing with a web interface.  This can be done by enlisting yet-another service: sipsorcery.com.  This service sits in between your VoIP adapter and your VoIP/PSTN interconnect (sipgate.com).

·Incoming calls: arrive at Google voice.  They will forward the call to your interconnect phone number (sipgate.com) that in turn forwards the call to sipsorcery.com that then rings your VoIP connected phone.

·Outgoing calls: you just dial the number on your VoIP connected phone.  Sipsourcery requests Google voice to setup the call.

Sorry for the long story.  There are points of failure, but appears to work well for me (so far).  One drawback is that 911.  They will not get your location., except if you enable E911, something that I have not tried yet.

Comments are closed.