Re: [Simple] Fwd: Response to an LS from ETSI

[Bruno von Niman <[e-mail]>]

Dear SIMPLE!

ETSI TC Human Factors has received your liaison reply (available, together
with the liaison statement, at
https://datatracker.ietf.org/documents/LIAISON/file1119.txt and
https://datatracker.ietf.org/documents/LIAISON/file1085.doc) and will
address it at its next meeting, in February 2011.

As work item rapporteur, I'd like to thank you for it and follow it up in
some more detail through this thread, for some clarifications and individual
comments (especially as due to our lack of experience with IETF work, the
discussion between us never really got going).

To recap: the technology referred to in the liaison is deployed in all
Nordic countries (except Iceland), in Germany and some others and is used to
provide societal accessibility services, as required in the respective
countries, to hearing impaired people and those who telecommunicate with
them, over mobile and IP-based main stream infrastructures and devices.

For the future, in the IMS era (foreseen to become enough penetrated and
mature in some years' time in 3G/4G environments), there are
state-of-the-art technologies envisaged and well specified (in 3GPP, or
through the GSM Association Rich Communication Suite (RCS)), expected to
become the main stream. However, no solutions requiring this kind of
technology enablers are yet deployed today and will probably not be tomorrow
either; it will most probably take years until they do.
Deaf people cannot wait years, until this environment becomes a market
reality, as they'd love to communicate today - across the reliably available
mainstream infrastructures and devices of today!

This has been sorted out in the Nordic countries; it's a gap-filler but it
works now, across all networks (with a Nordic gateway under development).
However, to allow third parties to develop their products and avoid
segmentation and proprietary, non-interoperable solutions, there is a need
for an open specification standard.

In your reply, you explain that our P-header registration request 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, you also mention that the proposal as described appears to overlap
and conflict with RFC 4103, RFC 4351, and RFC 5194 and it may lead to
disjoint message behaviors.
We do not believe this will necessarily be the case, as these are covering
different scopes and are used for different purposes (as explained in the
liaison and below).
Furthermore, the disjoint behavior referred to is well managed through
personal preferences on the user interface level of the device and will
deliver upon the applicable user preference expectations, as there are
typically two categories of users with regard to this (segmented by the use
of predictive text input preferences).
The proposed header(s) do not undermine SIP security in any sense ­on the
contrary! This request is to guarantee the full delivery of all characters
in the text strings, not achievable with RFC4103 (due to character loss), as
well as the integrity of the communicating parties (see below).
Would this not cover all scenarios you've thought of, we'd appreciate if you
could develop it a little more in detail.
We'd rather comply, than use a different type of header (unless necessary)!

As for the use of RFC 3428 for Real-Time Text: the calculation of the IETF
SIMPLE experts (33kbps) corresponds in magnitude to the empirical data we
have collected from several sites running the service in real-life
installations (stretching between 15 kbps to 50 kbps in older version
installations). They may be small (although Germany has the largest
population in the EU!) - but they are real and correspond to the need of
most European countries, as the current service is a societal service and it
IS limited to hearing impaired people and their contacts.
This service is not intended to become available to any larger segments of
the population.
Last but not least, it is considerably more important for the service
provider to offer the best possible service quality (as character losses in
text communication may lead to serious implications) than to save some bucks
on server capacity (that will be dimensioned as needed).

In your reply, you mention that "...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" (although we'd rather say "considerable", as the ratio may be as
low as 4:1 in some cases - but that's less relevant, as there is absolutely
no evidence of capacity issues).
The problem with RFC 4103-based implementations in today's networks is NAT
traversal in GSM (that still doesn't work), with new issues faced for Wi-Fi
and character loss in transmissions- two heavy reliability reasons to why
it's been completely rejected so far by service providers (there are NO
deployed services in operations, running RFC 4103 today).
In the future, as mentioned above, it's a different story - but the gap to
fill is NOW!
Even so, to be forward-looking, we'd like to mention the fact that there are
sharp interoperability requirements with RFC4103 in the ETSI draft Technical
Spec. 

Consultation with the RFC Editors indicates that the "SHOULD NOT" used in
RFC 3428 is to be interpreted as a "don't do it, unless you have a good
reason to do it". We believe to have a real good reason- or even two! So,
hopefully, it should be a show-stopper!

We'd be glad to continue discussions (over email, in or around this week's
meeting and after it), to agree some reasonable solution and consensus that
could allow you to accept or endorse the standardization of the described
use of the SIP MESSAGE method as an exceptional transport for real-time text
applications under the highly extraordinary circumstances described in the
liaison statement, as a gap-filler.
We'd be glad to use text-over-RTP, as recommended by you and as described in
RFC 4103 and RFC 5194 - if it was a workable direction for today's networks.
It is not, but we still need to offer hearing impaired people inclusive
communication services on equal terms NOW; we much hope that you can
contribute to achieving that vision, rather than raising another difficulty
(it's been quite some to pass already)!

With best regards,
Bruno von Niman
ETSI Human Factors 
ETSI HF work item Rapporteur


On 27/09/10 20:14, "Gonzalo Camarillo" <[e-mail]>
wrote:

> FYI.
> 
> Gonzalo
> 
> -------- Original Message --------
> Subject: Response to an LS from ETSI
> Date: Mon, 27 Sep 2010 21:14:10 +0300
> From: Gonzalo Camarillo <[e-mail]>
> To: [e-mail]
> CC: Robert Sparks <[e-mail]>
> 
> Hi,
> 
> as you probably know, we have received the following liaison from ETSI:
> 
> https://datatracker.ietf.org/documents/LIAISON/file1085.doc
> 
> Based on the discussions on the SIMPLE WG list, we have put together the
> response in the attachment. We intend to send it to ETSI on Thursday.
> Let us know if you have any comments on it before then.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple