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

[Arnoud van Wijk <[e-mail]>]

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

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

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:
> 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
>