About XEP-0301 In-Band Real-Time Text www.xmpp.org/extensions/xep-0301.html
On Fri, May 18, 2012 at 3:43 AM, Darren Sturman < darren.stur...@teligent.co.uk> wrote: > Have you been able to test the formula that you have indicated? > > ** ** > > From a user perspective how do you rate word by word transmission as > versus character by character.**** > > Personally I feel character by character has a smoother and cleaner > transmission appearance for the user whereas word by word appears to be > unnatural, however a design team member at our customer does not agree. > About the formula for XEP-0301 bandwidth: I've been able to test this formula in a narrow variety of scenarios. The rationale of creating a formula is to predict bandwidth, partially because there has not yet been enough tests in a wide enough variety of situations yet. I am working with Gunnar to create a document that I can put on realjabber.org for vendors (like you) that find this data useful. I will email you a draft later today. About character output vs. word output: The XEP-0301 standard permits either way, but most of us personally prefer character output. There are pros and cons of each approach. You can also combine the two (time-smoothed word output) which is a good compromise that I believe Gunnar also likes. Theoretically, it's possible to make this a configurable option (character vs word output) either on the sender end, or on the recipient end. It's easier to do on the sender end, but there are advantages to letting the recipient end do it. I would suggest that you tell your party about this link: http://www.realjabber.org/real_time_text_demo.html And also tell them to read section 6.1.2 and 6.1.4 of XEP-0301: http://xmpp.org/extensions/xep-0301.html#preserving_key_press_intervals You can also tell them that there is already ready-made source code that already takes advantage of key press intervals, too. (for C# and Java projects, other languages coming over the next while) Pros and Cons of character vs word output: There are pros and cons of each approach. Generally, if it's a relay service, text-to-voice, voice-to-text, captioned telephone, stenotype machine, we prefer word output (preferably time-smoothed) since we don't really care about an operator's typing mistakes. However, if it is two deaf people typing directly to each other, most of us prefer keypress output. Normally, keypress output can become jerky because of network latencies (variable pings). However, XEP-0301 is specially designed preserve key press intervals (in a way fairly immune to ping variances/jitter/etc). Because this is possible with XEP-0301, we prefer to be able to see the "emotion" of typing. However, not everybody likes watching typing mistakes, but generally we found that most people we've chatted to prefer being able to see the typing flow naturally. Example of "typing emotion": Look at the calm-versus-panicked typing at the beginning and the end of http://www.realjabber.org/real_time_text_demo.html and you can tell the difference between error-free calm typing and panicked hurried typing. You can't tell the difference if you don't preserve key press intervals. Compromise Idea: If this is a highly polarized or sensitive issue that can stall a project -- a diplomatic solution -- make it a configurable option (even just internally), and later let the customer decide or let the end-user choose in Preferences. Although it's easier to make this a configurable option on the sender end, it is preferable to make it a configurable option on the recipient side where the recipient's screen redraws the real-time-text buffer only when spacebar is rendered, or when a small amount of time elapsed with no incoming real time text). That way, the sender can send full key presses with intervals, and the recipient software can decide to display word-at-a-time (refresh incoming text when spacebar received, or small idle moment) or display keypress-at-a-time (refresh incoming text during every action element). Please note, on average, the use of Natural Typing (keypress intervals) can make some projects significantly more complicated. However, since ready-made modules (C# and Java) are available, it makes sense to take advantage of Natural Typing for XEP-0301 Cheers, Mark Rejhon Author of XEP-0301 > ** > > Kind Regards**** > > ** ** > > *Darren Sturman BSc (Hons) IT & Comp; MSc Soft Dev* > > *Senior Software Engineer***** > > ** ** > > Teligent Limited**** > > Teligent House**** > > 2 Kings Hill Avenue**** > > Kings Hill, West Malling**** > > Kent ME19 4AQ**** > > England, UK**** > > ** ** > > Telephone: +44 (0) 1732 879 694**** > > Mobile: +44 (0) 7968 130 668**** > > Facsmile: +44 (0) 1732 879 601**** > > Email: darren.stur...@teligent.co.uk**** > > Skype: darren.sturman.teligent**** > > Website: www.teligent.co.uk**** > > ** ** > > [image: Description: cid:image001.gif@01CAC4EF.5BFD8690]**** > > ** ** > > Disclaimer: **** > > The information in this email is confidential. The contents may not be > disclosed or used by anyone other than the addressee. If you are not the > intended recipient, please notify the sender immediately at the above > address. The sender cannot accept any responsibility for the accuracy or > completeness of this message as it has been transmitted over a public > network. If you suspect that the message may have been intercepted or > amended, please contact the sender.**** > > ** ** > > Teligent Ltd is registered in England and Wales, registration number > 2893478, registered office Lion House, Red Lion Street, London WC1R 4GB. > VAT registration GB639938577**** > > ** ** > > *From:* marky...@gmail.com [mailto:marky...@gmail.com] *On Behalf Of *Mark > Rejhon > *Sent:* 17 May 2012 18:56 > *To:* Darren Sturman > *Cc:* standards@xmpp.org > *Subject:* Re: Average packet size of XEP-0301**** > > ** ** > > Some minor edits:**** > > ** ** > > On Tue, May 15, 2012 at 4:02 PM, Mark Rejhon <webmail...@marky.com> wrote: > **** > > Regarding XEP-0301 at http://www.xmpp.org/extensions/xep-0301.html**** > > I have a mathematic formula for the bandwidth of XEP-0301 as follows:**** > > **** > > The biggest impact on bandwidth of XEP-0301 are as follows:**** > > (1) Is key press intervals being preserved? (Natural Typing) (uses more > bandwidth)**** > > Section 6.1.1 at > http://xmpp.org/extensions/xep-0301.html#text_presentation**** > > Animation: http://www.realjabber.org/real_time_text_demo.html**** > > (2) What transmission interval is being used? (shorter uses more > bandwidth)**** > > Section 4.4 at > http://xmpp.org/extensions/xep-0301.html#transmission_interval**** > > (3) Is XEP-0138 stream compression being used? (uses less bandwidth)**** > > See http://xmpp.org/extensions/xep-0138.html > (4) Are you using an optimized XMPP server that keeps headers compact? > (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or <x> > tags). This overhead is added by Google Talk's servers and adds an > additional >100 bytes per <message> packet.**** > > ** ** > > [now edited for correctness] **** > > *Math Formula for Bandwidth of XEP-0301:***** > > Here is a math formula for estimating the bandwidth of XEP-0301, for > regular typing:**** > > ** ** > > X = (H + (M + (K * i * N)) * C) * (1 / i)**** > > ** ** > > Where:**** > > X = Average bandwidth, in bytes per second.**** > > H = Average TCP/IP packet header overhead. **** > > .........40 if using regular headers.**** > > .........10 if using header compression. (Average. This varies. Adjust > appropriately for your network)**** > > M = Minimum <message> overhead in bytes, including <rtt> and one XEP-0301 > action element.**** > > .........120 if highly optimized XMPP is used. (super compact jid's)**** > > .........200 if reasonably optimized XMPP is used. (public full jid's, > infrequent extra payload)**** > > .........400 if Google servers is used.**** > > K = Number of keypresses per second. (Divide WPM by 12, so use K=5 for 60 > WPM)**** > > N = Overhead per keypress.**** > > .........1 if Natural Typing is not used**** > > .........20 if Natural Typing is used (Average. This varies a bit, i.e. > editing vs typing)**** > > i = Transmission interval between packets in seconds. Note: Variable is > used twice in formula.**** > > .........Recommended value is between 0.3 to 1.0**** > > C = Compression factor of XMPP**** > > .........1 if no compression used**** > > .........Less than 1 if compression used (XEP-0138 or TLS). Use a value > of 0.2 for 5:1 ratio.**** > > ** ** > > Two edits were made:**** > > 1. N=20 instead of N=10 if Natural Typing is used. Gunnar pointed this > out, and I realized I neglected to count the bytes of the <w/> elements in > addition to the bytes of the other action elements such as <t/>.**** > > 2. One pair of missing parantheses have been added.**** > > ** ** > > Recalculating the bandwidth of XEP-0301 with these minor adjustments, > result in only a minor change to the calculated answers (a few bytes per > second).**** > > ** ** > > Thanks, > Mark Rejhon**** >
<<image001.gif>>
