RTSP streaming fails for cameras that worked in v3.0.58 — investigate Sprint 6 regression

[kumaakh]

Symptom

Cameras that streamed successfully in v2.2.252.x fail to open an RTSP stream on feat/media2-support. ONVIF negotiation completes correctly (GetProfiles, GetStreamUri succeed, valid RTSP URI is returned), but the stream never opens. One camera (10.102.10.97) briefly initialised the decoder (PixFrmtImpl::Create) then stopped immediately — suggesting the stream opens momentarily then is cut.

What changed in Sprint 6 that could cause this

Sprint 6 introduced the following changes to NvtSession.fs that wrap the ONVIF call chain:

1. withMedia2HttpFallback / withMedia1HttpFallback — combinators that catch IsConnectionRefused and retry via raw HTTP xAddr. These wrap GetProfiles, GetStreamUri, and 6 other methods. If the fallback branch creates a new channel without the correct session token, the RTSP URI could come back from an unauthenticated context.

2. ServicePointManager.Expect100Continue = false (global) — applied at CreateSession. Could affect behaviour of any HTTP channel including the ONVIF media endpoint that returns the RTSP URI.

3. UpgradeScheme — already filed as UpgradeScheme incorrectly overrides sub-service URLs returned by GetCapabilities/GetServices #26. For HTTP cameras this should be a no-op (no change logged), but needs verification.

Investigation needed

1. Compare the RTSP URI returned by GetStreamUri in feat/media2-support vs. the URI a v2.2.252.x build returns for the same camera — are they identical?
2. Check whether withMedia1HttpFallback on GetStreamUri could be returning a result from the fallback channel (HTTP, no token) instead of the primary channel
3. Check whether ServicePointManager.Expect100Continue = false affects the RTSP-over-HTTP path (if any camera uses RTSP/HTTP tunnelling)
4. Add logging: in withMedia1HttpFallback and withMedia2HttpFallback, log which branch (primary vs. fallback) actually returned the result

Environment

Confirmed failing: 10.102.10.97, 10.102.10.75, 10.102.10.42, 10.102.10.61, 10.102.10.77
All are Media1-only HTTP cameras.
Previous build (v2.2.252.x): streams successfully.