[Standards] Coping with low bandwidth channels in Jingle

Paul Witty paulrw at codian.com
Wed Feb 13 12:14:26 UTC 2008

 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.



More information about the Standards mailing list