220 lines
10 KiB
Plaintext
220 lines
10 KiB
Plaintext
|
|
|
|
Still under construction...
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: What softphone work with siproxd?
|
|
|
|
A: The goal is that every softphone (that is SIP compliant) should be
|
|
able to work via siproxd. Tested and/or reported to work so far:
|
|
- linphone (0.9.0)
|
|
- kphone (1.0.2)
|
|
- MSN Messenger
|
|
- Grandstream BudgeTone series (only with IPCHAINS based RTP proxy)
|
|
---------------------------------------------------------------------------
|
|
Q: Siproxd's RTP proxying does only work for incoming RTP audio data.
|
|
Shouldn't it also proxy outgoing RTP data?
|
|
|
|
A: This is the correct behaviour. Incoming RTP traffic
|
|
is handled by siproxd's RTP proxy. However, outgoing RTP traffic has
|
|
to be handled by the firewall (IP masquerading).
|
|
---------------------------------------------------------------------------
|
|
Q: How do I setup IP masquerading for the outgoing RTP traffic?
|
|
|
|
A: if you are using 'ipchains' it is a firewall rule like the following:
|
|
|
|
# ipchains -A forward -i ppp0 -j MASQ -s 10.0.0.0/24 -d 0.0.0.0/0
|
|
|
|
This will set up IP masquerading for all local hostx (10.x.x.x) to
|
|
the Internet (connected on ppp0). Read the ipchains documentation
|
|
for details.
|
|
More recent Linux Kernels (2.4.x) may use 'iptables' instead of
|
|
'ipchains'. Check the corresponding documentation for details
|
|
how to configure IP masquerading there.
|
|
---------------------------------------------------------------------------
|
|
Q: Is it possible from a remote computer to call the inbound computer?
|
|
|
|
A: Yes, see also next question.
|
|
---------------------------------------------------------------------------
|
|
Q: What SIP address must the remote computer use to make a call?
|
|
|
|
A: Scenario
|
|
--------
|
|
|
|
private IP address range : Internet
|
|
10.0.0.x : (public IP address range)
|
|
:
|
|
: foo.bar.org xxx.org
|
|
+-------------+ +--------------+ +-------------+
|
|
! !.10 .1 ! masquerading ! publicIP ! !
|
|
! IntHost !-------------! Firewall !------------>>! externalHost!
|
|
! ! eth0! !ppp0 ! !
|
|
+-------------+ +--------------+ +-------------+
|
|
user: johndoe user: test
|
|
|
|
- IntHost is running an SIP softphone (like linphone, kphone)
|
|
|
|
- The SIP address used by IntHost is sip:johndoe@foo.bar.org
|
|
|
|
- The softphone on IntHost is configured to register at siproxd
|
|
running on the firewall host (10.0.0.1) as sip:johndoe@foo.bar.org
|
|
|
|
- foo.bar.org is the domain name corresponding to the public IP address
|
|
of the firewall (eg use some dynamic DNS service [1])
|
|
|
|
- externalHost does *not* register at siproxd running on the firewall host.
|
|
|
|
|
|
The relevant part of the configuration (linphone) of IntHost
|
|
then looks like ($HOME/gnome/linphone):
|
|
|
|
[sip]
|
|
sip_port=5060
|
|
use_registrar=1
|
|
username=johndoe
|
|
hostname=foo.bar.org
|
|
registrar=sip:10.0.0.1
|
|
reg_passwd=
|
|
addr_of_rec=sip:johndoe@foo.bar.org
|
|
reg_expires=900
|
|
as_proxy=1
|
|
as_redirect=0
|
|
as_outbound=1
|
|
|
|
To make an outgoing call from IntHost simply use the SIP address of the
|
|
target ( -> sip:test@xxx.org).
|
|
|
|
test@xxx.org can make a incoming calls - it simply has to use the registered
|
|
SIP address of the softphone running on IntHost (sip:johndoe@foo.bar.org).
|
|
Siproxd will then rewrite and forward the incoming request to Inthost.
|
|
|
|
The externalHost does not need to know anything about the proxy. For the
|
|
user sip:test@xxx.org it looks as he directly sends the traffic to
|
|
foo.bar.org, siproxd then takes care about where to send it from there.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: How does the registration and mapping of inbound clients work?
|
|
|
|
A: The mapping mechanism of SIP addresses works basically like:
|
|
|
|
Inthost sends a registration to siproxd with:
|
|
- a 'To:' address of the address to be registered (sip:johndoe@foo.bar.org)
|
|
(lets call this address the 'masqueraded' or 'public' address)
|
|
|
|
- a 'Contact:' address of the *true* address (sip:johndoe@10.0.0.10)
|
|
|
|
Siproxd then will basically 'just' substitute the true address by the
|
|
masqueraded address and vice versa. That means you can have multiple
|
|
IntHosts (each of them using a different user name) running at the
|
|
same time.
|
|
|
|
For an incoming call, siproxd will search its registration table for
|
|
the requested SIP address and so finds the internal host that belong to it.
|
|
|
|
This of course *requires* that the username part of the SIP address is
|
|
unique for each softphone that registers a the proxy (So this is more or
|
|
less the mechanism that you mentioned in your mail).
|
|
---------------------------------------------------------------------------
|
|
Q: How does the RTP Proxy work?
|
|
|
|
A: The RTP proxy actually is quite simple. It does not use any RTP
|
|
protocol stack. All relevant code is located within rtpproxy.c.
|
|
The RTP proxy is running as a separate thread. It maintains a
|
|
list of active RTP transfers (rtp_proxytable).
|
|
Controlling (registering a new RTP data stream / removing a RTP stream)
|
|
is done via 2 service routines rtp_start_fwd() and rtp_stop_fwd() from
|
|
withing the SIP related part of siproxd.
|
|
|
|
When a session is established (INVITE, ACK), siproxd will fetch the
|
|
relevant information (UDP ports) from the SIP messages and
|
|
does a rtp_start_fwd().
|
|
This will create an UDP socket and binds it to the outbound interface
|
|
address (port number dynamically chosen withing the RTP port range).
|
|
In addition a entry into the rtp_proxytable will be made.
|
|
|
|
The RTP Proxy then *simply* does wait withing a select() to receive
|
|
a UDP datagrams on the specified ports and then sends them to the
|
|
local client. The RTP proxy does absolutely not care about WHAT data
|
|
is proxied, so it is not aware of RTP or any other high level stuff.
|
|
It is simply a binary forwarding of datagrams.
|
|
If the session is closed (BYE) the RTP stream will be stopped via
|
|
rtp_stop_fwd(). In addition, there exists a timeout supervision
|
|
(configurable) that will stop RTP streams that have been inactive
|
|
(no data received) for a specified time.
|
|
|
|
The above only applies for reception of data FROM the outbound
|
|
interface (usually a public IP).
|
|
|
|
Outgoing traffic must be handled (masqueraded) by the firewall itself
|
|
(using ipchains or iptables rules).
|
|
|
|
Since version 0.3.6, siproxd also includes an IPCHAINs based RTP proxy/
|
|
forwarding. The principle is similar to above, but instead of receiving
|
|
and forwarding the UDP packets itself, siproxd just opens up an UDP
|
|
masquerading tunnel for the incomming traffic and then the kernel will
|
|
do the rest of the work.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: Does siproxd need to be installed on the same host as the
|
|
firewall (ipchains/iptables) is running?
|
|
|
|
A: Yes. Siproxd needs to know the public IP address, as this address is
|
|
included in the SIP signalling to establish a session. However,
|
|
siproxd does *not* interact with ipchains/iptables. The requirement
|
|
is to allow port 5060 for incomming UDP datagrams (SIP) as well as the
|
|
UDP port range for RTP data as specified in the config file (default
|
|
7070 - 7079). Outgoing UDP packets must be masqueraded by the firewall.
|
|
See 'Q: How do I setup IP masquerading for the outgoing RTP traffic'.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: How do I configure siproxd to use ICPHAINS based UDP masquerading
|
|
tunnels for proxying the incomming RTP traffic?
|
|
|
|
A: Simple. In the config file set the configuration option
|
|
rtp_proxy_enable = 2. Siproxd *must* then be started by root, I
|
|
highly recommend to let siproxd drop privileges after startup
|
|
(user, chrootjail config options).
|
|
Note: The UDP port range for incomming RTP data still uses the same
|
|
range as configured in the config file.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: How do I use siproxd as a pure outbound proxy, so I can register with my
|
|
SIP phone at a third party registrar?
|
|
|
|
A: Also Simple. Just configure your SIP phone to use siproxd as outbound
|
|
proxy and your 3rd party registrar as registrar. Siproxd will then
|
|
transparently handle (and if needed rewrite) the SIP traffic.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: I have a Grandstream Budgetone-100 SIP phone. The SIP communication
|
|
seems to work properly (I can register, make and receive calls) but
|
|
I do not hear any audio. However, transmitting audio works.
|
|
|
|
A: It has been observed that these SIP phone seems to be delicate there.
|
|
You should use the IPCHAINS based RTP proxy and your SIP phone must
|
|
be configured to use random ports. Connect with the web browser to
|
|
the phone and make sure the 'Use random port' option is enabled.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: I use Linux (kernel 2.4.x) with ipchains. However, siproxd
|
|
always complains "ERROR:IPCHAINS support not built in", why?
|
|
|
|
A: Siproxd IPCHAIN support works only with kernels 2.2.x. The
|
|
ipchains compatibility module for 2.4.x kernels lacks some features
|
|
that allow user space programs to control masquerading tunnels.
|
|
You must use the RTP relay or IPTABLES based masquerading.
|
|
|
|
---------------------------------------------------------------------------
|
|
Q: I have two local UA (SIP phones) connected to siproxd. I can
|
|
make outgoing calls and receive incoming calls to some other
|
|
SIP phones in the internet. However, making a call between the
|
|
two locally connected does not succeed, why?
|
|
|
|
A: That is not a bug but a known limitation of siproxd. Currently it
|
|
can only manage calls from the local (inbound) network to the
|
|
outside world (outbound network) and vice versa. Making calls
|
|
locally is not supported.
|
|
|
|
---------------------------------------------------------------------------
|