* Call `note_stale_live555_data` when this happens in playing state.
This makes it more consistent with what happens while waiting for
a response in the described state, or in playing state on an
assigned channel.
* Print a hex dump of some initial bytes, enough to analyze it to
see if it looks like RTP or RTCP, what the ssrc is, etc. And do the
same for other places we log (parts of) packets.
* export a `Session::tool` to allow callers to see the server's
version. Servers have many quirks (including but not limited to
the live555 version bug), and exposing this can help hunt them down.
* call out when we see the live555 stale session bug with a tool not
known to be affected.
* in several log messages, identify the session group and stale
session seqnum.
* add a `log::trace!` for status within
`SessionGroup::await_stale_sessions`, just in case I get really
puzzled again.
Found by inspection. It'd be nice to fuzz the tokio module to more
reliably find problems like this, but it looks like I'd have to make
a bunch more stuff public for that. Maybe later...
This .unwrap() call would panic on e.g. an empty string, which
it would get from 'fmtp:96 ' (empty parameters).
This is for example produced by v4l2-rtspserver when it
fails to extract SPS/PPS from the first (?) packet:
d0da079177/src/H264_V4l2DeviceSource.cpp (L52)
Since writing that text, I've made some design decisions that complicate
this:
* dropping a Session uses tokio::runtime::Handle::spawn
* keepalives are tracked with a tokio::time::Sleep
* I support UDP (so multiple sockets per session), which means the
blocking API would have to use extra threads or async IO behind the
scenes.
I might make decisions that complicate it further, e.g. having a tokio
task for each socket rather than polling them all in Session::poll_next.
It's of course still *possible* to support async-std and/or a blocking
API if there's demand. It'd require more duplicate logic/APIs now, so
I'm not excited about the possibility.
