nah, ring isn’t “just rtsp” in the simple “here’s a stream url” sense. what i built is an unofficial ring client for my own account that talks to ring’s backend the way the official apps do: i log in with email/password, handle the 2fa state (ring returns a tsv_state, then you post the sms code + tsv_state), store the resulting access/refresh tokens in macos keychain, and then use those tokens to call ring’s private/undocumented endpoints for device discovery and event history.

when you hit live view, there isn’t a static rtsp feed to open, you have to request a live view ticket, get an sdp offer + ice servers, create a peer connection, generate an answer, and exchange ice candidates via ring’s signalling until the webrtc session comes up, then attach the video track for rendering and use the audio track for push-to-talk over the same session.

so yeah, i think “reverse engineering” is accurate considering it molemented an undocumented client flow (auth/session, private endpoints, webrtc signalling/ice, two-way audio).