Lauri Kaila wrote:
If I understood you, a client should know its network capacity. Then
it tells that infromation to the other end so they can agree on the
best media fromat that doesn't exceed the limit. But isn't it almost
impossible to know actual end-to-end bandwidth beforehand unless some
kind of QoS is present?
Not if the client has a drop-down box to allow the user to say what kind
of connection they have. Though this is hardly a reliable way of
getting bandwidth info. Seeing as Jingle allows successive generations
of candidates, it would be easy enough to send an initial candidate
allowing unlimited bandwidth, and then sending further generations
reducing the bandwidth until no (or suitably low) packet loss is detected.
Furthermore, according to the latest TURN spec TURN relays must choose
the bandwidth they allocate to each channel through them, and report it
back to the client. This information should be passed on to the far end
to ensure the allocated bandwidth is not exceeded.
Additionally, having a method for sending fast update requests, in order
to get a complete keyframe from the far end, would allow recovering from
packet loss. I can't see where this would fit into the existing Jingle
action types, perhaps either as a content-modify, or a session-info.
Content-modify doesn't seem quite right, as it's not modifying anything;
likewise session-info is also not right, as it's a channel-level rather
than session-level message.
Using RTCP could help. I don't know anything about video streaming,
but wouldn't be enough that the sender knows about the packet drops at
the receiver's side?
RTCP is not sufficient, as generally a client will want to request a new
keyframe when the video decoder needs it, rather than when the client at
the other end thinks, based on regular RTCP messages, that a keyframe
may be required. Fast update requests are the way things are done in
the H.323 and SIP worlds, and generally more supported than RTCP. From
a quick read of RFC 3550, the use of RTCP is intended more towards
network-level rather than video-level error reporting.
--
Paul
