RTP support channels

From Yate Documentation
Jump to: navigation, search

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.



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:
  • minport: int: Minimum port range to allocate. Default value is:
  • maxport: int: Maximum port range to allocate. Default value is:
  • 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:
  • udpbuf: int: Requested size of UDP socket's receive buffer.
Valid values are 1024 to 65536, 0 to use kernel default.
  • buffer: int: Maximum buffer size - used to fragment octet (G.711) audio streams.
  • autoaddr: bool: Auto change outgoing RTP address:port to match incoming.
  • anyssrc: bool: Accept any incoming SSRC, even if it changes frequently.
  • padding: int: Pad the RTP payload to a multiple of this setting.
Supported values are between 2 and 128.
  • rtcp: bool: Allocate socket for the RTCP protocol by default
  • rtcp_interval: int: RTCP report interval in ms (500-60000), zero disables
  • 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
  • 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
  • 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
  • defsleep: int: Default in-loop sleep time for new RTP sessions in milliseconds
  • minsleep: int: Minimum allowed in-loop sleep time in milliseconds
  • 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
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 behavior when RTP and RTCP data is missing.

  • timeout: int: Receiver timeout in ms (500-60000), zero disables.
  • udptl_timeout: int: UDPTL receiver timeout in ms (500-60000), zero disables.
  • notifymsg: string: Name of the notification message sent on timeout.
Usually it should be chan.notify or call.drop, empty disables the message.
  • warnfirst: bool: Emit timeout warnings if no RTP packet was received.
Once a packet is received further timeouts are controlled by warnlater.
  • warnlater: bool: Emit timeout warnings even if there was initially some RTP.


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:


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

Personal tools