update rtp timeout documentation

en/web-interface/equipment/gateways.rst

@@ -544,24 +544,69 @@ 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.
 
 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