Products -> RTP Forwarding

The incoming call module must set the following in the "call.route" message:

    rtp_forward=possible
    rtp_addr=a.b.c.d
    rtp_port=nnnn
    formats=codec1,codec2,...
    format=preferred_codec (optional)

The router module looks for rtp_forward=possible and turns it into

    rtp_forward=yes (or true or enabled)

Later the same message becomes "call.execute" and is received by the call target module.

If it can handle RTP forwarding the module will check if rtp_forward holds a boolean True value. If it does, it picks parameters form rtp_addr, rtp_port, formats and format. If these values were acceptable it must set

    rtp_forward=accepted

When the "call.execute" returns the caller module can check if the target accepted the RTP forwarding. If the target did not accept it the module should enable its own RTP with data source and/or consumer or fail the call.

The called module must set its incoming RTP parameters in the "call.progress", "call.ringing" or the latest in the "call.answered" message:

    rtp_forward=yes
    rtp_addr=a.b.c.d
    rtp_port=nnnn
    formats=codec1,codec2,...
    format=preferred_codec (optional)

SIP to SIP raw SDP forwarding

If direct RTP forwarding is used between two SDP capable protocols (currently only SIP) there is the possibility to forward the full SDP between the call legs. This allows sending any media type or codec, even those not understood by Yate.

This is enabled in the ysipchan.conf file by setting:

    [general]
    forward_sdp=yes

The effect of this configuration is that the raw text of the SDP body is included in "call.route" as the sdp_raw parameter.

Further control is possible from routing, so in "call.execute" there are the following possibilities:

• rtp_forward is not true -> no RTP forwarding, use local RTP
• rtp_forward is true, sdp_raw is empty or missing -> RTP forwarding as above
• rtp_forward is true, sdp_raw is not empty -> the content of sdp_raw is included as outgoing SDP