From 3a4b1192e16e3e3558a054f96da373fe97fe7d32 Mon Sep 17 00:00:00 2001 From: Dmitry Date: Tue, 19 Aug 2025 11:58:04 +0300 Subject: [PATCH] update rtp timeout documentation --- en/web-interface/equipment/gateways.rst | 93 ++++++++++++++++++++----- 1 file changed, 74 insertions(+), 19 deletions(-) diff --git a/en/web-interface/equipment/gateways.rst b/en/web-interface/equipment/gateways.rst index dcb7c62..a6f59c0 100644 --- a/en/web-interface/equipment/gateways.rst +++ b/en/web-interface/equipment/gateways.rst @@ -544,14 +544,54 @@ To rewrite result Media attributes ================ -Sdp c location - Location of connection-line(c-line) in SDP payloads which are generated by YETI. +SDP c location + The SDP c location parameter specifies the placement of the connection line (c=) in SDP payloads generated by Yeti. + Possible values: - - On media level - - On session level - - On session and media level - + On media level + The connection line is included inside each media description (m= section). + + .. code-block:: + + v=0 + o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10 + s=yeti-switch + t=0 0 + m=audio 40000 RTP/AVP 0 8 + c=IN IP4 10.0.0.10 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + + On session level + A single connection line is included at the session level, applying to all media streams. + + .. code-block:: + + v=0 + o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10 + s=yeti-switch + c=IN IP4 10.0.0.10 + t=0 0 + m=audio 40000 RTP/AVP 0 8 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + + On session and media level + The connection line is present at both the session level and within each media description. + + .. code-block:: + + v=0 + o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10 + s=yeti-switch + c=IN IP4 10.0.0.10 + t=0 0 + m=audio 40000 RTP/AVP 0 8 + c=IN IP4 10.0.0.10 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + Codec group Codecs group which will be used to interact with this gateway. @@ -559,9 +599,14 @@ Proxy media Determines RTP processing mode. Must be enabled to have possibility of transcoding. Single codec in 200ok - If enabled, YETI will leave only once codec in responses with SDP - (Exception is only telephone-event. - It will be added anyway if received in SDP offer and present in codecs group for this gateway). + The Single Codec in 200 OK option controls codec selection in SDP responses generated by Yeti. + When enabled, Yeti includes only one codec in the SDP answer. + + - The selected codec is determined by the negotiated codec set for the gateway. + - The only exception is telephone-event, which is always added if it was present in the incoming offer and allowed in the gateway’s codec group. + + When disabled, Yeti responds with the full set of negotiated codecs. + Force symmetric rtp Ignore remote address negotiated in SDP. Use address gained from first received RTP/RTCP packet. @@ -570,17 +615,27 @@ Symmetric rtp nonstop By default, YETI allows to change address by symmetric RTP only one time. This option allows to disable this limitation. If enabled, YETI will change destination address every time when receives RTP/RTCP packet from another source. - + + Symmetric rtp ignore rtcp - Do not learn remote RTP address from incoming RTCP packets. - -Rtp ping - Useful for cases when gateways with enabled symmetric RTP wait for first packet before start sending, - but gateway on other side doing the same. - If enabled, YETI will send fake RTP packet to the gateway right after stream initialization. - -Rtp timeout - If set, call will be dropped with appropriate disconnect reason in CDR if no RTP arrived during this interval. + When enabled, Yeti will not update or learn the remote RTP address from incoming RTCP packets. Only RTP packets will be considered for determining the remote address. + + +RTP Ping + The RTP Ping mechanism is designed to resolve situations where both gateways(origination and termination), operating with symmetric RTP enabled, are waiting for the first incoming packet before transmitting their own RTP stream. + + When this option is enabled, Yeti proactively transmits a dummy (fake) RTP packet to the remote gateway immediately after the RTP stream initialization. This ensures that media exchange can be established even when both endpoints are configured to await the first packet. + + +RTP Timeout + The RTP Timeout parameter defines the maximum allowable interval without receiving RTP packets before a call is forcibly terminated. When the timeout condition is met, the call is disconnected, and the corresponding disconnect reason is recorded in the CDR. + + Yeti applies a single RTP timeout value for both call legs. This value is computed as the maximum of ``origination_gateway.rtp_timeout`` and ``termination_gateway.rtp_timeout``. + + If the computed RTP timeout value equals 0, the timeout mechanism is disabled, and Yeti does not terminate calls in the absence of RTP packets. + + .. warning:: In SEMS versions prior to 1.170.1, the RTP Timeout is not reset upon the reception of RTCP packets. Beginning with version 1.170.1, SEMS behavior was updated: if RTCP packets are received, the call will not be disconnected even in the absence of RTP packets. + .. spelling:word-list:: noaudio