Sounds great!

Looks like backchannel is defined in the ONVIF Streaming Specification, section 5.3.

Here are my first thoughts on the interface:

• We probably want a knob in the retina::client::SessionOptions to say if the caller is interested in the backchannel, defaulting to no. If we always check for it, when the caller doesn't want backchannel and the server doesn't support it there'd be a useless round trip where the server says 551 Not Supported in response to the DESCRIBE.
• We need a new accessor in retina::client::Stream so the caller can know if the stream is for receiving or sending.
• retina::client::Session<Playing> would have to implement futures::sink::Sink as well as futures::sink::Stream so the caller can send things. I think most likely the item should be similar to a retina::client::Packet but not exactly the same. Packet has context information for a received packet; we probably want to just leave that out. I say Packet rather than PacketItem because I don't think we want/need a way for the caller to just directly send RTCP; most likely Retina should handle the RTCP sender reports/receiver reports itself.
• The struct returned by retina::client::Session<Playing>::demuxed should also implement Sink for the higher-level API that handles the RTP- and codec-specific logic for "muxing" / "payloading" / "packetization". (We should probably also should rename the method/struct, as demuxed is now confusing.) The sink would take another item type similar to retina::codec::CodecItem.

How does that match what you're thinking?

Would you still be interested in reviewing a PR for this?

@cody-the-casual-dev yes I can try to review. I have no my doorbell cams anymore but still can check (I changed my job :) ).