Subject: Response to LS from ETSI Date: 2010-10-21 From: IETF RAI Area Contacts: Gonzalo Camarillo , Robert Sparks The IETF is in receipt of a liaison request from the ETSI Technical Committee Human Factors (TC HF) entitled "ETSI Human Factors: Request for advice and processing of two issues within mobile and IP-based text telephony". This liaison statement requests advice concerning the registration of SIP extension headers for the purpose of delivering a real-time text application using the SIP MESSAGE method as a transport. Advice concerning the SIP Change process: Section 1 of the statement concerns the registration of two "P-" headers, according to the SIP Change Process as described and amended in RFC 5727. RFC 5727 deprecates the use of the "P-" prefix for SIP headers, except in situations where the prefix may be grandfathered for pre-existing standards or deployments. The section asserts that the proposed headers have been in use in multiple deployments in 2006. This seems to fit the spirit of RFC 5727, and would likely be approved by a Designated Expert, assuming the expert agreed with the rest of the proposal. However, it is highly likely that a Designated Expert would object to the the proposed header fields based on other requirements in RFC 5727: 1) RFC 5727 recommends that the Designated Expert review proposals for overlap with existing chartered work in the RAI area. The proposal as described appears to overlap and conflict with RFC 4103, RFC 4351, and RFC 5194. 2) The proposed header fields MUST be of a purely informational nature, and MUST NOT significantly change the behavior of entities that support it. A common behavior of endpoints that support the SIP MESSAGE method is to render one "message" to the end user for each SIP MESSAGE request that it receives. Each message is rendered as a separate block, typically with white space in between. That is, they provide an "Instant Messaging" style user experience. We assume that endpoints supporting the proposed header fields would instead render messages as a stream of text, providing more of a "real-time text" user experience. These are significantly different behaviors, and if an endpoint that does not support the proposed header field receives SIP MESSAGE requests containing the proposed headers, they are likely to render the text as a series of disjoint messages, each containing a character or two. Use of RFC 3428 for Real-Time Text: The proposal as described in the Liaison Statement involves the creation of SIP dialogs for the sole purpose of carrying MESSAGE requests in contravention of section 2 of RFC 3428, which says implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE request with one another. As stated in the Liaison Statement, the main reason for this advice is to avoid network congestion and SIP server overload. The Liaison Statement indicates that no such problems have been observed in existing deployments. However, the existing deployments described are extremely low volume. While current uses of this service may be limited to a small sub-set of users (e.g. the hearing impaired), we must consider the possibility of the service becoming available to and popular with a larger segment of the population. Participants in the IETF SIMPLE working group have calculated that a real-time text session using the SIP MESSAGE method as a transport will require around 33 kbps of bandwidth. This bandwidth typical crosses the call-control services, requiring them to operate at a significantly higher transaction load than required for more typical applications. A similar session using RTP as described in RFC 4103 only requires 4 kbps, and only traverses network nodes participating in the media streams. This is a difference on the order of 10 to 1. Therefore, we cannot recommend the standardization of the described use of the SIP MESSAGE method as a transport for real-time text applications. We highly recommend that text-over-RTP, as described in RFC 4103 and RFC 5194, be used instead.