python-aidot-cameras 1.0.0rc8__tar.gz → 1.0.0rc9__tar.gz

{python_aidot_cameras-1.0.0rc8/python_aidot_cameras.egg-info → python_aidot_cameras-1.0.0rc9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0rc8
+Version: 1.0.0rc9
 Summary: Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)
 Author-email: cbrightly <chris.brightly@gmail.com>
 License-Expression: MIT
@@ -572,7 +572,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_BATTERY_STALE_OFFER_GRACE_S` | Backstop for a **battery** attempt that stalls anyway, in seconds (`0` disables it). When the camera was silent as the first-media wait began, has since turned up, and has still sent no media after this long, the attempt is abandoned to the retry instead of holding the full 75 s window - a stalled camera answers and then sends nothing, while the retry's fresh offer is served in about 5 s. Measured from the camera's first sighting rather than its latest message, because a camera emitting an event every 5 s while its handshake goes nowhere would otherwise push the decision out until it had gone back to sleep. Sized clear of the slowest healthy open (10.7 s) so a merely slow attempt is never mistaken for a stalled one. | `15` |
 | `AIDOT_SDES_SERVE_AUDIO` | Include the camera's audio in what an SDES camera serves, on both the RTSP-push and http-serve paths. **On by default** for parity with the official app; set to `0`/`false`/`no`/`off` for video only, which is what a consumer that cannot cope with the audio wants. The standalone CLI reads this; inside Home Assistant the per-camera **Camera audio** switch is the same setting and should be used instead. | enabled (on) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
-| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Shortened rather than removed, so a broker that does echo still short-circuits it and gets its `webrtcResp`. Measured on an A001064: time to first media 4195 ms -> 2489 ms. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. **Caveat:** the 17/17 evidence is one fleet, and an echo landing between 0.25 s and 2.0 s would now miss the wait - that flag also selects whether the `webrtcResp` is built, whether the ICE window runs 20 s or 2.5 s, and whether the quickConn reconnect retry is armed. A late echo is logged, so set this to `2.0` if you see one. | `0.25` |
+| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Measured on an A001064: time to first media 4195 ms -> 2489 ms. **This value is the wait for a camera never seen to echo.** An echo observed at any point, including after the wait has already expired, is remembered for that camera and every later open on it waits `2.0` s again - so a fleet whose echo band is not empty pays the miss once, says so in the log, and is never shortened again. Setting this explicitly overrides both. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. | `0.25` (`2.0` once an echo has been seen) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |
 | `AIDOT_SDES_OFFER_BANDWIDTH_KBPS` | Add a `b=AS:<kbps>` receive-bandwidth ceiling (RFC 4566) to the video section of the SDES offer. **Measured to do nothing** on an A001064 over ten sessions; kept, off, alongside `AIDOT_REMB_TARGET_BPS` for the same reason. Run as a strict ABAB campaign it appeared to give a decisive 2.1x reduction - that was a codec split, not the knob. | unset (no `b=` line) |

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/README.md

@@ -532,7 +532,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_BATTERY_STALE_OFFER_GRACE_S` | Backstop for a **battery** attempt that stalls anyway, in seconds (`0` disables it). When the camera was silent as the first-media wait began, has since turned up, and has still sent no media after this long, the attempt is abandoned to the retry instead of holding the full 75 s window - a stalled camera answers and then sends nothing, while the retry's fresh offer is served in about 5 s. Measured from the camera's first sighting rather than its latest message, because a camera emitting an event every 5 s while its handshake goes nowhere would otherwise push the decision out until it had gone back to sleep. Sized clear of the slowest healthy open (10.7 s) so a merely slow attempt is never mistaken for a stalled one. | `15` |
 | `AIDOT_SDES_SERVE_AUDIO` | Include the camera's audio in what an SDES camera serves, on both the RTSP-push and http-serve paths. **On by default** for parity with the official app; set to `0`/`false`/`no`/`off` for video only, which is what a consumer that cannot cope with the audio wants. The standalone CLI reads this; inside Home Assistant the per-camera **Camera audio** switch is the same setting and should be used instead. | enabled (on) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
-| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Shortened rather than removed, so a broker that does echo still short-circuits it and gets its `webrtcResp`. Measured on an A001064: time to first media 4195 ms -> 2489 ms. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. **Caveat:** the 17/17 evidence is one fleet, and an echo landing between 0.25 s and 2.0 s would now miss the wait - that flag also selects whether the `webrtcResp` is built, whether the ICE window runs 20 s or 2.5 s, and whether the quickConn reconnect retry is armed. A late echo is logged, so set this to `2.0` if you see one. | `0.25` |
+| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Measured on an A001064: time to first media 4195 ms -> 2489 ms. **This value is the wait for a camera never seen to echo.** An echo observed at any point, including after the wait has already expired, is remembered for that camera and every later open on it waits `2.0` s again - so a fleet whose echo band is not empty pays the miss once, says so in the log, and is never shortened again. Setting this explicitly overrides both. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. | `0.25` (`2.0` once an echo has been seen) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |
 | `AIDOT_SDES_OFFER_BANDWIDTH_KBPS` | Add a `b=AS:<kbps>` receive-bandwidth ceiling (RFC 4566) to the video section of the SDES offer. **Measured to do nothing** on an A001064 over ten sessions; kept, off, alongside `AIDOT_REMB_TARGET_BPS` for the same reason. Run as a strict ABAB campaign it appeared to give a decisive 2.1x reduction - that was a codec split, not the knob. | unset (no `b=` line) |

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/aidot_cameras/camera/sdes_open.py

@@ -1167,13 +1167,17 @@ def _parse_answer_ice(sdp):
     order offered, and the first ``typ host`` candidate - which is the one SCTP
     is addressed to, and is not necessarily the first candidate listed.
 
-    Taking the FIRST credential pair is an observation, not a contract: our own
-    offer carries distinct per-media credentials, and the nomination sends
-    USE-CANDIDATE on both sockets with the single pair this returns.  That works
-    on the whole reference fleet, so those cameras evidently answer with one
-    pair - but no captured answer in this repo proves it, and a camera that
-    answered per-media credentials would need this split before it could be
-    nominated on both.
+    Taking the FIRST credential pair is now measured, not assumed.  Our own
+    offer carries distinct per-media credentials and the nomination sends
+    USE-CANDIDATE on both sockets with the single pair this returns, which is
+    only correct if the camera answers one pair for the whole session.  Logging
+    every a=ice-ufrag / a=ice-pwd line of the answer per m-section across four
+    cold opens on two models (A001064 mains, A001513 battery) on 2026-09-04:
+    every answer carried ONE pair, repeated identically in the audio, video and
+    application sections.  The shape is pinned in
+    test_the_first_credential_pair_is_the_only_pair; a camera that answered
+    per-media credentials would need this split before it could be nominated on
+    both sockets.
 
     One parser, used by both the nomination and the window's exit predicate.
     The exit means "the nomination this is about to reach will succeed", and it
@@ -1210,6 +1214,19 @@ def _answer_sdp_can_nominate(sdp) -> bool:
     return bool(ufrag and pwd and cands)
 
 
+def _answer_ready_for_this_open(stamp, open_started_at) -> bool:
+    """Whether the answer-ready marker was set by the open now running.
+
+    The marker is per-camera state driving a per-open decision.  It is cleared
+    at the start of every open, which covers the ordinary sequential case, but
+    two opens overlapping on one camera object would otherwise let one leave its
+    STUN window on the other's answer - or lose its own stamp to the other's
+    reset.  Comparing against this open's own start makes a stale stamp inert
+    instead.
+    """
+    return stamp is not None and stamp >= open_started_at
+
+
 def _stun_window_answer_exit_due(*, stun_seen: bool,
                                  answer_ready: bool) -> bool:
     """Whether the STUN responder window has nothing left to wait for.
@@ -1798,11 +1815,23 @@ async def _sdes_await_answer_or_terminal(
 # end of the STUN window rather than passing unnoticed, so an operator on a
 # fleet whose band is not empty gets a line naming the knob.
 _SDES_ECHO_WAIT_S = 0.25
+#: What the wait was before it was measured, and what a device that has actually
+#: produced an echo goes back to.
+_SDES_ECHO_WAIT_LEGACY_S = 2.0
 
 
-def _sdes_echo_wait_timeout(skip_liveplay: bool) -> float:
+def _sdes_echo_wait_timeout(skip_liveplay: bool,
+                            echo_seen: bool = False) -> float:
     """Seconds to block on the camera's webrtcReq echo. Never negative.
 
+    ``echo_seen`` is this device's own history: once an echo has been observed
+    from it - during the wait or, more usefully, after the wait had already
+    expired - every later open on that device waits the full
+    ``_SDES_ECHO_WAIT_LEGACY_S`` again.  That is what keeps the shortened wait
+    honest on a fleet the 17/17 measurement never saw: such a camera pays the
+    miss once, says so in the log, and is never shortened again.  An explicit
+    env value still wins over both.
+
     The echo only ever arrives for role-reversal models (e.g. A001064), which
     build a webrtcResp from it and run with ``skip_liveplay`` False (they are
     hard-excluded from sdes_fast_liveplay).  For A001513-class cameras
@@ -1823,7 +1852,9 @@ def _sdes_echo_wait_timeout(skip_liveplay: bool) -> float:
             val = None
         if val is not None and val >= 0.0:
             return 0.0 if skip_liveplay else val
-    return 0.0 if skip_liveplay else _SDES_ECHO_WAIT_S
+    if skip_liveplay:
+        return 0.0
+    return _SDES_ECHO_WAIT_LEGACY_S if echo_seen else _SDES_ECHO_WAIT_S
 
 
 # ffmpeg returns AVERROR(EPIPE) = -32 when its output consumer disappears, and a
@@ -2315,6 +2346,10 @@ class _SdesOpenMixin:
         SDP answer, writes it to a temp file, and launches ffmpeg to receive and
         record the SRTP stream.
         """
+        # When this open began.  The answer-ready marker lives on the camera
+        # object, not the open, so a marker older than this belongs to a
+        # previous open and must not fire this one's early exit.
+        _open_started_at = time.monotonic()
         from .client import CameraMixin, _build_sdes_serve_cmd, _ffmpeg_path, _resolve_serve_input_timeout_s, _spawn_bg  # lazy: break client<->sdes_open cycle
         import base64
         import subprocess
@@ -3269,7 +3304,8 @@ class _SdesOpenMixin:
         # Only role-reversal models (A001064, _skip_lp False) echo our webrtcReq
         # and need the webrtcResp built below; for A001513-class (_skip_lp True,
         # default) the echo never arrives, so don't block ~2s on it.
-        _echo_wait_s = _sdes_echo_wait_timeout(_skip_lp)
+        _echo_wait_s = _sdes_echo_wait_timeout(
+            _skip_lp, echo_seen=bool(getattr(self, "_sdes_echo_seen", False)))
         _echo_wait_t0 = time.monotonic()
         try:
             await _asyncio.wait_for(
@@ -3277,6 +3313,7 @@ class _SdesOpenMixin:
                 timeout=_echo_wait_s,
             )
             _cam_echo_received = True
+            self._sdes_echo_seen = True
             _status("camera webrtcReq echo received - building webrtcResp")
             # Seed _sdes_turn_entries from the echo's IceServerList if the HTTP
             # ice_config fetch returned nothing (empty list).  The echo carries
@@ -3703,8 +3740,9 @@ class _SdesOpenMixin:
             # still probing hard, so no idle threshold would ever be crossed.
             if _stun_window_answer_exit_due(
                     stun_seen=_stun_seen,
-                    answer_ready=getattr(
-                        self, "_camera_answer_ice_ready_ts", None) is not None):
+                    answer_ready=_answer_ready_for_this_open(
+                        getattr(self, "_camera_answer_ice_ready_ts", None),
+                        _open_started_at)):
                 _status(
                     "STUN window: leaving early after %.2fs - answer ICE"
                     " credentials in hand and camera probing; nominating now"
@@ -3866,6 +3904,30 @@ class _SdesOpenMixin:
                     break   # inner per-socket loop
             if _srtp_detected:
                 break       # outer while loop
+        # An echo that missed the shortened wait but turned up anyway.  Recorded,
+        # not acted on: the webrtcResp this would have built has to be sent
+        # BEFORE the relay allocation and the ICE window, so building it now
+        # would be a reordering with no camera to measure it against.  What it
+        # does do is make the NEXT open on this device wait the full legacy
+        # window - so a fleet whose echo band is not empty pays the miss once
+        # and says so, instead of losing the branch silently forever.
+        if (not _cam_echo_received and _echo_fut is not None
+                and not getattr(self, "_sdes_echo_seen", False)):
+            try:
+                _late_echo = _echo_fut.done() and not _echo_fut.cancelled()
+            except Exception:
+                _late_echo = False
+            if _late_echo:
+                self._sdes_echo_seen = True
+                _LOGGER.warning(
+                    "camera %s: the webrtcReq echo arrived %.2fs after a %.2fs"
+                    " wait expired, so no webrtcResp was built for this open."
+                    " Later opens on this camera will wait %.1fs again. Set"
+                    " AIDOT_SDES_ECHO_WAIT_S=%.1f to make that permanent.",
+                    getattr(self, "device_id", "?"),
+                    time.monotonic() - _echo_wait_t0, _echo_wait_s,
+                    _SDES_ECHO_WAIT_LEGACY_S, _SDES_ECHO_WAIT_LEGACY_S,
+                )
         for _rsock in (_audio_sock, _video_sock):
             try:
                 _rsock.setblocking(True)
@@ -3952,8 +4014,9 @@ class _SdesOpenMixin:
                 # window was fixed for, in the window the fix had not reached.
                 if _stun_window_answer_exit_due(
                         stun_seen=_stun_seen,
-                        answer_ready=getattr(
-                            self, "_camera_answer_ice_ready_ts", None) is not None):
+                        answer_ready=_answer_ready_for_this_open(
+                            getattr(self, "_camera_answer_ice_ready_ts", None),
+                            _open_started_at)):
                     _status(
                         "STUN window (retry %d): leaving early after %.2fs -"
                         " answer ICE credentials in hand and camera probing"

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/aidot_cameras/camera/webrtc_open.py

@@ -76,12 +76,12 @@ def _answer_is_from_the_camera(*, src_addr, user_id) -> bool:
     would set the answer-is-ready marker and the STUN window would leave having
     heard nothing from the camera at all.
 
-    Scope, stated precisely: this gates only the marker.  It does NOT stop the
-    echo resolving ``answer_fut``, which is where the nomination reads its SDP -
-    that routing is unchanged, and a session whose ``answer_fut`` takes the echo
-    nominates our own addresses whether the window leaves early or late.  Fixing
-    that means applying this predicate at delivery, which changes established
-    behaviour this release has no measurement for.
+    It gates delivery as well as the marker.  ``answer_fut`` is where the
+    nomination reads its SDP, so an echo that resolves it makes the nomination
+    address our own host and srflx candidates with our own credentials - a
+    session that can never be nominated, whether the window leaves early or
+    late.  Nothing downstream wants our own SDP under any circumstance: the
+    SDES path built that answer itself and already holds every value in it.
 
     ``srcAddr`` carries the account's prefix convention - ``2.`` device,
     ``0.`` app, ``9.`` server - and our own messages go out as ``0.{userId}``,
@@ -94,12 +94,19 @@ def _answer_is_from_the_camera(*, src_addr, user_id) -> bool:
     return not str(src_addr).startswith(f"0.{user_id}")
 
 
-def _deliver_webrtc_answer(loop, answer_fut, second_answer_fut, answer) -> None:
+def _deliver_webrtc_answer(loop, answer_fut, second_answer_fut, answer,
+                           from_camera: bool = True) -> None:
     """Route a webrtcResp answer to the first-answer or second-answer future.
 
-    Called from the MQTT (non-loop) thread.  The first accepted answer resolves
-    ``answer_fut``; a later one is the camera's real answer (the first was the
-    broker echo of our own webrtcResp) and resolves ``second_answer_fut``.
+    Called from the MQTT (non-loop) thread.  The first accepted answer from the
+    CAMERA resolves ``answer_fut``; a later one resolves ``second_answer_fut``,
+    which the late-ICE-credential recovery reads.
+
+    ``from_camera`` False means the broker echoed our own webrtcResp back at us.
+    It is dropped rather than routed: it carries our SDP, so resolving
+    ``answer_fut`` with it makes the nomination address our own candidates, and
+    resolving ``second_answer_fut`` feeds the same values to the late-credential
+    recovery. See :func:`_answer_is_from_the_camera`.
 
     One hop, for the reason in ``_resolve_future_threadsafe``: two answers
     drained inside one loop stall would otherwise both take the first branch,
@@ -108,6 +115,13 @@ def _deliver_webrtc_answer(loop, answer_fut, second_answer_fut, answer) -> None:
     about ``answer_fut`` is true.
     """
     def _deliver() -> None:
+        if not from_camera:
+            _LOGGER.debug(
+                "SDES: dropping the broker echo of our own webrtcResp"
+                " (len=%d) - it carries our SDP, not the camera's",
+                len(answer.get("sdp", "")),
+            )
+            return
         if not answer_fut.done():
             answer_fut.set_result(answer)
             return
@@ -1032,15 +1046,17 @@ class _WebRTCOpenMixin:
                         )
                     )
                     return
+                _from_cam = _answer_is_from_the_camera(
+                    src_addr=(inner.get("srcAddr")
+                              or msg.get("srcAddr") or ""),
+                    user_id=user_id)
                 if (self._camera_answer_ice_ready_ts is None
-                        and _answer_is_from_the_camera(
-                            src_addr=(inner.get("srcAddr")
-                                      or msg.get("srcAddr") or ""),
-                            user_id=user_id)
+                        and _from_cam
                         and _answer_sdp_can_nominate(answer.get("sdp", ""))):
                     self._camera_answer_ice_ready_ts = time.monotonic()
                 _deliver_webrtc_answer(
-                    loop, answer_fut, second_answer_fut, answer
+                    loop, answer_fut, second_answer_fut, answer,
+                    from_camera=_from_cam,
                 )
             elif method == "iceCandidateReq":
                 resp_pid = inner.get("peerid")

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-aidot-cameras"
-version = "1.0.0rc8"
+version = "1.0.0rc9"
 description = "Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)"
 readme = "README.md"
 license = "MIT"

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9/python_aidot_cameras.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0rc8
+Version: 1.0.0rc9
 Summary: Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)
 Author-email: cbrightly <chris.brightly@gmail.com>
 License-Expression: MIT
@@ -572,7 +572,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_BATTERY_STALE_OFFER_GRACE_S` | Backstop for a **battery** attempt that stalls anyway, in seconds (`0` disables it). When the camera was silent as the first-media wait began, has since turned up, and has still sent no media after this long, the attempt is abandoned to the retry instead of holding the full 75 s window - a stalled camera answers and then sends nothing, while the retry's fresh offer is served in about 5 s. Measured from the camera's first sighting rather than its latest message, because a camera emitting an event every 5 s while its handshake goes nowhere would otherwise push the decision out until it had gone back to sleep. Sized clear of the slowest healthy open (10.7 s) so a merely slow attempt is never mistaken for a stalled one. | `15` |
 | `AIDOT_SDES_SERVE_AUDIO` | Include the camera's audio in what an SDES camera serves, on both the RTSP-push and http-serve paths. **On by default** for parity with the official app; set to `0`/`false`/`no`/`off` for video only, which is what a consumer that cannot cope with the audio wants. The standalone CLI reads this; inside Home Assistant the per-camera **Camera audio** switch is the same setting and should be used instead. | enabled (on) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
-| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Shortened rather than removed, so a broker that does echo still short-circuits it and gets its `webrtcResp`. Measured on an A001064: time to first media 4195 ms -> 2489 ms. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. **Caveat:** the 17/17 evidence is one fleet, and an echo landing between 0.25 s and 2.0 s would now miss the wait - that flag also selects whether the `webrtcResp` is built, whether the ICE window runs 20 s or 2.5 s, and whether the quickConn reconnect retry is armed. A late echo is logged, so set this to `2.0` if you see one. | `0.25` |
+| `AIDOT_SDES_ECHO_WAIT_S` | How long to wait for the broker to echo our own `webrtcReq` back before carrying on, in seconds, for the role-reversal models that build a `webrtcResp` from that echo (A001513-class cameras never took this wait and are unaffected). Like `AIDOT_SDES_LIVEPLAY_ECHO_S` it was pure latency: across 18 h of one deployment, of 61 SDES opens the 17 that took the wait timed out 17 times out of 17 at a mean of 2.086 s, the `webrtcResp` it exists to build was never sent once, and all 17 streamed anyway. Measured on an A001064: time to first media 4195 ms -> 2489 ms. **This value is the wait for a camera never seen to echo.** An echo observed at any point, including after the wait has already expired, is remembered for that camera and every later open on it waits `2.0` s again - so a fleet whose echo band is not empty pays the miss once, says so in the log, and is never shortened again. Setting this explicitly overrides both. Read on every open and clamped at 0, so a malformed or negative value falls back to the default instead of raising. | `0.25` (`2.0` once an echo has been seen) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |
 | `AIDOT_SDES_OFFER_BANDWIDTH_KBPS` | Add a `b=AS:<kbps>` receive-bandwidth ceiling (RFC 4566) to the video section of the SDES offer. **Measured to do nothing** on an A001064 over ten sessions; kept, off, alongside `AIDOT_REMB_TARGET_BPS` for the same reason. Run as a strict ABAB campaign it appeared to give a decisive 2.1x reduction - that was a codec split, not the knob. | unset (no `b=` line) |

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/tests/test_nominates_as_soon_as_the_answer_lands.py

@@ -17,8 +17,12 @@ import inspect
 
 import pytest
 
-from aidot_cameras.camera.webrtc_open import _answer_is_from_the_camera
+from aidot_cameras.camera.webrtc_open import (
+    _answer_is_from_the_camera,
+    _deliver_webrtc_answer,
+)
 from aidot_cameras.camera.sdes_open import (
+    _answer_ready_for_this_open,
     _answer_sdp_can_nominate,
     _parse_answer_ice,
     _stun_window_answer_exit_due,
@@ -279,3 +283,122 @@ def test_the_candidate_parse_accepts_a_line_that_ends_at_typ():
     _u, _p, cands, host = _parse_answer_ice(sdp)
     assert cands == [("192.168.0.124", 35488)]
     assert host == ()
+
+
+# --------------------------------------------------------------------------- #
+# Our own echo must not reach the future the nomination reads
+# --------------------------------------------------------------------------- #
+
+def test_our_own_echo_is_dropped_rather_than_routed():
+    """Gating only the readiness marker left the failure it was written to
+    prevent fully reachable: `answer_fut` is where the nomination reads its SDP,
+    so an echo that resolves it makes USE-CANDIDATE address our own host and
+    srflx candidates with our own credentials. Routing it to second_answer_fut
+    instead just feeds the same values to the late-credential recovery."""
+    import asyncio
+
+    async def _run():
+        loop = asyncio.get_running_loop()
+        first, second = loop.create_future(), loop.create_future()
+        _deliver_webrtc_answer(loop, first, second,
+                               {"sdp": _OUR_ANSWER}, from_camera=False)
+        await asyncio.sleep(0)
+        assert not first.done(), "our own SDP must not resolve answer_fut"
+        assert not second.done(), "nor the future the late recovery reads"
+
+        _deliver_webrtc_answer(loop, first, second,
+                               {"sdp": _ANSWER}, from_camera=True)
+        await asyncio.sleep(0)
+        assert first.done() and first.result()["sdp"] == _ANSWER
+
+        _deliver_webrtc_answer(loop, first, second,
+                               {"sdp": _ANSWER}, from_camera=True)
+        await asyncio.sleep(0)
+        assert second.done(), "a later camera answer still reaches the recovery"
+
+    asyncio.run(_run())
+
+
+def test_delivery_defaults_to_treating_an_answer_as_the_cameras():
+    """Every other caller predates the flag; none of them must start dropping
+    answers because a keyword was added."""
+    import inspect
+
+    sig = inspect.signature(_deliver_webrtc_answer)
+    assert sig.parameters["from_camera"].default is True
+
+
+# --------------------------------------------------------------------------- #
+# The marker belongs to one open
+# --------------------------------------------------------------------------- #
+
+def test_a_marker_from_this_open_arms_the_exit():
+    assert _answer_ready_for_this_open(100.0, 99.0) is True
+    assert _answer_ready_for_this_open(99.0, 99.0) is True
+
+
+def test_a_marker_left_by_an_earlier_open_is_inert():
+    """The marker is per-camera state driving a per-open decision. The per-open
+    reset covers the sequential case; two opens overlapping on one camera object
+    would otherwise let one leave its window on the other's answer."""
+    assert _answer_ready_for_this_open(98.9, 99.0) is False
+
+
+def test_no_marker_at_all_is_not_ready():
+    assert _answer_ready_for_this_open(None, 99.0) is False
+
+
+def test_the_window_checks_the_marker_belongs_to_this_open():
+    src = _open_source()
+    assert "_answer_ready_for_this_open" in src
+    assert src.count("_answer_ready_for_this_open") >= 2, (
+        "both STUN windows must use it, not just the first")
+
+
+# --------------------------------------------------------------------------- #
+# One credential pair, measured rather than assumed
+# --------------------------------------------------------------------------- #
+#
+# The nomination sends USE-CANDIDATE on BOTH sockets with the single ufrag/pwd
+# this parser returns, computing the video socket's MESSAGE-INTEGRITY with what
+# the parser found first. That is only correct if the camera answers one pair
+# for the whole session, which nothing here proved.
+#
+# Measured 2026-09-04 by logging every a=ice-ufrag / a=ice-pwd line of the
+# answer, per m-section, across four cold opens on two models (A001064 mains,
+# A001513 battery): every answer carried ONE pair, repeated identically in the
+# audio, video and application sections. Values below are synthesised - the real
+# ones are per-session credentials and do not belong in a repo - but the shape
+# is the shape that was captured.
+
+_ONE_PAIR_ANSWER = "\r\n".join([
+    "v=0",
+    "m=video 9 RTP/SAVP 96",
+    "a=ice-ufrag:9z7F",
+    "a=ice-pwd:mDe5uxBe1msnVNMlu8BwzQPy",
+    "a=candidate:1 1 udp 2130706431 192.168.0.124 33912 typ host",
+    "m=audio 9 RTP/SAVP 8",
+    "a=ice-ufrag:9z7F",
+    "a=ice-pwd:mDe5uxBe1msnVNMlu8BwzQPy",
+    "m=application 9 SCTP webrtc-datachannel",
+    "a=ice-ufrag:9z7F",
+    "a=ice-pwd:mDe5uxBe1msnVNMlu8BwzQPy",
+])
+
+
+def test_the_first_credential_pair_is_the_only_pair():
+    """So nominating both sockets with it is right, not merely lucky."""
+    ufrag, pwd, cands, _host = _parse_answer_ice(_ONE_PAIR_ANSWER)
+    assert ufrag == "9z7F"
+    assert pwd == "mDe5uxBe1msnVNMlu8BwzQPy"
+    assert cands == [("192.168.0.124", 33912)]
+
+    pairs = {
+        (ln[len("a=ice-ufrag:"):].strip() if ln.startswith("a=ice-ufrag:")
+         else ln[len("a=ice-pwd:"):].strip())
+        for ln in _ONE_PAIR_ANSWER.splitlines()
+        if ln.startswith(("a=ice-ufrag:", "a=ice-pwd:"))
+    }
+    assert pairs == {ufrag, pwd}, (
+        "this answer carries more than one credential pair, so the single pair"
+        " the nomination uses on both sockets is no longer the whole story")

{python_aidot_cameras-1.0.0rc8 → python_aidot_cameras-1.0.0rc9}/tests/test_sdes_echo_wait_is_not_dead_time.py

@@ -94,3 +94,61 @@ def test_the_timeout_is_reported_rather_than_swallowed():
 
     src = inspect.getsource(CameraMixin._open_sdes_stream_impl)
     assert "webrtcReq-echo elapsed" in src
+
+
+# --------------------------------------------------------------------------- #
+# A fleet whose echo band is not empty
+# --------------------------------------------------------------------------- #
+#
+# The 17/17 measurement is one deployment. An echo landing between the new wait
+# and the old 2.0 s would miss it, and that flag is a branch selector: it
+# decides whether the webrtcResp is built, whether the ICE window runs 20 s or
+# 2.5 s, and whether the quickConn reconnect retry is armed. So the shortened
+# wait is not unconditional - it is the wait for a device that has never been
+# seen to echo.
+
+def test_a_device_that_has_echoed_goes_back_to_the_full_wait():
+    assert _sdes_echo_wait_timeout(False, echo_seen=True) == 2.0
+
+
+def test_a_device_that_has_never_echoed_keeps_the_short_wait():
+    assert _sdes_echo_wait_timeout(False, echo_seen=False) == 0.25
+
+
+def test_history_does_not_resurrect_the_wait_for_cameras_that_never_take_it():
+    """A001513-class cameras wait 0.0 s and are not part of this at all."""
+    assert _sdes_echo_wait_timeout(True, echo_seen=True) == 0.0
+
+
+def test_an_explicit_override_still_wins_over_the_history(monkeypatch):
+    monkeypatch.setenv("AIDOT_SDES_ECHO_WAIT_S", "0.5")
+    assert _sdes_echo_wait_timeout(False, echo_seen=True) == 0.5
+
+
+def test_the_history_defaults_off_so_the_first_open_is_still_fast():
+    """Callers that predate the flag must not start paying 2.0 s."""
+    assert _sdes_echo_wait_timeout(False) == 0.25
+
+
+def test_a_late_echo_is_recorded_so_the_next_open_waits_for_it():
+    """Recorded, not acted on: the webrtcResp has to be sent before the relay
+    allocation and the ICE window, so building it after the window would be a
+    reordering with no camera to measure it against. Making the NEXT open wait
+    is the part that can be done safely."""
+    import inspect
+
+    from aidot_cameras.camera.client import CameraMixin
+
+    src = inspect.getsource(CameraMixin._open_sdes_stream_impl)
+    assert "_sdes_echo_seen" in src
+    assert "AIDOT_SDES_ECHO_WAIT_S=%.1f" in src, (
+        "the line must name the knob that makes it permanent")
+
+
+def test_the_wait_reads_the_devices_history():
+    import inspect
+
+    from aidot_cameras.camera.client import CameraMixin
+
+    src = inspect.getsource(CameraMixin._open_sdes_stream_impl)
+    assert "echo_seen=" in src