[Standards] Coping with low bandwidth channels in Jingle

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 13 22:46:10 UTC 2008

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)
> {
>    advertise_less_bandwidth();
>    wait_for_a_bit();
> }

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'/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080213/2757f563/attachment.bin>

More information about the Standards mailing list