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

From: Bruno von Niman <[email-masked]>
Date: Mon, 08 Nov 2010 00:02:23 +0100

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" <[email-masked]>
wrote:

> FYI.
> 
> Gonzalo
> 
> -------- Original Message --------
> Subject: Response to an LS from ETSI
> Date: Mon, 27 Sep 2010 21:14:10 +0300
> From: Gonzalo Camarillo <[email-masked]>
> To: [email-masked]
> CC: Robert Sparks <[email-masked]>
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Nov 2010 10:20:59 +0800

( as SIMPLE chair)

Hi,

The working group discussion so far has relied entirely on the liaison statement. It might help if we could view the mentioned draft directly. Is that draft publicly available?

Thanks,

Ben.

On Nov 8, 2010, at 7:02 AM, Bruno von Niman <[email-masked]> wrote:

> The proposed header(s) do not undermine SIP security in any sense –on the

---

From: Bruno von Niman <[email-masked]>
Date: Mon, 08 Nov 2010 08:05:57 +0100

Hi Ben,

Thanks for raising this very valid issue - I totally agree!

No, it's not (other than to ETSI members - published documents are...) but
I'm sure we'll find a good way to make it available for comments to anyone
interested; there are workarounds.
I'll have a word with Gonzalo on Tuesday and we'll get back on the topic
(through the mailing list or the Dispatch session on Thursday latest),
Bruno

On 08/11/10 03:20, "Ben Campbell" <[email-masked]> wrote:

> ( as SIMPLE chair)
> 
> Hi,
> 
> The working group discussion so far has relied entirely on the liaison
> statement. It might help if we could view the mentioned draft directly. Is
> that draft publicly available?
> 
> Thanks,
> 
> Ben.
>

---

From: Arnoud van Wijk <[email-masked]>
Date: Thu, 11 Nov 2010 11:27:02 +0100

Hi all,
Discussions about standards, and why and how to implement and the 
necessity is always very good.
But I am seeing again in Bruno's statements incorrect information.
> them, over mobile and IP-based main stream infrastructures and devices.
Yes, but this is only as a relay system specific targeted to a small and 
limited user group. These systems are nothing more then a a big island.
Where the traffic flow is low and can be predicted very well. The text 
system implemented there may not cause serious problems in that network.
That does not mean that using the SIP signaling pathway for real-time 
text is something to aim for on global IP networks!

I want to make this clear. Real-Time Text (RTT) is NOT for just a small 
group of hearing and speech impaired users. It will be a mainstream and 
usable for all people.
And that means that RTT must use the same SIP signaling and media 
transport using all what VoIP does.

That is why RFC4103 has been created. The unique thing about RFC4103 is 
that is is a standard that is created by listening and involving the 
Telecom experts, IETF and ITU and as well the hearing and speech 
impaired users to ensure that RFC4103 does fill the communication needs 
and ability for them.
We hearing impaired users want text that is equal as voice is. And that 
is possible now without clogging the signaling path, RFC4103 is fully 
supported by SIP and can be treated with any security measures possible 
for voice.

> for an open specification standard.
Which is possible and already done with RFC4103!! RTP based real-time 
text as described in RFC4103 is deployed and used widely. I am using RTT 
now. Even combined with video and audio. NENA and Reach 112 are 
implementing RTT in the PSAPs as part of Total Conversation (RTT, audio 
and video).
RFC4103 works very well through GSM. I am using that today. RFC4103 is 
part of IMS. Deployed now.
RFC4103 is able to traverse NATs just as well as VoIP, after all it uses 
EXACTLY the same SIP NAT traversal technologies. And will work with 
proprietary SIP tunneling solutions as well.

The reason that the Nordic countries use some gap filler is because 
RFC4103 is simply ignored as the open standard RTT.
RFC4103 is fully interoperable even with PSTN Text telephones using V.18 
transcoding gateways.

> well as the integrity of the communicating parties (see below).

RFC4103 has an excellent mechanism with redundancy that ensures no 
character loss. If character loss does occur, it is because the network 
conditions are so deteriorated, that even SIP will not be able to 
function. I have encountered enough situations where audio and video 
were very bad (video for me since I cannot say about audio quality) and 
the RTT was happily crunching along without dropped characters.
In the early phases of T.140 over RTP when it did not use redundancy 
first (the time of RFC2793) it was true that it had character loss. But 
that is solved and not a problem in RFC4103.

New standards, and improving standards should only be added when there 
are no proper solutions available. I am seeing arguments by Bruno here 
against RFC4103 while they are in fact all incorrect or out of date 
(RFC2793). I actually do not see why even Real Time Text using SIP 
MESSAGE has any benefit.
What can Real-Time Text using SIP MESSAGE do better then RFC4103?

For more information on RFC4103, and the systems where it is 
implemented. Please have a look at http://www.realtimetext.org/
RTT in standards: http://www.realtimetext.org/index.php?pagina=28
and other references: http://www.realtimetext.org/index.php?pagina=54

Thanks for reading through this and lets  continue doing real work!

Arnoud van Wijk

On 08-11-10 00:02, Bruno von Niman wrote:
> On 27/09/10 20:14, "Gonzalo Camarillo"<[email-masked]>
> wrote:
>
>> FYI.
>>
>> Gonzalo
>>
>> From: Gonzalo Camarillo<[email-masked]>
>> To: [email-masked]
>> CC: Robert Sparks<[email-masked]>
>>
>> Hi,
>>

---

From: Bruno von Niman <[email-masked]>
Date: Thu, 11 Nov 2010 13:19:07 +0100

Hi Arnoud,

Thanks for your detailed feedback! I'm glad you welcome the discussion.
I compact my feedback to keep it more understandable, also to other readers.

Issues I don't answer is because they are covered better by other experts I
instead invite to contribute.

> system implemented there may not cause serious problems in that network.
Glad we can fully agree so far.

> text is something to aim for on global IP networks!
This is totally out of our scope and maybe we should make that very clear in
our Scope? Would that make the proposal more acceptable?

> group of hearing and speech impaired users. It will be a mainstream and
I don't disagree but our focus is only on the provision of accessibility
services. Maybe we should rephrase the ETSI TS' scope and title?

> impaired users to ensure that RFC4103 does fill the communication needs
None of us argues about the future: once the networks and standards
necessary to make it work are out there (IMS), 4103 is the way to go. But
that will take some time...
One group you've then probably forgot to include is the current text
telephony service providers, who cannot (yet) commit to 4103 and deliver
upon their quality commitments.
By the way, by the time RFC 4103 was published (June 2005), the other
service was launching its first trial...(open tender in 2005, pilot launch
in 2006). 
> supported by SIP and can be treated with any security measures possible
I totally agree - but I also assume the typical hearing impaired user will
not care at all about how the support is provided technically:-)!

> implementing RTT in the PSAPs as part of Total Conversation (RTT, audio
Well, "widely" is probably a slight exageration:-)!
Reach112 is an recently started, EU co-funded project, not a deployed,
public, societal service!
I've seen proprietary services but not yet a well-working standard
implementation as a service....hope it's in the pipeline!
> part of IMS. Deployed now.
To my knowledge, IMS isn't really deployed in the global (not even the
Nordic) market yet...anyone aware of any other reality?
I'd also be interested to know if you're getting all characters? In trials
I've seen and I've been quoted, characters were lost!
> proprietary SIP tunneling solutions as well.
I'd rather let those with more technical knowledge and aware of the details
report back!
> RFC4103 is simply ignored as the open standard RTT.
No, it's not: it's (at least, in some cases) because of the quality issues
4103 was experiencing when the open tenders were put out!
> What can Real-Time Text using SIP MESSAGE do better then RFC4103?
We should probably invite some real-service providers to report their
empirical views, based on some years' real-life deployment and technology
choice; I'll see what I can do!
One real, national service provider states that using a 4103-based
implementation provides a technology that "...could not be used to deliver
upon the required quality commitments".
> and other references: http://www.realtimetext.org/index.php?pagina=54
I've looked at realtimetext.org and must confess, there's lots of
information (and I also recognized several of those negatively commenting
the ETSI liaison and proposal before as RealTimeText Directors, et
cetera...that doesn't really help confidence!).
Unfortunately, I could not find any information about deployed systems where
it's implemented and used today...can you please provide a better reference,
if available over current deployments?
> Thanks for reading through this and lets  continue doing real work!
Thanks for your input and assumed support for our gap-filler with the
modifications we'll consider, to ensure we harmonize and collaborate for
interoperability - in the interest of all hearing impaired users!
Bruno von Niman

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Nov 2010 01:58:04 -0500

> our Scope? Would that make the proposal more acceptable?

Why would hearing impaired people (or anyone) in the Nordics+Germany not want to communicate globally?  
Many people in the Netherlands can read/write German, and of course Austria and Switzerland.
And I would think some smart person would write a real-time translation program to translate languages for real-time-text as well.

You can say "but it's only for the Nordics+Germany", but that would be misleading, since ETSI affects all of Europe, and presumably Europeans would not want to be isolated from the rest of the World.

Unfortunately SIP MESSAGE is not a ubiquitously supported SIP method, either.  Especially not across transit service providers, and not on international links.  Some providers assume it to be SMS, which is billed and routed very differently.  Would you be ok with charging hearing-impaired people on a per-character basis?

> upon their quality commitments.

Then why isn't ETSI submitting a liaison for *that* issue?  We can fix that.

> service was launching its first trial...(open tender in 2005, pilot launch

RFC 4103 was published in 2005, but its predecessor RFC 2793 was published in 2000.

> Nordic) market yet...anyone aware of any other reality?

IMS is "deployed" in numerous countries around the World, including many in Europe.  I don't know about Nordic countries in particular, but I can find out if it really matters.
Having said that, it's frequently deployed in a way you wouldn't know/care about - it's in the "network" and not SIP/RTP all the way to your handset.

> I've seen and I've been quoted, characters were lost!

Then let's go fix that, if it's a real problem.

> I'd rather let those with more technical knowledge and aware of the details

I don't know if it will always work from behind NATs, though I haven't heard of any complaints.  I was actually expecting it to have a problem, but it hasn't so far.

-hadriel