SIPproxy64 -- Bridging SIP telephony between IPv4 and IPv6

If IPv4 and IPv6 are different universes or different dimensions, then by that metaphor SIPproxy64 is a wormhole between them. In order to make a SIP phone in the other universe reachable, it listens to a local IP address that serves as a proxy in this universe to get to the phone in the other. In the other universe, it sends from a local IP address in that universe, to which it listens for responses to be warped back to this universe.

SIPproxy64 is a proxy for SIP and RTP traffic between IPv6 and IPv4. It simply exchanges IPv4 and IPv6 addresses and passes on the traffic to the other address family. SIPproxy64 has its own little RTPproxy64 built in, so it is fully self-contained and specific to the task of connecting SIP and RTP between IPv4 and IPv6.

Use this package to make IPv4-only phones or PBXs visibible to IPv6 callers, to call IPv6-only service providers from an IPv4 phone, and so on. SIPproxy64 is designed to have a small footprint and be as simple as possible, so it is easy to add IPv6 support to your SIP setup. Even though such things could be done with SER / OpenSIPS with RTPproxy, this is probably too difficult for non-telco networks. Asterisk with IPv6 may however be another option to consider.

SIPproxy64 is small by design, making it ultimately suitable for embedding:

  • The 32-bit binary size is 37 kB
  • The only dependencies are and
  • This relates to the current version under test, 0.5

Recent changes

We have made a great leap forward in the end of 2012, making the software much more reliable, although the great overhaul of its internals do mean that new bugs may be found. What has changed is:

  • support for arbitrary SIP ports, not just port 5060
  • HUP signals will stop SIP listening, so the daemon can be restarted; RTP will remain active as long as it takes
  • dropped dependencies on libosip2, putting an end to memory leaks
  • using our own parser led to much more problem-driven structure, rather than parser-driven structure
  • we can now process any SIP facility defined in any RFC; extension is easy
  • a --wrapper option can leave processing of Contact: headers to a wrapper
  • multiple media streams can be setup in a single SIP invitation
  • output is now written to system logs instead of just to stderr
  • a complete test system has been added, including all RFC 3261 messages
  • a dedicated test mode dumps SIP messages on stdout instead of sending them

These radical improvements were funded by NLnet and OpenFortress.

Open Source

SIPproxy64 is open source software. The code resides under GPL, text and graphics under Creative Commons License.

First and foremost, we want this software to be used. If we ever want to get rich over trivialities, we'll get some US software patents ;-)

Project intention

The intention is to make it straightforward for the IPv4-only majority in the SIP world to step up to IPv6, without much effort or without having to touch their current phone configuration. Phone systems are complex, and it is easier to add an external interface than to touch what is often considered "carved in stone" configurations.

For IPv4-only hardware (like SIP phones and PBXs) this is currently the only workable path to unleash their powers over the direct connections of IPv6.

For other solutions, this may provide an opportunity to try out IPv6 for SIP. You should understand that your call quality will vary with the quality of your IPv6 roll-out. If you have no direct access to IPv6 yet, you may want to try the excellent tunnels of SIXXS.

Project context

The aim of the 0cpm project is to make SIP over IPv6 possible, useful and commonplace. This is done in a few sub-projects:

  • Transitional techniques, like SIPproxy64
  • Alternative open source firmware for network telephones
  • A calling network that is IPv6-only and attractive to end-users

The current market situation shows mostly lock-in schemes by vendors. Furthermore, phone manufacturers and networks seem to be paralising each other and are stuck to minimal changes in a working model, and are forever waiting until "the others" make a first move. We like to be part of those "others" by way of our open source software that will be freely available to vendors who do want to progress. And we will build a telephony network to match.

The technology that we are keen on seeing in mainstream SIP applications is:

  • SIP and RTP over IPv6 -- it may be best to drop IPv4 altogether
  • ZRTP for end-to-end encryption -- recently accepted for RFC publication
  • DNSSEC -- to a level that is practical in an embedded device
  • ITAD and ENUM -- direct connectivity schemes over the Internet
  • Phones able to exchange with other RTP nodes' direct address/port

Breaking through the impaired market state is not easy, but end users have seen so little of SIP yet, and IPv6 is so supportive of a more useful mode of operation for SIP, that the combination is appealing to all: being able to stream 3D video by detaching from their provider's RTP proxy is attractive enough to teach end users to ask their providers for IPv6!


Relating to v0.5:

  • This version is up for test. Please try and report back to us.
  • You are free to use any SIP port, both for IPv4 and IPv6. Enclose IPv6 addresses in square brackets to avoid syntactical ambiguity.
  • All extensions to SIP are supported, but not all scenarios have been tested in real life.
  • If you find anything wrong, please read t/README for submission guidelines -- basically, please construct a test to simplify reproduction.
  • Made by Rick van Rein, rick at openfortress dot Netherlands.
  • Thanks to NLnet for funding the development in part.

Up to v0.3:

  • The tool has shown to work well in various modes of operation
  • You MUST only use port 5060 for all SIP communication (to be fixed later)
  • You SHOULD NOT rely on multi-homed IPv6 to forward RTP properly
  • Not all extensions to SIP are supported, but plain calls, registration and other common facilities work reliably
  • Made by Rick van Rein, rick at openfortress dot Netherlands
  • Many thanks for testing help to Henri Manson from Mansoft dot Netherlands
GIT tag Release notes
v0.5 Support arbitrary SIP ports. Use a better SIP parser. Better internal structure (not parser-driven). Resolve memory leakages. Support all SIP facilities available in RFCs. Comprehensive testing system. Logging facilities.
v0.3 Survive SIP PING. Survive rebooting GrandStream. Daemon mode. SIGHUP: Detach SIP but support RTP until it terminates. Phones at same side of same SIPproxy64 can connect through it.
v0.2 Record-Route header order problem in osip2 solved. Resolved crashes on NOTIFY/other without From tag.
v0.1 IPv4-to-IPv6 and IPv6-to-IPv4 calls: REGISTER, INVITE, CANCEL, BYE. Access to uplinks. RTPproxy64 (symmetric RTP). Local calls and calls through IPv4-IPv6-IPv4 may fail.

The software is young, but it has shown to work and be stable.

The current version in trunk does not support all SIP extensions yet, but we have an internal version that should support all SIP RFCs and be really straightforward to extend with future ones. It is still less than 50 kB in size, and therefore suitable for embedded environments like routers.

The underlying OSIP2 parser used in trunk seems a bit unreliable (due to incomplete documentation). Its memory leaks can be overcome by an occasional restart in a cronjob; this will not cause any downtime or disruption on running streams. The internal version switches to a new parser of our own design, which is akin to what is done in popular SIP software such as OpenSIPS.

If you have any problems, please let me know. What is especially useful is to show me the message that failed on you, together with the commandline that your SIPproxy64 runs with. Problems are very consistent due to the almost-stateless nature of SIPproxy64, so it is usually a matter of tracking down a false assumption made about the parser and/or the "proper" behaviour of a SIP device, and then finding the most elegant way to bypass that.


This project is registered with SourceForge as SIPproxy64, where it has a managed git browsing interface and users forum. You can also download the source code for trial version 0.5 from this website.

The source code can also be obtained at git:// Note that I haven't bothered to setup IPv4 access -- as the tool will require you to have IPv6 setup anyway ;-)

For the sake of convenience, but without any guarantees in the early phases, there may also be some Debian packages available:


VoIP router export: VoIP routers usually export a SIP service to the LAN. The dial-out function is usually protected with a password (is it a strong one?) but calling your own number, or an internal number, is usually permitted without password for any LAN-side traffic. You can share this access point to your old-school telephones by calling to that SIP server. You would share the router's SIP functions from your IPv6 access router as follows:

sipproxy64 -l \                  # Listen to an IPv4 address
           -L 2001:db8:666::3 \             # Listen to an IPv6 address
      # Link router IP to its IPv6 counterpart

You would need to setup the "fake" IPv6 address for the router, and call the phone numbers available on the LAN @ that fake IPv6 address.

IPv4-only SIP phones: Many current SIP-phones are IPv4-only. Until these have all been overtaken by open source firmware ;-) they can enter the IPv6 realm through a mapping on a proxy that has a "fake" IPv6 address and pairs them with each phone:

sipproxy64 -l \                    # Listen to an IPv4 address
           -L 2001:db8:666::3 \               # Listen to an IPv6 address
  \      # Link phone #1 to its IPv6 counterpart
  \      # Link phone #2 to its IPv6 counterpart
         # Link phone #3 to its IPv6 counterpart

As before, there is a "fake" IPv6 address created to cover the phone. It would also be possible to cover IPv6-only phones based on a "fake" IPv4 address, because the tool is perfectly symmetrical in its IPv4 and IPv6 behaviour.

Dial-out over IPv6: The example above can be extended to support dial-out over IPv6, even with an IPv4-only phone. To do this, a phone would have to use the SIPproxy64 address as its outgoing proxy, and an additional parameter would have to be configured:

sipproxy64 -l \
           -L 2001:db8:666::3 \
           -U 2001:db8:456::12 \              # Uplink to IPv6 SIP provider

As before, there is a -u option for an IPv4 uplink, mirrorring the -U on the IPv6 side. The uplinks are generally used for undirected traffic from the other address family, usually from a fresh INVITE arriving on the -l or -L interfaces.

Traffic sent from a known phone will be forwarded from the phone's "fake" IP on the other side. Traffic sent from anywhere else is forwarded from the general -l or -L listen address.