* 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.
It's allowed for a server to send only in-band parameters, although I
haven't encountered this yet. The VStarcam cameras sometimes send
invalid out-of-band parameters; treat that as if it sent nothing.
Fixes#42
