[Standards] Coping with low bandwidth channels in Jingle

Paul Witty paulrw at codian.com
Wed Feb 13 14:01:18 UTC 2008

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.



More information about the Standards mailing list