[Standards] Coping with low bandwidth channels in Jingle

Lauri Kaila lauri.kaila at gmail.com
Wed Feb 13 13:13:26 UTC 2008

2008/2/13, Paul Witty <paulrw at codian.com>:
>  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.

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?

> 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?


More information about the Standards mailing list