From what I can tell, there's no way to transmit bandwidth information
when setting up Jingle sessions. Though not especially critical for
audio, particularly if using a codec such as G.711, with a fixed
bandwidth, it can be very useful to limit the bandwidth usage for video,
as low powered computers can struggle to cope with high bandwidth
video. Also, it's not unlikely that Jingle will be used over ADSL
lines, which typically have a limited upstream bandwidth, which could
easily cause RTP packets to be discarded, meaning that the far end will
receive poor quality video, and has no ability to do anything about it.
I propose having some method for a client to specify the receive
bandwidth for each channel. Ideally this would be for each candidate,
so that e.g. a TCP relay can advertises a lower bandwidth than UDP.
Implementation would be with an optional attribute 'bandwidth' in the
candidate, giving the bandwidth in kilobits/second, with assumed
unlimited bandwidth if not present. It may also be desirable to set
bandwidth per channel, or per call.
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.
--
Paul
- [Standards] Coping with low bandwidth channels in Jingle Paul Witty
-
