Site Navigation:
Current Release: 0.7.2


Valid HTML 4.01!

 
 

Siproxd - a masquerading SIP Proxy Server


OVERVIEW

Siproxd is a proxy/masquerading daemon for the SIP protocol. It handles registrations of SIP clients on a private IP network and performs rewriting of the SIP message bodies to make SIP connections work via an masquerading firewall (NAT). It allows SIP software clients (like kphone, linphone) or SIP hardware clients (Voice over IP phones which are SIP-compatible, such as those from Cisco, Grandstream or Snom) to work behind an IP masquerading firewall or NAT router.

SIP (Session Initiation Protocol, RFC3261) is the protocol of choice for most VoIP (Voice over IP) phones to initiate communication. By itself, SIP does not work via masquerading firewalls as the transfered data contains IP addresses and port numbers. There do exist other solutions to traverse NAT existing (like STUN, or SIP aware NAT routers), but such a solutions has its disadvantages or may not be applied to a given situation. Siproxd does not aim to be a replacement for these solutions, however in some situations siproxd may bring advantages.

PREREQUISITES

Siproxd runs on a variety of Unix derivates. Currently known to work are: Siproxd requires the libosip2 package available at www.gnu.org.

HOW TO GET STARTED

Either download a ready made package for your favorite distribution (there are quite some around) or do it from scratch: And of course: Please read the documentation and the FAQ!

PROBLEM REPORTING

If you encounter problems/crashes and ask for support, please include as much information as possible. Very helpful is a debug log that has been recorded at the time of the misbehavior. Also include the exact versions of the siproxd package and libosip2 that you are using. You should also include your siproxd.conf.

The easiest way to generate a debug log is:

  1. make sure siproxd is not started as daemon.
    -> 'daemonize = 0' in the config file.
  2. start siproxd:
    $ ./siproxd -d -1 2>debug.log
  3. reproduce the error
  4. include the file debug.log in your error report.
Since Version 0.5.10 there also exists the possibility to obtain the debug log remote via TCP (useful if running siproxd on an embedded system). To enable this feature, edit the configuration file and set 'debug_port' to a free TCP port number (e.g. 5050). Then (after starting siproxd) you can connect from any remote client to this TCP port (e.g. using netcat) and all the debug output will be sent via network:
  1. edit configuration file:
    -> 'daemonize = 1' have siproxd started as daemon
    -> 'silence_log' should be set to 1
    -> 'debug_level = -1'
    -> 'debug_port = 5050' (or any other TCP port you like)
  2. have siproxd started the usual way
  3. connect from a remote machine and write into a file:
    $ netcat <IP_of_siproxd> <port> > debug.log
  4. reproduce the error
  5. include the file debug.log in your error report.
If siproxd crashes, a stack backtrace usually is helpful to me:
  1. start siproxd in the debugger (daemonize set to 0):
    $ gdb ./src/siproxd
    (gdb) set args -c /path/to/siproxd.conf
    (gdb) run
  2. reproduce the crash
  3. use gdb to print the stack backtrace:
    (gdb) info thread
    ...
    (gdb) bt
    #0 0x400ec9ee in __select ()
    #1 0xbffff6f8 in ?? ()
    #2 0x804a5c2 in main (argc=3, argv=0xbffffc54) at siproxd.c:186
    #3 0x4005bcb3 in __libc_start_main (main=0x804a30c <main>, argc=3,
    argv=0xbffffc54, init=0x8049a08 <_init>, fini=0x804edac <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffc4c)
    at ../sysdeps/generic/libc-start.c:78
    (gdb)
  4. copy-paste all the output and include it in your error report.

SENDING A PATCH

If you send a patch, please make the diff using "diff -Naur" and include the version of siproxd you used to patch. This makes it a lot easier for me to merge it.

WHAT SIPROXD DOES

Siproxd's purpose is to act as an SIP proxy for SIP softphones/hardphones located behind an masquerading router (NAT). It will rewrite SIP messages to allow a SIP phone to communicate to a counterpart that is located in the Internet. Check the scenarios drawn below. 
Scenario 1
----------

 private IP address range             :          Internet
 10.0.0.x                             :          (public IP address range)
                                      :
                                      :         foo.bar.org
 +-------------+               +--------------+
 !             !.10         .1 ! masquerading ! publicIP
 ! IntHost     !---------------! Firewall     !------------>>  
 !             !               !              !
 +-------------+               +--------------+
                           eth0       :        ppp0


Scenario 2
----------

 private IP address range             :          Internet
 10.0.0.x                             :          (public IP address range)
                                      :
                                      :     foo.bar.org
 +-------------+               +--------------+              +--------------+
 !             !.10         .1 ! masquerading ! publicIP     ! external SIP !
 ! IntHost     !---------------! Firewall     !------------>>! Registrar    !
 !             !               !              !              !              !
 +-------------+               +--------------+              +--------------+
                           eth0       :        ppp0
IPCHAINS:
Firewall rules for incoming traffic:
IPTABLES:
Firewall rules for incoming traffic: The first line will allow incoming SIP traffic (UDP port 5060). The second line will allow incoming RTP traffic on the ports 7070-7080 (the default port range used by siproxd for incoming RTP traffic).

LIMITATIONS

You are welcome to send us patches that implement new functionality.

CONTACTS

Please feel free to contact the author to: There is a siproxd mailing list available on sourceforge.

CREDITS

Thanks to sourceforge.net for providing the distribution platform and infrastructure.