[Standards] Coping with low bandwidth channels in Jingle
paulrw at codian.com
Thu Feb 14 10:30:46 UTC 2008
Peter Saint-Andre wrote:
> Paul Witty wrote:
>> Dave Cridland wrote:
>>> On Wed Feb 13 13:13:26 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?
>>> Sometimes the user knows the bandwidth of the immediate upstream link.
>>> Often, though, they don't - people usually know the advertized maximum
>>> downlink bandwidth, but usually don't know either the upstream, nor
>>> the actual bandwidth of either direction.
>>> The actual device may know it's immediate link rate. Sometimes, at
>>> least - often actual link rates are deeply buried inside weird APIs,
>>> and finding overhead, latency, and other somewhat related link
>>> characteristics isn't usually possible.
>>> But there is indeed no practical way to know the end to end bandwidth
>>> short of measuring it, and that measurement is quite tricky. There's a
>>> very interesting paper on the subject of intermediate link measurement
>>> by van Jacobson, actually. People interested in this sort of thing can
>>> probably find it with a Google for pathchar, or download pchar (an
>>> open source implementation). You'll note it takes several minutes for
>>> each hop, and uses quite a bit of traffic to do so.
>> Fortunately, actually knowing the bandwidth is not necessary:
>> while (incoming_packet_loss)
> Ah, in that case an informational message might be more appropriate
> (just tell the other side that you're experiencing packet loss):
> <iq from='juliet at capulet.com/balcony'
> to='romeo at montague.net/orchard'
> <jingle xmlns='urn:xmpp:tmp:jingle'>
> initiator='romeo at montague.net/orchard'
> <packet-loss xmlns='urn:xmpp:tmp:jingle:apps:audio-rtp:info'/>
I'd have to question the namespace, as the message is relevant on video
rather than audio channels. Apart from that, it seems fair enough,
although if multiple video channels are open (as seems to be permitted
by the spec), it may only be necessary to send a keyframe on one of
those channels, so specifying the channel experiencing packet loss could
offer a saving in bandwidth. Presumably the spec will say that a client
receiving such a message must either return an iq_error, or must send an
iq_result and send a keyframe over the video channel?
More information about the Standards