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

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

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.

On 11/11/10 11:27, "Arnoud van Wijk" <[e-mail]>
wrote:

> 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.
> Why? let me comment here:
>> 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.
> 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.
Glad we can fully agree so far.

> That does not mean that using the SIP signaling pathway for real-time
> 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?

> 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.
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?

> 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.
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). 
> 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.
I totally agree - but I also assume the typical hearing impaired user will
not care at all about how the support is provided technically:-)!

>> 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.
> 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).
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!
> RFC4103 works very well through GSM. I am using that today. RFC4103 is
> 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!
> 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.
I'd rather let those with more technical knowledge and aware of the details
report back!
> 
> The reason that the Nordic countries use some gap filler is because
> 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!
> RFC4103 is fully interoperable even with PSTN Text telephones using V.18
> transcoding gateways.
> 
>> 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).
> 
> 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?
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".
> 
> 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
> 
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!
> Arnoud van Wijk
Bruno von Niman
> 
> On 08-11-10 00:02, Bruno von Niman wrote:
>> 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
>> 
>> _______________________________________________
>> Simple mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/simple
>> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
>