rtpproxy (8) - Linux Man Pages
rtpproxy: RTP (Real-time Transport Protocol) Proxy Server
rtpproxy - RTP (Real-time Transport Protocol) Proxy Server
rtpproxy [-?] [-2] [-f] [-v] [-V] [-R] [-l
addr1[/addr2]] [-6 addr1[/addr2]] [-s ctrl_socket] [-t tos] [-p pidfile] [-T max_ttl] [-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]
The main purpose of rtpproxy is to make the communication between SIP user agents behind NAT(s) (Network Address Translator) possible. 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.
When two listen interfaces have been specified using the command line parameters described below then rtpproxy will enter so called bridging mode. In briding 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 connectivy (provided that the host running rtpproxy has one interface in both of them). One particular application of bridging mode is IPv4/IPv6 traversal of RTP packets.
- Show summary of options.
- Send 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.
- Rtpproxy will stay in foreground mode if this option is set.
- Show version of program.
- Show command protocol version.
- IPv4 listen IP address(es). You can specify either one or two addresses. If two addresses have been specified then rtpproxy will work in bridging mode.
- IPv6 listen IP address(es). You can specify either one or two addresses. If two addresses have been specified then rtpproxy will work in bridging mode.
This parameter configures rtpproxy control socket. The control socket is used by nathelper module of SER to create/modify/delete RTP sessions to be relayed. Format of
is <type>:<socket>. Following types are supported:
udp: Create UDP control socket. In this mode RTPProxy will listen on UDP for control messages from SER/nathelper.
Example: -s udp:127.0.0.1:9000
IP address can be '*' in which case rtpproxy will listen on all local interfaces. If omitted port 22222 is 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 SER/nathelper.
Example: -s udp6:::1:9000
unix: Create UNIX domain socket for control interface. In this mode SER/nathelper and RTPProxy must be running on the same host. This is the default setting for both SER/nathelper and rtpproxy.
Example: -s unix:/var/run/rtpproxy.sock
Default value is /var/run/rtpproxy.sock.
- Set ToS (Type of Service) in the outgoing UDP packets to this value. Default value is 0xB8. Setting this parameter to -1 disables setting ToS resulting in operating system default ToS being used instead.
- Directory where recorded RTP sessions will be stored.
- Spool directory for RTP sessions being recorded. The file will be moved to directory configured in -r option after the session finishes.
- Do not record RTCP when recording an RTP session. This option is disabled (rtpproxy will record RTCP) by default.
- This parameter configures the name of the file where PID of running rtpproxy will be stored. Default is /var/run/rtpproxy.pid.
- Limit the maximum TTL (Time To Live) of outgoing IP packets to the value of max_ttl.
- Adjust the number of simultaneous open connections. Please note that each RTP media stream requires four open connections. A SIP call can open more than one RTP media stream depending on the client's setup.
- Setup advertised address if necessary.
- Set lower limit on UDP ports range that the RTPproxy uses for RTP/RTCP sessions to min_port. Default is 35000.
- Set upper limit on UDP ports range that the RTPproxy uses for RTP/RTCP sessions to max_port. Default is 65000.
- Switch RTPproxy to UID identified by the uname and optional GID identified by gname when proxy is up and running.
- Set access mode for the controlling UNIX-socket (if used). Only applies if RTPproxy runs under a different GID using -u option.
- By 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.
- Enable independent 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).
This parameter configures the optional timeout notification socket. The socket should be created by another application, preferably before starting rtpproxy. For those sessions where the timeout mechanism is enabled, notifications are sent on this socket if the session times out.
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.
- Record sessions using PCAP file format instead of non-standard ad-hoc format. The PCAP 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 Wireshark (Ethereal) for example. The drawback of PCAP is sligtly larger overhead (extra 12 bytes for every saved RTP packet for IPv4). Also, recording IPv6 sessions in PCAP format is not supported at the moment.
- Record all sessions going through the RTPproxy unconditionally. By default the RTPproxy requires call control software (i.e. SER, OpenSER or B2BUA) to enable recording explicitly on per-session basis by sending appropriate record command.
This parameter configures the verbosity level of the log output. Possible
values in the order from the most verboe 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 is DBUG, in background - WARN and facility is LOG_DAEMON.
When SER receives an INVITE request, it extracts Call-ID from it and communicates it to rtpproxy via Unix domain socket or UDP. Rtproxy looks for an existing session with such Call-ID. If the session exists it returns UDP port for that session, if not, then it creates a new session, binds to a first empty UDP port from the range specified at the compile time and returns number of that port to a SER. After receiving reply from the proxy, SER replaces media ip:port in the SDP to point to the proxy and forwards request as usually.
When SER receives a non-negative SIP reply with SDP it again extracts Call-ID from it and communicates it to the proxy. In this case the proxy does not allocate a new session if it doesn't exist, but simply performs a lookup among existing sessions and returns either a port number if the session is found, or error code indicating that there is no session with such id. After receiving positive reply from the proxy, SER replaces media ip:port in the SIP reply to point to the proxy and forwards reply as usually.
After the session has been created, the proxy listens on the port it has allocated for that session and waits for receiving at least one UDP packet from each of two parties participating in the call. Once such packet is received, the proxy fills one of two ip:port structures associated with each call with source ip:port of that packet. When both structures are filled in, the proxy starts relaying UDP packets between parties.
The proxy tracks idle time for each of existing sessions (i.e. the time within which there were no packets relayed), and automatically cleans up a sessions whose idle times exceed the value specified at compile time (60 seconds by default).
The latest version of this program can be found at m[blue]http://www.rtpproxy.org/m.
Copyright © 2006 janakj