6 ms·

We been doing this at Vonage since 2001. This was our "secrete sauce", since at the time there wasn't a well documented or an industry standard on how to do th

We been doing this at Vonage since 2001. This was our "secrete sauce", since at the time there wasn't a well documented or an industry standard on how to do this. Eventually SIP through NAT papers and RFC's did appear, but we already had our way of doing it that was just as effective. We found that renewing the NAT entry at a rate of once per 20 seconds was good enough. This made it work through all the routers and gateways we came across. EDIT: SIP is short for Session Initiation Protocol. Its the protocol used to connect VOIP phone calls. We used UDP. SIP's standard port is 5060 and 5061. We had to switch to port 10,000 (any port other than the standard) because too many high end routers and gateways would manipulate our packets. These routers were trying to implement SIP through NAT on their own. I applauded their efforts but it caused problems for us. I still remember the day that I took it upon myself to change production to use port 10,000. I was really scared I was going to break something but everything worked out in the end.

cr0sh 9y ago
I used to be a Vonage customer (service was nice, as long as my Cox internet was working - but I shut it off after my wife and I finally both had cell phones - this was at least a decade or more ago). I had always wondered how you guy's were doing it, but I had always thought that the router Vonage handed out was something special that used its own reserved ports or something that wasn't easily visible. I never looked into it deeper. It's interesting that instead something like this "hole punching" technique was used. I've heard about the technique before, but never investigated it before...
- jmartrican 9y ago
  The solution was very simple. It came down to this. - SIP end points register every so often. Each registration had a TTL. We set the TTL to 20 seconds. This actually leads to a registration every 16 seconds, since SIP end points register at 80% into their TTL. - When a SIP end point reigsters, do not register the end point at the IP:port that it is advertising int he SIP Registration message. Instead use the source IP and port of the IP/UDP packet/datagram. - Inbound calls to that SIP end point must go through the server that the SIP end point registered with and it must use the destination port (10,000) as the source port. We need to match the NAT entry in the router. - When a phone call comes in for that end point, send the SIP Invite message to source IP:port of the SIP end point. Since the device is registering every 16 sec, there is sure to be a NAT entry in the router to allow our packets into the network and routed to the SIP end point. It is vital that we use the same server that the SIP end point registered with.
  - Drdrdrq 9y ago
    Everything is simple if you know what you are doing. Kudos! I had my own share of adventures with SIP across NAT so I know it must have been lots of experimentation and studying to find this simple solution.
    - gerdesj 9y ago
      It sounds like they are describing "symmetric RTP" which is still a common way to get SIP n RTP to work. Another way is to use a VPN and route the blasted things - which was/is a classic cop out with a gloss of security added in. Then you got to fix the pain of subtly incompatible IPSEC implementations instead. Strangely enough all VoIP phones with a VPN built in (that I know of) use OpenVPN and not IPSEC. OpenVPN uses a single port which may be 1194/udp or not. Another "fix" to SIP - a protocol that works just as successfully over NAT as ftp (mmm active or passive? 1:1 NAT bodge/fix? etc etc) - is to mix the control and data into one stream: eg IAX(2). IAX uses a single well known destination port (4569/udp) which is as easy to implement as DNS or NTP, which are both generally UDP but DNS can require TCP, through a NAT. IAX can make a fine Sometimes folk decide to run SIP over TCP instead of UDP and may even decide to run that inside a TCP tunnel eg OpenVPN over TCP. That's fine until you discover how TCP inside TCP can result in exponential standoffs when network conditions are sub-optimal. That can really bugger up voice traffic that really needs sub 100ms point to point latency to be acceptable. Then there is dealing with packet fragmentation if changes of media require it and of course the fact that TCP packet streams can arrive out of order and be re-assembled. That latency wont worry your web browser but it makes voice sound horrid.
      - adamfisk 9y ago
        Lots of confusion on this thread. SIP never handles actual voice traffic. It is just a signaling protocol used to initiate the ICE process of actually establishing the connection, either a direct p2p connection or a relayed connection using TURN when the NATs can't be traversed. That's when traffic is typically UDP, as it's easier to traverse NATs with UDP. The transport SIP uses is largely irrelevant, although it's pretty silly for it to use anything but TCP because reliability of sending the offer and the answer is pretty important, and they can be sent in multiple packets.

cr0sh 9y ago

I used to be a Vonage customer (service was nice, as long as my Cox internet was working - but I shut it off after my wife and I finally both had cell phones - this was at least a decade or more ago). I had always wondered how you guy's were doing it, but I had always thought that the router Vonage handed out was something special that used its own reserved ports or something that wasn't easily visible. I never looked into it deeper. It's interesting that instead something like this "hole punching" technique was used. I've heard about the technique before, but never investigated it before...

jmartrican 9y ago
The solution was very simple. It came down to this. - SIP end points register every so often. Each registration had a TTL. We set the TTL to 20 seconds. This actually leads to a registration every 16 seconds, since SIP end points register at 80% into their TTL. - When a SIP end point reigsters, do not register the end point at the IP:port that it is advertising int he SIP Registration message. Instead use the source IP and port of the IP/UDP packet/datagram. - Inbound calls to that SIP end point must go through the server that the SIP end point registered with and it must use the destination port (10,000) as the source port. We need to match the NAT entry in the router. - When a phone call comes in for that end point, send the SIP Invite message to source IP:port of the SIP end point. Since the device is registering every 16 sec, there is sure to be a NAT entry in the router to allow our packets into the network and routed to the SIP end point. It is vital that we use the same server that the SIP end point registered with.
- Drdrdrq 9y ago
  Everything is simple if you know what you are doing. Kudos! I had my own share of adventures with SIP across NAT so I know it must have been lots of experimentation and studying to find this simple solution.
  - gerdesj 9y ago
    It sounds like they are describing "symmetric RTP" which is still a common way to get SIP n RTP to work. Another way is to use a VPN and route the blasted things - which was/is a classic cop out with a gloss of security added in. Then you got to fix the pain of subtly incompatible IPSEC implementations instead. Strangely enough all VoIP phones with a VPN built in (that I know of) use OpenVPN and not IPSEC. OpenVPN uses a single port which may be 1194/udp or not. Another "fix" to SIP - a protocol that works just as successfully over NAT as ftp (mmm active or passive? 1:1 NAT bodge/fix? etc etc) - is to mix the control and data into one stream: eg IAX(2). IAX uses a single well known destination port (4569/udp) which is as easy to implement as DNS or NTP, which are both generally UDP but DNS can require TCP, through a NAT. IAX can make a fine Sometimes folk decide to run SIP over TCP instead of UDP and may even decide to run that inside a TCP tunnel eg OpenVPN over TCP. That's fine until you discover how TCP inside TCP can result in exponential standoffs when network conditions are sub-optimal. That can really bugger up voice traffic that really needs sub 100ms point to point latency to be acceptable. Then there is dealing with packet fragmentation if changes of media require it and of course the fact that TCP packet streams can arrive out of order and be re-assembled. That latency wont worry your web browser but it makes voice sound horrid.
    - adamfisk 9y ago
      Lots of confusion on this thread. SIP never handles actual voice traffic. It is just a signaling protocol used to initiate the ICE process of actually establishing the connection, either a direct p2p connection or a relayed connection using TURN when the NATs can't be traversed. That's when traffic is typically UDP, as it's easier to traverse NATs with UDP. The transport SIP uses is largely irrelevant, although it's pretty silly for it to use anything but TCP because reliability of sending the offer and the answer is pretty important, and they can be sent in multiple packets.