python-aidot-cameras 1.0.0b7__tar.gz → 1.0.0b8__tar.gz

{python_aidot_cameras-1.0.0b7/python_aidot_cameras.egg-info → python_aidot_cameras-1.0.0b8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0b7
+Version: 1.0.0b8
 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

{python_aidot_cameras-1.0.0b7 → python_aidot_cameras-1.0.0b8}/aidot_cameras/camera/protocol.py

@@ -243,6 +243,124 @@ def _section_of(lines: list) -> str:
     return ""
 
 
+#: How long to wait for ICE when the camera's answer arrived with its mids
+#: shifted. Measured over 63 opens on an A000088: every successful open
+#: completed ICE between 8.7 s and 10.6 s, and every failure ran the full 45 s
+#: deadline. There is no overlap between the two bands, so a cap sitting above
+#: the success band cannot cost a session that was going to work.
+SHIFTED_ANSWER_ICE_TIMEOUT_S = 15.0
+
+
+def answer_inserted_a_section(*, shifted_sections: int,
+                             unclaimed_answer_mids: int) -> bool:
+    """Did the camera ADD an m-section, rather than drop or reorder one?
+
+    Both shapes shift our mids, and only one of them is the behaviour the ICE
+    cap was measured against. An A000088 that inserts its H265 video section
+    leaves that section unclaimed after the walk, because nothing in our offer
+    wanted it. An A001064 that drops a rejected section and renumbers the rest -
+    quirk 1 of this rebuild - shifts the mids just as much and leaves nothing
+    over.
+
+    The distinction is load-bearing: the cap comes from 63 opens on a mains
+    A000088 that connects in 9 s, and an SDES camera reaching this path through
+    the SDES->DTLS fallback can take 25-70 s to open cold. Cutting its deadline
+    to 15 s on a shape that was never measured would break exactly the streaming
+    this must not break.
+    """
+    return shifted_sections > 0 and unclaimed_answer_mids > 0
+
+
+def ice_wait_timeout(*, shifted_sections: int, default_timeout: float) -> float:
+    """How long to give ICE, given what the camera's answer looked like.
+
+    A shifted answer - one where the camera added its H265 video section and
+    pushed every later mid along - is a strong but NOT certain sign the session
+    is not coming up: 6 of 7 measured shifts failed at ICE, and the seventh
+    established in 8.8 s. So it must still be given room to succeed, just not
+    45 s of it.
+
+    45 s matters because it is past the ~30 s deadline Home Assistant's stream
+    worker allows, which is the failure this project already learned the hard
+    way. Capping at 15 s keeps the one-in-seven that works, fails the rest
+    faster than the old behaviour did, and stays inside that deadline either
+    way.
+
+    Never extends a caller's own timeout - a caller asking for 5 s means 5 s.
+    """
+    if shifted_sections > 0:
+        return min(default_timeout, SHIFTED_ANSWER_ICE_TIMEOUT_S)
+    return default_timeout
+
+
+def select_answer_section(
+    offer_mid: str,
+    offer_kind: str,
+    ans_sections: dict,
+    offer_video_pts: set,
+    claimed: set,
+) -> "Optional[tuple]":
+    """Which answer section fills this offer m-section, or None to stub it.
+
+    ``ans_sections`` maps ``a=mid`` -> ``(kind, lines)``.  ``claimed`` holds the
+    answer mids already given to earlier offer sections, so one section is never
+    handed out twice.  Returns ``(answer_mid, lines)``.
+
+    Same mid first: that is what a compliant answerer sends, and the A001064
+    quirks this rebuild exists for (dropped sections, swapped kinds) are all
+    expressed in mid terms.
+
+    The fallback is for the case the mid walk cannot express.  An A000088 was
+    measured answering an SD-card offer with an extra ``m=video`` carrying
+    ``a=rtpmap:0 H265/90000`` at mid 0, which shifts every later mid by one.
+    Matching by mid then puts H265 in our video slot - and aiortc has no H265
+    in its codec registry, so setRemoteDescription fails outright rather than
+    degrading.  On a live offer the same shift makes every mid mismatch on kind
+    and the whole answer gets stubbed, which reads as a camera declining media.
+    The camera does not add that section every time, so both failures are
+    intermittent.
+
+    So when the same-mid section is the wrong kind, or is a video section
+    sharing no payload type with our offer, the other unclaimed sections of the
+    right kind are considered and the video one with the most payload-type
+    overlap wins.  A video section with no overlap is still preferred over
+    stubbing: a section aiortc may reject beats one that cannot possibly work.
+    """
+    def _pts(entry) -> set:
+        for ln in entry[1]:
+            if ln.startswith("m="):
+                return set(ln.split()[3:])
+        return set()
+
+    def _usable(entry) -> bool:
+        if entry[0] != offer_kind:
+            return False
+        # Payload types only discriminate video, and only when we know ours.
+        if offer_kind != "video" or not offer_video_pts:
+            return True
+        return bool(_pts(entry) & offer_video_pts)
+
+    same = ans_sections.get(offer_mid)
+    if same is not None and offer_mid not in claimed and _usable(same):
+        return (offer_mid, same[1])
+
+    candidates = [
+        (mid, entry) for mid, entry in ans_sections.items()
+        if mid not in claimed and entry[0] == offer_kind
+    ]
+    if not candidates:
+        return None
+    if offer_kind == "video" and offer_video_pts:
+        mid, entry = max(
+            candidates, key=lambda c: (len(_pts(c[1]) & offer_video_pts), c[0])
+        )
+        return (mid, entry[1])
+    # Non-video, or nothing to score with: the earliest unclaimed one of the
+    # right kind, which for a shifted answer is the shifted section.
+    mid, entry = min(candidates, key=lambda c: c[0])
+    return (mid, entry[1])
+
+
 def _compress_sdp_for_camera(sdp: str) -> str:
     """Selective SDP filter matching official Java client's g.b() behaviour.
 

python_aidot_cameras-1.0.0b8/aidot_cameras/camera/sd_playback.py

@@ -0,0 +1,112 @@
+"""Ask a camera to play a recording off its own SD card.
+
+The control surface only - the request bytes and the reply decode. Opening a
+session and delivering frames is `_CameraSdPlaybackMixin`, added separately, so
+this half can be tested with no camera in the way.
+
+The request shape comes from the vendor app rather than from guesswork - but
+from a specific overload of it. The app calls
+`AVIOCTRLDEFs$SMsgAVIoctrlPlayRecord.parseContent(IIIIJII)`, not the
+`(III[B)` overload this module first assumed, and the two disagree about the
+last four bytes. `parseContent(IIIIJII)` allocates 0x18 bytes and fills:
+command at offset 4 and an 8-byte STimeDay at offset 12, both as first
+assumed, but offset 0 and offset 8 are ALWAYS 0 (not a caller-chosen channel),
+and the trailing two bytes at offsets 20-21 carry the real channel and a
+second caller value. The channel comes from `KVSWebRTCChannel.sdRecordPlay`,
+which allocates it as `sdChannelId += 1` wrapping 26 -> 1 before every play -
+so a real request never carries channel 0.
+"""
+import struct
+from typing import Any, NamedTuple, Optional
+
+RECORD_PLAYCONTROL_REQ_CMD = 0x31A
+RECORD_PLAYCONTROL_RESP_CMD = 0x31B
+
+# Only START and STOP have been sent to a camera and answered (measured
+# 2026-08-13, A000088). PAUSE, STEPFORWARD, STEPBACKWARD, FORWARD, BACKWARD,
+# SEEKTIME, END and RESUME are real values from the same vendor enum, kept
+# here for completeness, but nobody should assume any of them are proven
+# against hardware.
+PLAY_PAUSE = 0x00
+PLAY_STOP = 0x01
+PLAY_STEPFORWARD = 0x02
+PLAY_STEPBACKWARD = 0x03
+PLAY_FORWARD = 0x04
+PLAY_BACKWARD = 0x05
+PLAY_SEEKTIME = 0x06
+PLAY_END = 0x07
+PLAY_START = 0x10
+PLAY_RESUME = 0x11
+
+_PAYLOAD_LEN = 0x18
+# Unlike _PAYLOAD_LEN, this is not read off the vendor encoder - it rests on
+# one live capture, on an A000088, 2026-08-13. Treat it as less certain than
+# the request shape above.
+_REPLY_LEN = 20
+
+_MIN_SD_CHANNEL = 1
+_MAX_SD_CHANNEL = 26
+
+
+class PlaycontrolReply(NamedTuple):
+    """What the camera said back.
+
+    ``field1`` and ``field2`` are deliberately not named. Measured 2026-08-13:
+    ``field1`` read 0 with the camera free and 1 while another viewer held a
+    live session, so it is NOT a success code; ``field2`` read 60 on every run,
+    but every run used the same record. Naming either would publish a guess.
+    """
+
+    command: int
+    field1: int
+    field2: int
+    year: int
+    month: int
+    day: int
+    hour: int
+    minute: int
+    second: int
+
+
+def playcontrol_payload(command: int, record: Any, *, sd_channel: int = 1,
+                        param: int = 0) -> bytes:
+    """The 24 bytes for one playback command against one record.
+
+    ``sd_channel`` must be 1..26, the range `sdRecordPlay` actually allocates.
+    A value outside it is a caller bug, not a protocol surprise, and is
+    rejected rather than clamped: a silently changed channel would send a
+    request the camera accepts and answers while returning no media - the
+    exact symptom this module exists to avoid reproducing.
+    """
+    if not _MIN_SD_CHANNEL <= sd_channel <= _MAX_SD_CHANNEL:
+        raise ValueError(
+            f"sd_channel must be {_MIN_SD_CHANNEL}..{_MAX_SD_CHANNEL}, "
+            f"got {sd_channel}")
+    # Offsets 0 and 8 are always 0 in the vendor app's own call - neither is a
+    # caller-chosen channel or param, whatever the (III[B) overload implies.
+    head = struct.pack("<III", 0, command, 0)
+    when = struct.pack(
+        "<HBBBBBB",
+        record.year, record.month, record.day,
+        0,                       # wday - the camera fills its own
+        record.hour, record.minute, record.second,
+    )
+    tail = struct.pack("<BB", sd_channel, param)
+    return (head + when + tail
+            + b"\x00" * (_PAYLOAD_LEN - len(head) - len(when) - len(tail)))
+
+
+def decode_playcontrol_reply(data: Optional[bytes]) -> Optional[PlaycontrolReply]:
+    """Read a 0x31b reply, or None if it cannot be read.
+
+    None rather than an exception, for the same reason the listing decode does
+    it: a reply with an unexpected shape is entirely ordinary and must not
+    surface as a traceback in a media browser.
+    """
+    if not data or len(data) < _REPLY_LEN:
+        return None
+    command, field1, field2 = struct.unpack("<III", data[:12])
+    year, month, day, _wday, hour, minute, second = struct.unpack(
+        "<HBBBBBB", data[12:20])
+    return PlaycontrolReply(command, field1, field2,
+                            year, month, day, hour, minute, second)

{python_aidot_cameras-1.0.0b7 → python_aidot_cameras-1.0.0b8}/aidot_cameras/camera/webrtc_open.py

@@ -34,6 +34,9 @@ from .protocol import (
     _normalize_bundle_ice_credentials,
     _reorder_m_section_ice_attrs,
     _sdp_transport,
+    answer_inserted_a_section,
+    ice_wait_timeout,
+    select_answer_section,
     _terminal_webrtc_ack,
     _upgrade_sctp,
     _webrtc_consume_video,
@@ -2558,6 +2561,13 @@ class _WebRTCOpenMixin:
         _rr_webrtc_resp_topic:   str  = ""
         _rr_webrtc_resp_payload: str  = ""
         _rr_ice_payloads:        list = []  # list of (topic, json_str) tuples
+        # How many answer sections came from a mid other than the offer's. Set
+        # by the normal path's rebuild below; declared here so the ICE wait can
+        # read it whichever path ran.
+        _shifted_picks = 0
+        # True only when the camera ADDED a section, which is the shape the
+        # ICE cap was measured against.
+        _answer_inserted = False
 
         if camera_offer_fut in _rr_done and answer_fut not in _rr_done:
             # ---- ROLE REVERSAL path (e.g. LK.IPC.A001064) ---------------------- #
@@ -3037,14 +3047,52 @@ class _WebRTCOpenMixin:
             # 4-section BUNDLE is aligned) but we only decode H264 and audio.
             _h265_offer_pts: set = set()  # H265 no longer offered; camera won't answer H265 PTs
 
+            # Our offer's video payload types, used both here (to tell the
+            # camera's real video answer from an H265 section it added) and
+            # again by _aiortc_answer below.
+            _offer_video_pts: set = set()
+            for _ol in _offer_sdp.splitlines():
+                if _ol.startswith('m=video'):
+                    _offer_video_pts = set(_ol.split()[3:])
+                    break
+
             _rebuilt: list = list(_ans_header)
             _kept_count = 0
             _stub_count = 0
             _dropped_mids: list = []
+            _claimed_ans_mids: set = set()
             _rejected_mids: set = set()  # mids whose stub has port=0 (excluded from BUNDLE)
             for _m in _offer_mids:
                 _expected_kind = _offer_kinds[_m]
-                _ans_kind, _ans_block = _ans_sections.get(_m, ("", []))
+                # Same mid first, then kind + payload-type overlap.  This camera
+                # sometimes adds an H265 video section at mid 0 and shifts every
+                # later mid by one; matching on mid alone then puts H265 in our
+                # video slot (hard setRemoteDescription failure) or mismatches
+                # every kind at once (reads as declined media).  See
+                # select_answer_section.
+                _pick = select_answer_section(
+                    _m, _expected_kind, _ans_sections,
+                    _offer_video_pts, _claimed_ans_mids,
+                )
+                if _pick is not None:
+                    _claimed_ans_mids.add(_pick[0])
+                    if _pick[0] != _m:
+                        _shifted_picks += 1
+                        _status(
+                            f"answer mid {_pick[0]} taken for offer mid {_m}"
+                            f" ({_expected_kind}): the camera shifted its mids"
+                        )
+                _ans_kind = _expected_kind if _pick is not None else ""
+                _ans_block = list(_pick[1]) if _pick is not None else []
+                if _pick is not None and _pick[0] != _m:
+                    # Renumber to the slot it now occupies. _aiortc_answer
+                    # renumbers again downstream, but leaving a section
+                    # carrying another slot's a=mid inside _rebuilt would make
+                    # the intermediate SDP disagree with its own BUNDLE line.
+                    _ans_block = [
+                        f'a=mid:{_m}' if _bl.startswith('a=mid:') else _bl
+                        for _bl in _ans_block
+                    ]
                 # Force-stub H265 sections: detect by camera's answer m-line
                 # using only our H265 PTs (103/104).
                 _ans_h265 = False
@@ -3070,9 +3118,19 @@ class _WebRTCOpenMixin:
                     _stub_count += 1
                     if _s and _s[0].split()[1] == '0':
                         _rejected_mids.add(_m)
-            for _ans_mid in _ans_sections:
-                if _ans_mid not in _offer_kinds:
-                    _dropped_mids.append(_ans_mid)
+            # Sections the walk never took. An INSERTED section (the camera's
+            # H265 one) ends up here; a dropped-and-renumbered answer leaves
+            # nothing. That is what separates the shape the ICE cap was
+            # measured on from the one it was not - see
+            # answer_inserted_a_section.
+            _unclaimed_ans_mids = [
+                _am for _am in _ans_sections if _am not in _claimed_ans_mids
+            ]
+            _answer_inserted = answer_inserted_a_section(
+                shifted_sections=_shifted_picks,
+                unclaimed_answer_mids=len(_unclaimed_ans_mids),
+            )
+            _dropped_mids.extend(_unclaimed_ans_mids)
 
             if _stub_count or _dropped_mids:
                 _status(
@@ -3196,13 +3254,8 @@ class _WebRTCOpenMixin:
             # bogus single-PT video stub - all of which break aiortc's positional
             # matching.  _aiortc_answer() below selects by content and re-emits.
             import re as _re_ans  # module has no top-level `import re`
-            # Our offer's video payload types (H264 + RTX), used to pick the
-            # camera's REAL video answer section apart from H265/bogus stubs.
-            _offer_video_pts: set = set()
-            for _ol in _offer_sdp.splitlines():
-                if _ol.startswith('m=video'):
-                    _offer_video_pts = set(_ol.split()[3:])
-                    break
+            # _offer_video_pts (our H264 + RTX payload types) is computed above,
+            # where the mid walk needs it, and reused here.
 
             # Set by _aiortc_answer when the camera returns a DC-only answer
             # (both audio and video rejected = media declined, encoder cold).
@@ -3618,7 +3671,19 @@ class _WebRTCOpenMixin:
         async def _on_ice_gather() -> None:
             _LOGGER.info("webrtc: ICE gatheringState -> %s", pc.iceGatheringState)
 
-        deadline = time.monotonic() + timeout
+        # A shifted answer gets a shorter ICE deadline, not a refusal: 6 of 7
+        # measured shifts never connected, but the seventh came up in 8.8 s.
+        # See ice_wait_timeout for the measurement behind the cap.
+        _ice_timeout = ice_wait_timeout(
+            shifted_sections=1 if _answer_inserted else 0,
+            default_timeout=timeout,
+        )
+        if _ice_timeout != timeout:
+            _status(
+                f"answer shifted mids: ICE deadline capped to {_ice_timeout:.0f}s"
+                f" (from {timeout:.0f}s)"
+            )
+        deadline = time.monotonic() + _ice_timeout
         _last_ice_log = time.monotonic()
         _userconnect_midloop_sent = False  # guard: re-send user/connect once at half-timeout
         _second_ans_processed = False  # guard: process second_answer_fut candidates once
@@ -3719,11 +3784,15 @@ class _WebRTCOpenMixin:
             # Mid-loop user/connect retry: if no camera IP yet and ~half of the
             # ICE timeout has elapsed, re-announce user presence so the camera
             # pushes setDevAttrNotif again.  Replaces the invented getDevAttrReq.
+            # Halve the deadline this loop is actually running to (_ice_timeout),
+            # not the caller's: a capped wait compared against the uncapped
+            # timeout is already past half on its first tick, which fires the
+            # one-shot re-announce at t=0 and leaves nothing for mid-loop.
             _remaining = deadline - time.monotonic()
             if (not _userconnect_midloop_sent
                     and cam_ip_q.empty()
                     and _remaining > 0
-                    and _remaining <= timeout / 2.0):
+                    and _remaining <= _ice_timeout / 2.0):
                 outgoing_q.put_nowait((
                     f"iot/v1/cb/{user_id}/user/connect",
                     json.dumps({
@@ -3767,10 +3836,18 @@ class _WebRTCOpenMixin:
             outgoing_q.put_nowait(None)
             _cancel_track_tasks()
             await pc.close()
+            if _answer_inserted:
+                # Before the answer sections were matched by content, a shifted
+                # answer on the live path stubbed every section and raised this
+                # same error, which the caller retries in a fast bounded burst.
+                # Keep that: a shifted answer that did not connect inside the
+                # cap is the camera declining, not a transport fault, and the
+                # generic 15s-gated retry is the wrong response to it.
+                raise AidotCameraNotReady(self.device_id)
             raise RuntimeError(
                 f"async_open_webrtc_stream: ICE connection not established "
                 f"(connState={pc.connectionState}"
-                f"  iceState={pc.iceConnectionState}) within {timeout}s"
+                f"  iceState={pc.iceConnectionState}) within {_ice_timeout}s"
             )
 
         if recorder:

{python_aidot_cameras-1.0.0b7 → python_aidot_cameras-1.0.0b8}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-aidot-cameras"
-version = "1.0.0b7"
+version = "1.0.0b8"
 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.0b7 → python_aidot_cameras-1.0.0b8/python_aidot_cameras.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0b7
+Version: 1.0.0b8
 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

{python_aidot_cameras-1.0.0b7 → python_aidot_cameras-1.0.0b8}/python_aidot_cameras.egg-info/SOURCES.txt

@@ -61,6 +61,7 @@ aidot_cameras/camera/playback.py
 aidot_cameras/camera/protocol.py
 aidot_cameras/camera/sd_events.py
 aidot_cameras/camera/sd_listing.py
+aidot_cameras/camera/sd_playback.py
 aidot_cameras/camera/sdes.py
 aidot_cameras/camera/sdes_open.py
 aidot_cameras/camera/tutk.py
@@ -75,6 +76,7 @@ python_aidot_cameras.egg-info/top_level.txt
 tests/test_aioice_compat.py
 tests/test_alarm_event.py
 tests/test_answer_sdp_video_pt.py
+tests/test_answer_section_selection.py
 tests/test_audio_mux_offline.py
 tests/test_avio_request.py
 tests/test_avio_response_parse.py
@@ -164,6 +166,7 @@ tests/test_sd_card_presence.py
 tests/test_sd_event_decode.py
 tests/test_sd_event_probe_payloads.py
 tests/test_sd_listing.py
+tests/test_sd_playback.py
 tests/test_sdes_adaptive.py
 tests/test_sdes_avio_dispatch.py
 tests/test_sdes_bridge_break_gate.py

python_aidot_cameras-1.0.0b8/tests/test_answer_section_selection.py

@@ -0,0 +1,189 @@
+"""Matching the camera's answer sections to the offer's m-sections.
+
+The rebuild that feeds aiortc used to match purely by ``a=mid``. That holds
+right up until the camera adds a section the offer never had, which this
+firmware family does: an A000088 was measured on 2026-08-13 answering an
+SD-card offer with
+
+    m=video ... 0        a=mid:0   a=rtpmap:0 H265/90000
+    m=video ... 101 102  a=mid:1   (the H264 section we negotiated)
+    m=application ...    a=mid:2
+
+Every mid is shifted by one. Matching by mid then hands our video slot the
+H265 section and drops the H264 one, and aiortc rejects the answer outright
+("Failed to set remote video description send parameters") because H265 is not
+in its codec registry. On a live offer the same shift makes every mid mismatch
+on kind, all sections get stubbed, and the open fails as a cold camera would.
+
+Mid order is still the right first guess - it is what a compliant answerer
+sends, and the A001064 quirks the mid-walk was written for depend on it. So the
+mid match stays, and the fallback only runs when it produces something
+unusable.
+"""
+
+import os
+import sys
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
+
+from aidot_cameras.camera.protocol import select_answer_section
+
+_OFFER_VIDEO_PTS = {"97", "98", "99", "100", "101", "102"}
+
+
+def _sec(kind: str, *pts: str) -> tuple:
+    """One answer section: (kind, lines), as the rebuild stores them."""
+    line = f"m={kind} 9 UDP/TLS/RTP/SAVPF " + " ".join(pts)
+    return (kind, [line, "a=rtcp-mux", "a=sendonly"])
+
+
+# The shapes below are transcribed from measured answers, not invented.
+_SD_SHIFTED = {
+    "0": _sec("video", "0"),                # H265 stub the camera added
+    "1": _sec("video", "101", "102"),       # the H264 answer we want
+    "2": _sec("application"),
+}
+
+_LIVE_SHIFTED = {
+    "0": _sec("video", "0"),
+    "1": _sec("audio", "8"),
+    "2": _sec("video", "101", "102"),
+    "3": _sec("application"),
+}
+
+_LIVE_CLEAN = {
+    "0": _sec("audio", "8"),
+    "1": _sec("video", "101", "102"),
+    "2": _sec("application"),
+}
+
+
+def test_clean_answer_is_matched_by_mid_unchanged():
+    """The common case must not move: mid 1 is the video, and stays it."""
+    for mid, kind in (("0", "audio"), ("1", "video"), ("2", "application")):
+        got = select_answer_section(mid, kind, _LIVE_CLEAN, _OFFER_VIDEO_PTS, set())
+        assert got == (mid, _LIVE_CLEAN[mid][1])
+
+
+def test_sd_offer_skips_the_h265_stub_sharing_its_mid():
+    """Our only video mid is 0, and the camera's mid 0 is its H265 section."""
+    got = select_answer_section("0", "video", _SD_SHIFTED, _OFFER_VIDEO_PTS, set())
+    assert got is not None
+    assert got[0] == "1", "should take the H264 section, not the H265 one"
+    assert "101 102" in got[1][0]
+
+
+def test_sd_datachannel_finds_the_application_section_a_mid_away():
+    got = select_answer_section("1", "application", _SD_SHIFTED,
+                                _OFFER_VIDEO_PTS, {"0"})
+    assert got is not None and got[0] == "2"
+
+
+def test_live_offer_survives_a_one_mid_shift():
+    """audio/video/application must each find their section despite the shift."""
+    claimed: set = set()
+    picks = {}
+    for mid, kind in (("0", "audio"), ("1", "video"), ("2", "application")):
+        got = select_answer_section(mid, kind, _LIVE_SHIFTED,
+                                    _OFFER_VIDEO_PTS, claimed)
+        assert got is not None, f"offer mid {mid} ({kind}) found nothing"
+        claimed.add(got[0])
+        picks[kind] = got[0]
+    assert picks == {"audio": "1", "video": "2", "application": "3"}
+
+
+def test_a_section_is_never_handed_to_two_offer_mids():
+    claimed = {"1"}
+    got = select_answer_section("0", "video", _SD_SHIFTED,
+                                _OFFER_VIDEO_PTS, claimed)
+    assert got is None or got[0] != "1"
+
+
+def test_missing_kind_returns_none_so_the_caller_stubs():
+    """A001064 drops sections outright; the caller must still get to stub."""
+    answer = {"0": _sec("video", "101", "102")}
+    assert select_answer_section("1", "audio", answer,
+                                 _OFFER_VIDEO_PTS, set()) is None
+
+
+def test_video_with_no_overlap_is_still_taken_when_it_is_all_there_is():
+    """Better a section aiortc may reject than a stub that guarantees failure.
+
+    Losing the real section would turn a recoverable answer into a declined one,
+    so a no-overlap video section is preferred over nothing at all.
+    """
+    answer = {"0": _sec("video", "0")}
+    got = select_answer_section("0", "video", answer, _OFFER_VIDEO_PTS, set())
+    assert got is not None and got[0] == "0"
+
+
+def test_no_offer_pts_falls_back_to_plain_mid_matching():
+    """With nothing to score against, the mid is the only signal left."""
+    got = select_answer_section("0", "video", _SD_SHIFTED, set(), set())
+    assert got is not None and got[0] == "0"
+
+
+# --- how long to wait for ICE, given what the answer looked like -------------
+
+from aidot_cameras.camera.protocol import ice_wait_timeout
+
+
+def test_a_clean_answer_gets_the_full_timeout():
+    assert ice_wait_timeout(shifted_sections=0, default_timeout=45.0) == 45.0
+
+
+def test_a_shifted_answer_is_capped_but_not_refused():
+    """One shifted answer in seven DID open - at 8.8 s. The cap must clear it.
+
+    Measured over 63 opens: every successful open finished ICE between 8.7 s and
+    10.6 s and every failure ran the full 45 s. There is no overlap, so a cap
+    above the success band and far below the failure band loses nothing and
+    saves 30 s on the 86% that were never going to connect.
+    """
+    capped = ice_wait_timeout(shifted_sections=3, default_timeout=45.0)
+    assert capped < 45.0
+    assert capped > 10.6, "must still clear the slowest observed success"
+
+
+def test_the_cap_never_extends_a_shorter_caller_timeout():
+    """A caller asking for 5 s means 5 s, shifted answer or not."""
+    assert ice_wait_timeout(shifted_sections=3, default_timeout=5.0) == 5.0
+
+
+# --- telling an ADDED section from a dropped or reordered one ----------------
+
+from aidot_cameras.camera.protocol import answer_inserted_a_section
+
+
+def test_an_added_section_leaves_one_unclaimed():
+    """The measured shape: the camera adds H265 and every later mid moves on.
+
+    The SD offer has two mids (video 0, application 1); the camera answers with
+    three, and the walk claims its video and application sections, leaving the
+    H265 one spare. That spare is what says a section was INSERTED.
+    """
+    assert answer_inserted_a_section(shifted_sections=2, unclaimed_answer_mids=1)
+
+
+def test_a_dropped_section_is_not_an_insert():
+    """A001064 drops rejected sections and renumbers - quirk 1 of the rebuild.
+
+    Its mids shift too, but nothing is left over. Treating that as the H265
+    shape would cut the ICE deadline of a camera whose cold open is 25-70 s,
+    on the SDES->DTLS fallback path, using a cap measured on a mains A000088
+    that opens in 9 s.
+    """
+    assert not answer_inserted_a_section(shifted_sections=2,
+                                         unclaimed_answer_mids=0)
+
+
+def test_a_clean_answer_is_not_an_insert():
+    assert not answer_inserted_a_section(shifted_sections=0,
+                                         unclaimed_answer_mids=0)
+
+
+def test_a_spare_section_without_a_shift_is_not_an_insert():
+    """An extra section nobody wanted, with our mids still lining up, is the
+    camera padding the answer - not the shift the cap was measured against."""
+    assert not answer_inserted_a_section(shifted_sections=0,
+                                         unclaimed_answer_mids=1)