Yate supports RTP forwarding and SDP forwarding (currently only in SIP).
RTP forwarding allows Yate to handle more calls per second since the media goes directly between the endpoints, while SDP forwarding allows sending any media type or codec, even those not understood by Yate.
This page describes the flow of messages that deal with RTP forwarding and how to enable SDP forwarding.
How RTP forwarding works in Yate
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:
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.
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:
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