RTP support channels

The yrtpchan module provides RTP and udptl transports for any technology that requires it (SIP, H.323, MGCP, Jingle). For RTP it also provides RTCP support by default.

Configuration

The configuration file is yrtpchan.conf. Below you can see the sections and their description.

Section [general]

This section sets global network level variables.

• ipv6_support: boolean: Enable or disable IPv6 support.

This parameter is applied on reload.

This parameter is ignored if yate was not built with IPv6 support.

It can be overridden in chan.rtp messages.

Default value is:

ipv6_support=no

• minport: int: Minimum port range to allocate. Default value is:

minport=16384

• maxport: int: Maximum port range to allocate. Default value is:

maxport=32768

• localip: ipaddress: Local IP address to use instead of guessing.

IPv6: An interface name can be added at the end of the address to bind on a specific interface.

This is mandatory for Link Local addresses (e.g. localip=fe80::1%eth0)

• tos: keyword: Type Of Service or DiffServ to set in outgoing UDP packets.

Numeric TOS / DiffServ value or:

lowdelay, throughput, reliability, mincost

cs0, ... cs7, af11, af12, af13, af21, ... af43, expedited, voice

Default value:

tos=0

• udpbuf: int: Requested size of UDP socket's receive buffer.

Valid values are 1024 to 65536, 0 to use kernel default.

udpbuf=0

• buffer: int: Maximum buffer size - used to fragment octet (G.711) audio streams.

buffer=240

• autoaddr: bool: Auto change outgoing RTP address:port to match incoming.

autoaddr=enable

• anyssrc: bool: Accept any incoming SSRC, even if it changes frequently.

anyssrc=disable

• padding: int: Pad the RTP payload to a multiple of this setting.

Supported values are between 2 and 128.

padding=0

• rtcp: bool: Allocate socket for the RTCP protocol by default

rtcp=enable

• rtcp_interval: int: RTCP report interval in ms (500-60000), zero disables

rtcp_interval=4500

• drillhole: bool: Attempt to drill a hole through a firewall or NAT

drillhole=disable in server mode, enable in client mode

• minjitter: int: Amount to attempt to keep in the dejitter buffer in msec

Valid values 5 to maxjitter-30, negative disables dejitter buffer

minjitter=50

• maxjitter: int: Maximum dejitter buffer size in msec

Valid values 50 to 1000, 0 disables dejitter buffer

maxjitter=120 in client mode, 0 in server mode

• monitoring: bool: Emit the messages required for SNMP monitoring

You will also need to set monitor=yes in section [rtp] of monitoring.conf

monitoring=no

• thread: keyword: Default priority of the data service threads

Can be one of: lowest, low, normal, high, highest

It is a bad idea to set a low priority for anything but testing

thread=normal

• defsleep: int: Default in-loop sleep time for new RTP sessions in milliseconds

defsleep=5

• minsleep: int: Minimum allowed in-loop sleep time in milliseconds

minsleep=1

• rtp_warn_seq: bool: Warn on receiving invalid RTP sequence number

If disabled the log message will be put at level 9

This parameter is applied on reload for new sessions only

It can be overridden in initial chan.rtp message or chan.attach message

rtp_warn_seq=enable

Note: The "tos" and "thread" settings requires IP and process level privileges - usually you need to run Yate as root (on *NIX), Administrator or Windows service.

Section [timeouts]

This section controls the behaviour when RTP and RTCP data is missing

• timeout: int: Receiver timeout in ms (500-60000), zero disables

timeout=3000

• notifymsg: string: Name of the notification message sent on timeout

Usually it should be chan.notify or call.drop, empty disables the message

• warnlater: bool: Emit timeout warnings even if there was initially some RTP

;warnlater=no

Example

How to drop calls if RTP is lost.
Because the signalling protocol may not detect promptly (or at all) a network failure it is common to drop calls shortly after RTP data is lost. This can be easily accomplished by setting:

[timeouts]
timeout=6500
notifymsg=call.drop
warnlater=yes

This will drop the call with reason nomedia 6.5 seconds after no RTP or RTCP packets were received. The 6.5 seconds is set to accomodate the typical 5s with 20% variation interval of RTCP reports.

SSRC problems

Normally the Synchronization Source identifier (SSRC) may change only if some change is applied to the media stream by the signaling protocol.
However many SIP and MGCP devices seem to change the SSRC without notifying the other end about the possible change. In this case with the default settings you will get a message like this:

<WARN> RTP Received SSRC AAAAAAAA but expecting BBBBBBBB

You can accomodate such devices by setting anyssrc=yes in the config file. The downside is a slight reduction in security as any valid looking RTP packet received on the UDP port will be accepted, potentially injecting audio or diverting away the entire stream.

RTCP usage

Very few application make use of RTCP. You can improve the performance of the system by disabling it. This also reduces the number of UDP ports used, potentially doubling the maximum number of voice streams.

See also

• RTP Forwarding