rtpproxy [-?] [-2] [-f] [-v] [-V] [-R] [-l
addr1[/addr2]...] [-l
[label@]address[=advertized_address]...] [-6
addr1[/addr2]...] [-6
[label@]address[=advertized_address]...] [-s
ctrl_socket] [-t
tos] [-p
pidfile] [-T
max_ttl] [--maxpps
pps[,rtcp_pps]] [--maxpsize
size[,rtcp_size]] [-r rdir
[-S
sdir]] [-L
nofile_limit] [-A
advaddr1[/advaddr2]] [-m
min_port] [-M
max_port] [-u
uname[:gname]] [-w
sock_mode] [-F] [-i] [-n
timeout_socket] [-P] [-a] [-d
log_level[:log_facility]] [-W
setup_ttl] [--force_asymmetric] [-b] [-c
fifo|rr] [--nice
level] [-D] [--no_redirect] [--config
config_file] [--dso
module...] [--bridge_symmetric] [--no_resolve]
rtpproxy -C
The rtpproxy is a generic-purpose RTP proxy server designed to be used in conjunction with a SIP Controller capable of rewriting SDP contents. OpenSIPS, Kamailio, and Sippy B2BUA support rtpproxy.
The rtpproxy can be used to facilitate RTP sessions between SIP user agents that are behind a NAT(s) (Network Address Translator) firewall. Several cases exists when direct end-to-end communication is not possible and RTP streams have to be relayed through another host. rtpproxy can be used to setup such a relaying host.
The rtpproxy can also operate as a application level bridge by specifying two interfaces to listen on. In bridging mode rtpproxy forwards RTP packets received on one interface to the other interface and vice versa. This mode can be used to forward RTP packets between networks without direct network level connectivity (provided that the host running rtpproxy has an interface connected to both networks). One particular application of bridging mode is IPv4/IPv6 traversal of RTP packets.
When instructed by the call controller rtpproxy will record the entire RTP session to the local hard disk, fork-off (copy) to a remote server and/or play a pre-recorded file to the user agent (comfort ring replacement, Music-on-Hold, disclaimer announcements etc).
The rtpproxy tracks various important operational metrics about RTP sessions (calls), such as number of packets sent, received, lost, forwarded and so forth. Real-time metrics can then be retrieved by issuing appropriate command via control socket interface.
-?Show summary of options.
-2Send every RTP packet twice in sessions that use low-bitrate codecs. Only packets that are smaller than 128 bytes will be sent twice. This option can improve audio quality on lossy links.
-frtpproxy will stay in foreground mode if this option is set.
-VShow version of program.
-vShow supported rtpp command protocol revisions.
-l
addr1[/addr2]IPv4 listen IP address(es). This option can be specified
multiple times. Bridging mode can be enabled when the first IPv4 (or
first IPv6) listen argument is specified as
addr1/addr2.
Additional labeled listen addresses use the separate format
[label@]address[=advertized_address]. The
/addr2 form is not valid for labeled
entries.
When multiple listen addresses are configured, all addresses
after the first must have unique labels. Such labels are accepted by
the l{label} argument in U and
L commands.
-6
addr1[/addr2]IPv6 listen IP address(es). This option can be specified
multiple times. Two argument formats are supported:
addr1[/addr2] and
[label@]address[=advertized_address].
-s
ctrl_socketThis parameter configures rtpproxy control socket. The control
socket is used by the call controller for the purpose of creating,
modifying, and deleting RTP sessions. The control socket can also be
used to fetch stats from the rtpproxy process, or about specific
media sessions. Format of ctrl_socket is
<type>:<socket>. Following types are supported:
udp: Create UDP control socket. In this mode rtpproxy will listen on a UDP socket for control messages from the call controlle.
Example: -s udp:127.0.0.1:9000
IP address can be '*' in which case rtpproxy will listen on all local interfaces. If port is omitted then port 22222 will be used.
rtpproxy control protocol has no built-in security mechanisms. Make sure that you protect the listening IP and port properly when using rtpproxy with UDP control socket.
udp6: Create IPv6 UDP control socket. In this mode rtpproxy will listen on UDP/IPv6 for control messages from the SIP Controller.
Example: -s udp6:::1:9000
tcp: Create IPv4 TCP control socket. In this mode rtpproxy will listen on TCP/IPv4 for control messages from the SIP Controller.
Example: -s tcp:192.168.0.1:9001
tcp6: Create IPv6 TCP control socket. In this mode rtpproxy will listen on TCP/IPv6 for control messages from the SIP Controller.
Example: -s tcp6:::1:9002
unix: Create UNIX domain socket in a datagram-like mode for control interface. In this mode the SIP Controller and rtpproxy must be running on the same host. This is traditional mode when rtpproxy would close connection after processing each command and sending reply.
Example: -s unix:/var/run/rtpproxy.sock
cunix: Create UNIX domain socket for control interface. In this mode the SIP Controller and rtpproxy must be running on the same host. Similar to unix: above, but the rtpproxy would keep control socket open and accept multiple commands via the same connection.
Example: -s cunix:/var/run/rtpproxy.sock
Default value is
unix:/var/run/rtpproxy.sock.
-t tosSet ToS (Type of Service) in the outgoing IP header. Default value is 0xB8. Setting this parameter to -1 disables setting ToS resulting in operating system default ToS being used instead.
-r rec_dirDirectory to write recorded RTP sessions.
-S spool_dirSpool directory for recording of RTP streams. When the session
is stopped, the recording will be moved from the spool directory to
the rec_dir directory as specified by the -r
option.
-RPrevent rtpproxy from recording RTCP when recording RTP. rtpproxy records RTCP by default when RTP recording is enabled.
-p pid_fileThis parameter configures the name of the file where PID of
running rtpproxy will be stored. Default is
/var/run/rtpproxy.pid.
-T max_ttlSpecify the RTP inactivity timer. Defaults to 60 seconds.
If the rtpproxy does not receive any RTP packets for more than
max_ttl it will then delete the
session.
--maxpps
pps[,rtcp_pps]Set the default per-stream packet-per-second limit for newly
created RTP/RTCP streams. The first value applies to RTP streams.
The optional second value applies to RTCP streams; if omitted, the
RTP value is used for RTCP as well. A value of 0 disables the
default limit, which is the default behavior. The limit can be
changed for an existing session using the S pps=
control sub-command.
--maxpsize
size[,rtcp_size]Set the default maximum allowed incoming packet size in bytes
for newly created RTP/RTCP streams. The first value applies to RTP
streams. The optional second value applies to RTCP streams; if
omitted, the RTP value is used for RTCP as well. Packets larger than
the configured size are dropped. A value of 0 disables the default
limit, which is the default behavior. The limit can be changed for
an existing session using the S mps= control
sub-command.
-L
nofile_limitSet the maximum number of open file descriptors per process.
The default maximum is set by the operating system, and can be
overridden using the -L flag.
The rtpproxy requires four file descriptors per session to ensure that it can reliably identify where each stream is coming from in a NAT firewall scenario.
-A
advaddr1[/advaddr2]Set advertised address of rtpproxy. Useful if the rtpproxy is
behind a NAT firewall. (Amazon EC2) When the rtpproxy receives a
session request from a SIP controller it will return the IP
address(es) specified by the -A option.
This option configures the legacy bridge
internal/external address pair. For
per-address advertised overrides with multiple
-l/-6 entries, use
=advertized_address inside each listen
address argument.
-m min_portSet lower limit on UDP ports range that the rtpproxy uses for
RTP/RTCP sessions to min_port. Default is
35000.
-M max_portSet upper limit on UDP ports range that the rtpproxy uses for
RTP/RTCP sessions to max_port. Default is
65000.
-u
uname[:gname]Switch rtpproxy to UID identified by the
uname and optional GID identified by
gname when proxy is up and
running.
-w sock_modeSet access mode for the controlling UNIX-socket (if used).
Only applies if rtpproxy runs under a different GID using
-u option.
-FBy default the rtpproxy will warn user if running as superuser (UID 0) in local control mode and refuse to run in remote control mode at all. This switch removes the check.
-iEnable independent RTP activity timeout mode. By default, a timeout (which results in automatic destruction of the session) can only occur if no RTP packets are received on any of the session's ports. This option, if set, varies that behaviour, such that a timeout will occur if packets are still being received on one port but not the other. The option should be used with caution since in some cases it's perfectly fine to have packets coming from only one side of conversation (i.e. when the second party has muted its audio).
-n
timeout_socketThis parameter specifies permitted notification sockets only. The listening socket must be created by another application, preferably before starting rtpproxy.
Timeout notifications must be enabled by the SIP controller when setting up the session. The SIP Controller must specify the timeout_socket, and a notify_tag, which is expected to be an arbitrary string that can be used by the SIP controller to identify which session a received time out notification relates to.
If a SIP Controller specifies a notification socket for a
session, and that socket is not specified using the
-n flag, the rtpproxy will not send a notification,
and will not produce an error. It will ignore the notification
request.
Format of timeout_socket is
<type>:<socket>. Following types are supported:
unix: Connect to UNIX domain socket for sending timeout notifications. In this mode B2BUA and rtpproxy must be running on the same host.
Example: -n unix:/var/run/rtpproxy_timeout.sock
tcp: Connect to a remote host using
TCP/IP for sending timeout notifications. Format of the
socket parameter in this case is
<host>:<port>.
Example: -n tcp:10.20.30:12345
There is no default value, notifications are not sent and not
permitted unless a value is specified explicitly. Multiple
notification sockets can be provided by specifying the
-n flag more than once.
-PRecord sessions using libpcap file format instead of non-standard ad-hoc format. The libpcap format, which is the de-facto standard for packet capturing software, has the advantage of being compatible with numerous third-party tools and utilities, such as tcpdump or Wireshark. The drawback of libpcap is slightly larger overhead (extra 12 bytes for every saved RTP packet for IPv4).
-aRecord all sessions going through the rtpproxy unconditionally. By default rtpproxy expects the SIP controller to enable recording on a per-session basis.
-d
log_level[:log_facility]Configures the verbosity level of the log output. Possible
log_level values in the order from the
most verbose to the least verbose are: DBUG, INFO, WARN, ERR and
CRIT.
The optional log_facility parameter
sets syslog(3) facility assigned to log messages.
Example: -d WARN:LOG_LOCAL5
The default level in foreground mode is DBUG, in background - WARN and facility is LOG_DAEMON.
--force_asymmetricTreat all RTP/RTCP sessions as "asymmetric", i.e. disable any NAT traversal features unconditionally.
-W setup_ttlSpecify the inactivity timer for sessions that have not been
fully set up yet, i.e. before the rtpproxy has received the matching
L command. Defaults to the value of
-T.
-bAllocate UDP ports for new sessions sequentially instead of randomly. Mostly intended for debugging, to make the behaviour more predictable.
-c fifo|rrSwitch the rtpproxy process to the
SCHED_FIFO (fifo) or
SCHED_RR (rr)
real-time scheduling policy, at the maximum priority for that
policy.
--nice levelSet the scheduling priority (nice value) of the rtpproxy
process to level.
-DDo not change the working directory to /
when switching into the background mode.
--no_redirectDo not redirect the standard output and the standard error to
/dev/null when switching into the background
mode.
-CPrint the name of the monotonic clock used by the rtpproxy and exit.
--config config_fileRead the configuration of the loadable modules from
config_file, in the UCL format. An
example is provided in doc/rtpproxy.conf.sample
in the source tree.
--dso moduleLoad module, specified as a path to
the shared object of a dynamically loadable module, or as a name of
a module compiled in statically. This option can be specified
multiple times. Modules that require configuration cannot be loaded
this way, use --config instead.
--bridge_symmetricIn the bridging mode, do not treat all sessions as asymmetric, which is the default in that mode for historical reasons.
--no_resolveOnly accept numeric IP addresses, in the command line arguments and in the control commands, instead of resolving host names.
When the SIP controller receives an INVITE request, it extracts the Call-ID and from_tag from INVITE. The call controller communicates it with the rtpproxy via Unix domain socket or a UDP socket. rtpproxy looks for an existing session with the given Call-ID and from_tag.
If rtpproxy finds a session that is already associated with the given Call-ID, it will return the UDP port number that is already associated with that session.
If the given Call-ID and from_tag is not associated with an existing session, it will create a new session by randomly choosing a free UDP port from the usable UDP port range. The UDP port number will be provided as a response to the SIP controllers request.
The SIP controller is then expected to rewrite the SDP, replacing the ip:port to that of the IP address of the rtpproxy, and the port number allocated by the rtpproxy. The user agent reading the SDP will then send its RTP stream to the rtpproxy.
When the SIP Controller receives a non-negative SIP reply with SDP it extracts the Call-ID, from_tag and to_tag from the SIP message and sends a request to the rtpproxy with Call-ID, from_tag and to_tag.
The rtpproxy looks for an existing session based on the Call-ID and from_tag, which it should find. It will then randomly choose another port and "connect" this port with the earlier allocated port, forming the proxy between both sides.
When the SIP controller receives the new port number from the rtpproxy, the SIP controller is expected to rewrite the SDP in the SIP message body by replacing the ip:port to that of the IP address and new udp port number provided by rtpproxy. The SIP controller is expected to send the reply to the user agent that initiated the call.
After the session has been created, the proxy listens on the ports it has allocated for that session and relays UDP packets between the parties. Initially, packets are sent to the addresses provided by the SIP controller, i.e. taken from the SDP. Once a packet is received from a party, the proxy "latches" to the source IP:port of that packet and uses it as the address of that party from then on, which allows reaching parties located behind NAT. Latching is not done for asymmetric parties.
The rtpproxy tracks idle time for each of existing sessions (i.e. time interval within which there were no packets relayed), and automatically cleans up sessions whose idle times exceed the idle time (60 seconds by default).
All components of the rtpproxy are licensed under the BSD 2-Clause
License. See LICENSE file in the top of source tree
for details.
The latest version of this program and its components can be found at http://www.rtpproxy.org/.