Coding and transmission of text in real-time and en-bloc mode based on MSRP

A set of mechanisms must be defined in order to assure consistent user experience when using MSRP RFC 4975 for text communication in SIP sessions. One style of usage of MSRP based text sessions is the real-time text conversation that makes use of time sampled transmission. Another style is Instant Messaging with user initiated transmission of complete messages. MSRP is a general transport method mainly intended for messages. The capability for real-time text transmission needs to be indicated, so that the users can agree on a common view of the conversation. A time sampling of 500 ms or less is required in order to achieve the end to end delay of less than 1 second that is needed for effective real time text conversation, . Requirements for presentation of conversations using real-time text is found in [draft-hellstrom-textpreview] . Traditionally the real-time text medium can be transmitted with RTP, as specified in RFC 4103. This specification describes how to implement these functions with MSRP.User initiated transmission of MSRP text messages also need to follow presentation conventions in order to be presented as expected by the sending user. It is specifically the following features that need to be defined: Functional requirements. Media type and subtype specification and negotiating. Presentation coding. Text Erasure New lines Other presentation control functions Indication and negotiation of the time-sampled transmission capability Time sampled transmission Routing of calls to real-time text capable devices. Sessions including MSRP-based real-time text and other media. Performance Security

The procedures defined in this specification are intended to provide a text transport mechanism fulfilling the following requirements.

Presentation of text shall be possible in one internationally useable character set. Presentation within messages shall be done contiguously so that it is easily read. It shall be possible to use the text transport method in a session together with other media. It shall be possible to use the text transmission in SIP sessions. A set of characters shall be defined for any specific language environment to cause end of message. It shall be possible to protect the text contents from reading and modification from others than authorised adressees. It shall be possible to guide routing of calls who may need text to specific devices capable of handling text transmission.

The real-time transmission and presentation of text shall be done in a way so that the users experience a flow of text approximately as it is typed. The delay from character entry to remote display needs to be less than 1 s in order to maintain effective real-time conversation. Therefore the maximum delay before transmission of any character shall not be longer than 500 ms. It shall be possible to erase already transmitted text in the current message.[see issues-list] It shall be possible to negotiate between MSRP and other SIP-based standardised transport methods for real-time text at session setup. It shall be possible to transmit at least 30 characters per second. It shall be possible to guide routing of calls who may need real-time text to specific devices capable of handling this text transmission mode. The main purpose of this requirement comes from the requirment to find a text capable gateway to PSTN for text telephony. It shall be possible to use the real-time text transmission in SIP sessions.

The transmission and presentation of text shall be done so that the users experience a transmission of text when a specific transmission action is made.

In SIP sessions, SDP MUST indicate the media type 'message'. The Content-type is specified in the MSRP header. For real-time text, support MUST be provided for content-types text/plain and for message/cpim with text/plain content. In addition, other content-types MAY be supported in real-time text mode.

SDP Examples Figure: SDP example for a text-only session The MSRP messages and chunks contain headers indicating the media type and subtype actually used. For the real-time text usage a send request MAY look like this:

MSRP Chunk exaMPLE Example: MSRP chunk

Text shall be coded with an internationally applicable character set. The text/plain MIME type is defined to be used according to this specification. Coding with utf-8 shall be used. RFC 3629

When operating in real-time text mode, text shall be collected for transmission during a time interval and then transmitted as an MSRP chunk. The maximum delay of any character before transmission MUST be 500ms. For good flow it SHOULD be 300 ms. For en-bloc mode, no timer-initiated tansmissions are required. Text MAY be sent in chunks, and recombined in complete messages by the receiver.

It shall be possible to insert a new line in the text. A new line serves as message delimiter. Unicode Line Separator (UCS-16 2028) or CRLF SHALL be used for transmission. In reception, Line Separator, CR, CRLF, LF shall all have the same effect and be regarded as one operation.

BEL may be sent to cause an external alerting action from the receiving terminal, but shall otherwise be treated as a non-printable character and have no impact on the display.

The following actions MAY cause the End of Message condition: Pressing Enter, pressing Return and pressing a Send button. The actual selection of end of message reasons is a sending application decision. At the End of Message condition, any unsent characters in the session MUST be transmitted with an End of Message indication in MSRP.

Erasure of the last character shall be signalled by a 'BS' character. Erasure shall have effect on the local and remote presentation of text. Locally inserted new lines by presentation logic only for layout purposes shall not be transmitted and therefore do not require any specific erasing action. New Lines inserted by the sending user MUST require one BS to be erased. The complete current message MUST be kept available for erasure. Characters that do not occupy a position in the display shall not require any BS for erasure, but if they have any effect on the presentation, they shall be regarded to be erased when the character before it is erased. BEL is one such character. Completed messages are not available for erasure.[see issues-list] [To issues-list: The relation between character position indications in MSRP headers and real printable position in a message needs to be defined. Possible alternative erasing action by chunk position and new character for replacement may be introduced]

When using the media format text/plain, no other presentation controls than the ones described above can be conveyed in communication. Both users may vary their presentation locally.

The capability to present and transmit real-time text with MSRP MUST be declared by the following means: a. An attribute a=real-time-text, in the media description for the media=message declaration intended for the real-time text conversation. b. A Content-disposition=immediate-presentation to be included in the MSRP headers in the chunks and messages. c. The capability to present and transmit real-time text by any transport SHALL be declared by a media feature tag sip.real-time-text=<any defined value> in the SIP Contact header. This tag is also used by other text transports and may be used to determine if there is any real-time text support in the remote device.

The availability of characters ready for transmission MUST be checked at regular time intervals. The interval MUST be set to 300 ms for good user experience. When there is something to transmit at the end of an interval, the text SHALL be transmitted in an MSRP message chunk. No extra character SHALL be added to the text before transmission. When an End of Message condition is detected, the last characters of the message shall be sent immediately, with an End of Message MSRP indication. [see issues list]The chunk position counter shall be regarded to point at a position in a message transmission buffer including all characters that have been transmitted for that message. BS and BEL shall thus increase the chunk position value as any other characters. The Chunk position MUST NOT be used to directly address any presentation position on a display of the text.[see issues list]

Example: Figure: Real-time text chunks.

Text received from one session participant MUST be presented with some indication of the source. Text received within one message MUST be presented in one contiguous area. MSRP Chunks of the same message MUST be presented consecutively as soon as possible after reception, with no inserted character or editing control between the chunks. Characters MAY be added to a display singly so as to smooth presentation. Local presentation conventions MAY be applied to e.g break lines with word-wrapping.

A real-time text indicator in the SIP header MAY be used for routing of calls to real-time text capable devices, using the principles of caller capabilities and callee preferences from RFC 3840 and 3841.

Other media MAY be negotiated in the same SIP session setup as the MSRP session.

This specifications register the following new items: MSRP SDP attribute a=real-time text Indicates capability to use real-time text. [see issues-list] Contents-disposition=immediate indicates that if fragments of the complete text message is received, the fragments shall be presented without waiting for later fragments.[see issues-list] Note to RFC Editor: this section may be removed on publication as an RFC.

This chapter contains a collection of issues that have been discussed and not yet been resolved. The intention is to delete this section after resolving the issues. 1. Erasure 1. A possibility to erase back over message borders may be appreciated. One of the tensions appearing in traditional IM is of the non-erasable characteristics of sent text. Technically it gets complex to allow erasure further back, because MSRP does not have any defined way to address earlier messages than the current one. Also in interpreting the presentation of a dialogue after modification can cause confusion. But, it is a desired feature. A check with users is needed to decide on the functionality. A proposed function is to allow erasure represented by the earlier completed message being brought back for editing, but only erasure is allowed, and shall have te effect of replacing characters with xxx. When new text is then typed. The partially erased message is closed and a new message begun. 2. Erasure 2. The use of charater position within chunk and message must be explored and defined. It must also be explained how it is affected by erasure. Shall BS always be translated into a replacement of a previously sent character by its position? 3.Erasure 3. Is the wording of handling of non-printable characters during erasure sufficiently described. 4. The use of chunks for time sampled transmission of text has been questioned. The primary intent of the chunk concept was said to be for avoiding congestion situations. It needs to be agreed if the reason to get a progressive presentation of a growing message is also an appropriate use of chunks.