Op 28/06/2012 14:18, Simon McVittie schreef:
On 28/06/12 05:22, Kurt Zeilenga wrote:
I guess bandwidth-challedged XMPP networks should be fair and, if they
want to block one real-tine conversation method, block them all.
RTT and audio/video do have a significant technical difference: RTT is
in-band, and audio/video (at least as implemented in Jingle) are
out-of-band.
For in-band protocols the extra traffic (stream of partial messages)
goes through the server, whereas in out-of-band protocols, the vast
majority of the extra traffic is out-of-band, and the XMPP server only
sees some relatively lightweight signalling, which is O(number of calls)
rather than O(total length of calls). If Alice and Bob communicate via
(say) jabber.org, the Jingle traffic is a cost for Alice, Bob and their
respective ISPs, whereas the in-band XMPP traffic is a cost for Alice,
Bob and their ISPs, but also for jabber.org.
RTT over Jingle + ICE-TCP would be a closer equivalent, if there was a
finished XEP for Jingle + ICE-TCP; or in principle, RTT could even go
over ICE-UDP like audio and video do, if it can survive packet
loss/re-ordering.
I has disagree. RTT works already with SIP. See more info: Supported
real-time text codec is t.140.
RTT must be convert to codec t.140 in SIP.
Now, RTT is considerably "lighter" than audio/video, so it's not
necessarily a *significant* bandwidth cost for jabber.org (or whatever
server Alice and Bob are using) - but it is extra bandwidth that
jabber.org would not otherwise be using.
S
