SIPproxy64 Code
Status: Beta
Brought to you by:
vanrein
Menu
▾
▴
Tree [83bc83] master / History
Rick van Rein
Rick van Rein
Read Me
========================================== README for SIP proxy between IPv4 and IPv6 ========================================== This software acts as a proxy between SIP phone networks on IPv4 and IPv6. It will hardly do a thing but translate addresses and cause its built-in RTPproxy64 to care for the media session in a corresponding fashion. Running the proxy ================= Information about running SIPproxy64 is contained in the manpage sipproxy64.man and this document is about building, installing and understanding the source code. Building requirements ===================== * POSIX * wget Note: The build script will show a list of RFCs containing SIP headernames that have not yet been implemented. The package lists the RFCs whose headers are parsed for URIs that are then mapped. Some headers do not contain URIs, in which case mapping them is a trivial identity function. The list of RFCs unprocessed is derived from a dynamic download from IANA, using wget. This means that a package that is current when published will show its shortcomings at a later date. Running requirements ==================== * POSIX operating system (such as Linux) * direct-routable IPv6 (not Teredo / Miredo) and IPv4 The SIPproxy64 is a stand-alone application, with the exception of a few simple library dependencies. It includes its own RTPproxy64 to make RTP traffic cross between IPv4 and IPv6. You need IPv6 connectivity to be able to do this. Note that Teredo and its Linux-implementation Miredo are not suitable, as these only work for client/server connections. If you used that for SIP connectivity over IPv6, you would end up in NAT traversal problems in your IPv6 tunnel, very much like you do with SIP over IPv4! Teredo and Miredo use a special IPv6 prefix 2001:0::/32 and so are easy to recognise. Mapping addresses ================= The conceptual idea of this proxy is that each phone appears to have an address in both IPv4 and IPv6 address families. In situations where no IPv6 address is currently present, the proxy will pick up any traffic that arrives on the IPv6 address, map addresses contained in SIP messages and forward them. In addition, sessions will be passed through its built-in RTPproxy64 and be translated between address families as well. Each phone has its own address in both spaces. So traffic forwarded to a particular UDP port on a phone's simulated IPv6 address can simply be proxied to the same port on the phone's actual IPv4 address. The traffic can travel in both directions through the proxy; aside from the media sessions that are passed through RTPproxy64, the proxy does not keep state. The media traffic all goes through a single IPv4 address and a single IPv6 address. The UDP port on each will be allocated by RTPproxy and handed back to the proxy for editing SIP messages before passing them on. To setup an IPv4 phone for registration at an IPv6 registrar, the mapping for those phones must be created as an explicit mapping. Then, if a SIP message comes in destined for a particular IPv4 address, this address will be mapped to the proper IPv6 address and the SIP message is then passed on. Rewriting headers ================= Headers are changed when they are passed through the proxy. The following is done: * The header ``Max-forwards`` is lowered by one, and if it reaches zero, the SIP message is discarded. * The host in ``From``, ``To``, ``Contact`` headers as well as the ``URI`` are changed from the address in one address family to the matching address in the other address family. This will only work inasfar as these are IP addresses. Names are left untouched. * The ``User-agent`` header is changed to describe this SIP proxy. * A ``Via`` header is inserted to ensure that traffic continues to travel through this proxy. If needed, a ``Via`` header referring to the proxy is removed, and/or a ``Via`` header is used to forward traffic to the next hop in the SIP transaction. * Two ``Record-Route`` headers are inserted; one for the incoming side of SIPproxy64, one for its outgoing side. This makes the proxy reachable from both address families, for any future transactions in the dialog. If incoming traffic came from a generic address (not a known phone and not an uplink), there will be an addtional ``received=`` parameter to the incoming side's header, indicating where to forward return transactions within the dialog. * The and ``m=`` and ``c=`` lines in any SDP attachment are parsed to find any addresses in them; these are then mapped from one address family to the pairing address in the other address family. * The terms ``IP6`` and ``IP4`` are exchanged in the and ``m=`` and ``c=`` lines in SDP attachments. Reporting problems ================== As most open source software, this is a work of love, but the time available for it is less than infinite. Unless you were to hire me to solve your problem, your chances will improve if you prepare any problems as well as you possibly can. Most of SIPproxy64's behaviour is stateless, so it should be easy to reproduce any problems. If you can't, you should really wonder why. If you can reproduce the problem, then please setup a test for it under t/sometestname and supply the expected output. You should try to not rely on your own IP-addresses for the test, but rather make the daemon bind to local addresses as much as possible. You may want to anonymise your data if it contains your IPs and phone numbers; passwords do not appear in SIP traffic. It is often worthwhile trying to simplify the problem. Not only will it make the test more powerful, but it also makes you focus on your problem, and that may cause you to resolve it on your own! Make sure that the test is reproduced in the test system as well. Then send me a bug report, and be sure to include the test directory so I can easily reproduce the problem and work towards its resolution. The test will be included in the distribution, so as to ensure that it does not occur again in the future.
