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 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 ;-)
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.
The aim of the 0cpm project is to make SIP over IPv6 possible, useful and commonplace. This is done in a few sub-projects:
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:
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!
| GIT tag | Release notes |
|---|---|
| TODO | Resolve memory leakages, support non-5060 ports, test more SIP message types. Test differently counting RTP ports on the sides. Test call referrals. |
| Trunk | |
| 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, and especially the underlying OSIP2 layer seems a bit unreliable (due to incomplete documentation). 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, 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.
The source code can also be obtained at git://git.0cpm.org/sipproxy64/. 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 192.0.2.70 \ # Listen to an IPv4 address
-L 2001:db8:666::3 \ # Listen to an IPv6 address
192.0.2.1=2001:db8:666::5060 # 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 192.0.2.70 \ # Listen to an IPv4 address
-L 2001:db8:666::3 \ # Listen to an IPv6 address
192.0.2.86=2001:db8:666::86 \ # Link phone #1 to its IPv6 counterpart
192.0.2.87=2001:db8:666::87 \ # Link phone #2 to its IPv6 counterpart
192.0.2.88=2001:db8:666::88 # 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 192.0.2.70 as its outgoing proxy, and an additional parameter would have to be configured:
sipproxy64 -l 192.0.2.70 \
-L 2001:db8:666::3 \
-U 2001:db8:456::12 \ # Uplink to IPv6 SIP provider
192.0.2.86=2001:db8:666::86 \
192.0.2.87=2001:db8:666::87 \
192.168.2.88=3001:333:666::88
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.