10.0.0.21 Git - sipproxy64/blob - README

   1 ==========================================
   2 README for SIP proxy between IPv4 and IPv6
   3 ==========================================
   4
   5 This software acts as a proxy between SIP phone networks on IPv4 and IPv6.
   6 It will hardly do a thing but translate addresses and cause its built-in
   7 RTPproxy64 to care for the media session in a corresponding fashion.
   8
   9
  10 Running the proxy
  11 =================
  12
  13 Information about running SIPproxy64 is contained in the manpage
  14 sipproxy64.man and this document is about building, installing and
  15 understanding the source code.
  16
  17
  18 Building requirements
  19 =====================
  20
  21 * POSIX
  22 * libosip2, libosipparser2
  23
  24
  25 Running requirements
  26 ====================
  27
  28 * a POSIX operating system (such as Linux)
  29 * direct-routable IPv6 (not Teredo / Miredo)
  30 * libosip2, libosipparser2
  31
  32 The SIPproxy64 is a stand-alone application, with the exception of a few
  33 simple library dependencies.  It includes its own RTPproxy64 to make
  34 RTP traffic cross between IPv4 and IPv6.
  35
  36 You need IPv6 connectivity to be able to do this.  Note that Teredo and
  37 its Linux-implementation Miredo are not suitable, as these only work for
  38 client/server connections.  If you used that for SIP connectivity over
  39 IPv6, you would end up in NAT traversal problems in your IPv6 tunnel,
  40 very much like you do with SIP over IPv4!  Teredo and Miredo use a
  41 special IPv6 prefix 2001:0::/32 and so are easy to recognise.
  42
  43
  44 Mapping addresses
  45 =================
  46
  47 The conceptual idea of this proxy is that each phone appears to have an
  48 address in both IPv4 and IPv6 address families.  In situations where no
  49 IPv6 address is currently present, the proxy will pick up any traffic
  50 that arrives on the IPv6 address, map addresses contained in SIP messages
  51 and forward them.  In addition, sessions will be passed through RTPproxy
  52 and will be translated between address families as well.
  53
  54 Each phone has its own address in both spaces.  So traffic forwarded to
  55 a particular UDP port on a phone's simulated IPv6 address can simply be
  56 proxied to the same port on the phone's actual IPv4 address.  The traffic
  57 can travel in both directions through the proxy; aside from the media
  58 sessions that are passed through RTPproxy, the proxy does not keep state.
  59
  60 The media traffic all goes through a single IPv4 address and a single
  61 IPv6 address.  The UDP port on each will be allocated by RTPproxy and
  62 handed back to the proxy for editing SIP messages before passing them
  63 on.
  64
  65 To setup an IPv4 phone for registration at an IPv6 registrar, the mapping
  66 for those phones must be created as an explicit mapping.  Then, if a
  67 SIP message comes in destined for a particular IPv4 address, this address
  68 will be mapped to the proper IPv6 address and the SIP message is then passed
  69 on.
  70
  71
  72 Listening for traffic
  73 =====================
  74
  75 TODO: Which addresses to listen to?
  76
  77 * IPv4 -- any address (or a router address), port 5060
  78 * IPv6 -- only if part of the address map and locally defined
  79
  80 TODO:   Possibly use the first ipv4/ipv6 pair as proxy address definition;
  81         Then, if traffic is forwarded to those, they will always be picked
  82         up.  For the other addresses, introduce a local binding for IPv6 only,
  83         assuming that the phones will listen on their IPv4 addresses.
  84
  85
  86 Rewriting headers
  87 =================
  88
  89 Headers are changed when they are passed through the proxy.  The following
  90 is done:
  91
  92 * The header ``Max-forwards`` is lowered by one, and if it reaches zero,
  93   the SIP message is discarded.
  94
  95 * The host in ``From``, ``To``, ``Contact`` headers as well as the ``URI``
  96   are changed from the address in one address family to the matching address
  97   in the other address family.  This will only work inasfar as these are
  98   IP addresses.  Names are left untouched.
  99
 100 * The ``User-agent`` header is changed to describe this SIP proxy.
 101
 102 * A ``Via`` header is inserted to ensure that traffic continues to travel
 103   through this proxy.  If needed, a ``Via`` header referring to the proxy
 104   is removed, and/or a ``Via`` header is used to forward traffic to the next
 105   hop in the SIP transaction.
 106
 107 * The ``o=`` and ``m=`` and ``c=`` lines in any SDP attachment are parsed to
 108   find any addresses in them; these are then mapped from one address family to
 109   the pairing address in the other address family.
 110
 111 * The terms ``IP6`` and ``IP4`` are exchanged in the ``o=`` and ``m=`` and ``c=``
 112   lines in SDP attachments.
 113
 114