RTP support channels

Revision as of 15:42, 9 October 2012

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 config file is yrtpchan.conf:

[general]
; This section sets global network level variables
 
; minport: int: Minimum port range to allocate
;minport=16384
 
; maxport: int: Maximum port range to allocate
;maxport=32768
 
; tos: keyword: Type Of Service to set in outgoing UDP packets
; numeric TOS value or: lowdelay, throughput, reliability, mincost
;tos=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

; rtcp: bool: Allocate socket for the RTCP protocol by default
;rtcp=enable

; drillhole: bool: Attempt to drill a hole through a firewall or NAT
;drillhole=disable in server mode, enable in client mode

; 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

[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
;notifymsg=
                                                                                
; warnlater: bool: Emit timeout warnings even if there was initially some RTP
;warnlater=no

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.

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.