Subject: [Simple] The real time text thread: The national relay services launced in Europe based on RFC 4103

From: <[email-masked]>
Date: Wed, 17 Nov 2010 18:48:08 +0100

Dear All,

Just a short update regarding if there are relay services with a track record based on RFC 4103 and if so if it is common in Europe.

For me the question is not fully new. My authority has been searching and looking for a relay service that is in service and is based on RFC 4103. There is none to our knowledge. If we have missed any then please provide information about calls per month, etc. Tests with RFC 4103 are going on. Great, we support that! RFC 4103 is the way to secure interoperability. The technical specification (TS) will clearly confirm this. With IMS in place RFC 4103 is the very expected choice for everyone! For now the TS is a used and needed gap filler, securing interoperability with RFC 4103. Also the TS is used by two of three video telephone vendors in Sweden.

Gunnar, Arnoud and Greg reason that RFC 4103 is the best way to send real time text. They base the real time text in the EU-financed project Reach 112 on RFC 4103. We look forward to the results in the project. The project will help Europe to secure real time text interoperability because emergency calls are vital in all societies. Great job!

Somehow others prefer to use the solution defined in the TS. Good, or bad, it is used by relay services in Sweden, Norway, Denmark, Finland and Germany. They handle the dimensioning of the equipment for the services in a way so that no loading problem occurs in real practice. 

Why is this important? It shows that this TS and RFC 4103 is not viewed as fully redundant by all. The two are different solutions and if the TS creates no harm for organizations choosing not to implement the standard then please let the organizations that what to use it continue to do that using this TS. If they can base it on a TS with requirements on interoperability with RFC 4103 it will actually strengthen the use of RFC 4103 which will be the choice in IMS. No harm with the loads have been experienced. It is just a matter of dimensioning and it is up to the service providers to do that. No negative effect with load, as a user. 

The solution is used and it is used even without a formal standard. Let it be standardized and it will strongly support the broad introduction of RFC 4103 and possibly even influence when IMS will be introduced in a positive way.

Best regards

Robert

Robert Hecht
Senior Officer

Swedish Post and Telecom Agency, PTS
Consumer Markets Department
Section for Consumer Issues
Phone: +46 8 678 57 15
Mobile: +46 730 66 57 15
[email-masked] 
www.pts.se

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För [email-masked]
Skickat: den 15 november 2010 21:00
Till: [email-masked]
Ämne: Simple Digest, Vol 79, Issue 12

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/simple

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Simple mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/simple
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simple digest..."

Today's Topics:

   1. The real time text thread: The national relay services
      launced in Europe based on RFC 4103 ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Mon, 15 Nov 2010 17:27:53 +0100
From: <[email-masked]>
Subject: [Simple] The real time text thread: The national relay
	services launced in Europe based on RFC 4103
To: <[email-masked]>
Message-ID: <550A3286D8497C45B743B2121046875D01C98CEC0C@STO-MS01>
Content-Type: text/plain; charset="us-ascii"

Dear All,

I would prefer that the representatives aware of established national relay services in Europe using RFC 4103 could list them for everyone to see in this forum. Please state contact points as well with contact information. I will definitely contact them and report back to this forum if the information would be wrong. Only the relay services up and running with a track record and accessibility requirements are interesting at this point in time. Please if possible also include number of calls per month so we can see the scale of the services.

The reason for this is that I have tried to find these relay services without luck. As a procurer we procure services now. It is important that the solution is transparent and this is a main reason why the TS is being standardized. With the requirements in the TS regarding that interoperability SHALL be secured by RFC 4103 it could influence procurers to demand interoperability with RFC 4103.

In Sweden two of three of the major video telephone vendors base real time text on the TS solution. I do believe that a TS with requirements on interoperability with RFC 4103 will help reaching global interoperability quicker than without the TS. The TS is as I stated earlier already used and for some reason it is the way to set up relay services presently in Sweden, Norway, Denmark, Finland and Germany. For some reason it has become the preferred way of handling real time text in a number of relay services. As long as it is set up with interoperability with RFC 4103 I see no risk with this.

Hadriel comments why anyone would like to see fragmentation. I agree. Also I already see fragmentation. No one wants to repeat the fragmentation of the analogue era. RFC 2793 came in 2000 and the updated RFC 4103 has not caught the relay service market yet, as far as I know. When IMS is implemented it will for sure mean that RFC 4103 will be widely spread, but as Hadriel says IMS is not implemented in the Nordic countries and other places yet. This gap filler will lose its importance when IMS is implemented in wide parts of Europe.

I cannot comment on the more technical points Hadriel made. I would encourage people who knows more to comment on it. Especially the service providers offering services based on the TS. Today I am not aware of any problems with international calls based on the TS solution.

In my e-mail on Friday last week I brought up four areas (A, B, C, D). I would welcome comments on the four areas.

Best regards,

Robert

Robert Hecht
Senior Officer

Swedish Post and Telecom Agency, PTS
Consumer Markets Department
Section for Consumer Issues
Phone: +46 8 678 57 15
Mobile: +46 730 66 57 15
[email-masked]<mailto:[email-masked]>
www.pts.se<http://www.pts.se/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/simple/attachments/20101115/4745f9fe/attachment.htm>

------------------------------

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

End of Simple Digest, Vol 79, Issue 12
**************************************

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 17 Nov 2010 21:38:09 +0100

Hi,

I made a calculation to really check what load effects we are talking
about if we would use SIP Messages for real-time text, transmitted with 300
ms intervals.

Summary: The SIP Message based solution has considerable load effects when
used for text telephony. For a 10 M population, with assumptions described
below, the SIP Message based real-time text solution causes 12000 SIP
protocol messages per second, while with the RFC 4103 transport for text,
the solution will be loaded by 50 SIP protocol messages per second. A quite
normal SIP server capacity is 500 SIP protocol messages per second. This
load will thus require 24 SIP servers when SIP Message is used vs one SIP
server when RFC 4103 is used for this load.
The SIP Message based method should therefore be avoided, or drastically
modified to create much less load.
---------------------------

Detailed discussion.

Note that this reasoning contains a set of assumptions that may be more or
less suitable for modelling real cases. I am no expert in load modelling.

When used for text telephony, SIP Message used as indicated in ETSI DTS 102
575 Annex A causes the following load:

For a population of 10 M persons ( e.g. Sweden or a medium sized US state or
European country ):
about 1% is hard-of-hearing to the degree that phone use is hard and text
telephony or captioned telephony is a useful alternative.
=100 000 users.  ( initially, before mainstream users discover the usability
of real-time text )
Assume that only 50% are attracted to use text telephony from one operator.
= 50 000
A usual figure is that 2% have simultaneous calls at busy hours = 1000
simultaneous calls.
In text telephony, text usage is quite intensive, and even more in captioned
telephony.
SIP Message sent 3 times per second causes 3000 SIP Messages per second in
the 1000 simultaneous calls.
Each SIP Message causes one incoming SIP protocol message, one outgoing
message, one incoming acknowledgement and one outgoing acknowledgement in a
central server. = 12000 SIP protocol messages per second.

SIP servers have of course widely varying capacity. A quite common figure
for medium sized servers seems to be 500 SIP protocol messages per second.

With the calculated size of load, it needs to be divided on 24 servers.

With RFC 4103 only call setup and disconnect is loading the central SIP
server with SIP transactions. It is about 7 SIP protocol messages per side
of the server per call, and calls have approximately 7 minutes mean
duration, or one message per minute, to be compared with 360 per minute per
call per side for the SIP Message solution. That causes about a factor of
360 lower number of SIP protocol messages per second. = 12000/260 = 50 SIP
protocol messages per second, easily handled by nearly any SIP server.

In a disaster situation, users tend to call much more than the above
figures. If the infrastructure is shared between text telephony users and
regular VoIP voice users, it is an apparent risk that text telephony usage
with the SIP Message based solution will cause problems for regular voice
calls.

If text calls are kept separate from voice calls at the server side, there
is still a risk for congestion in various points in the networks from the
SIP Message load, e.g. in the disaster situation and if a group of users is
located at the same place.

If the population using the service is reduced by a factor 10, to handle
only the traditional textphone users without any extended user groups, the
load will be 100 simultaneous calls, 1200 SIP protocol messages per second
with the SIP Message based solution, and 5 SIP protocol messages per second
for the rfc 4103 based method. That is 3 servers vs 1 with the assumed size
of servers.

-----

The draft ETSI TS is about text telephony. That is an operator service
connecting textphone calls. Only a few of the calls will be using a relay
service. Robert's questions ask about relay services. They have a much
lighter load than the communication service.
The same is true about sign relay ("VRS") use of text. Only a few phrases
during a signed call usually requires text transmission. The load concerns
are much lower in the sign relay service case.

For the sake of interoperability, the same protocols should be used for IP
based text telephony, text relay, captioned telephony, total conversation,
sign relay, deaf-blind relay and emergency services.
For text telephony, SIP Message for real-time text causes very high load on
the SIP servers compared to voice calls and calls using RFC 4103 for
real-time text (240 times more). The SIP Message based method should
therefore be avoided. The best way to avoid the load is to use RFC 4103.

Another way to avoid the high load is to reduce the transmission rate of SIP
Message dramatically.
When we discussed the possible use of MSRP for real-time text in the
SIMPLE list a few years ago, that discussion also resulted in a judgement
that it was unfavourable because of the load. An increased transmission
interval from 300 ms to one second was discussed and also regarded to be
not suitable.
It could be discussed again, but it is hard to imagine a pattern of use of
SIP Message that would combine acceptable load and acceptable real-time
characteristics.

Anyway, if such a use pattern is found, it would be for use only between one
server and its registered users for calls within one operator.

For interoperability with other operators and services, RFC 4103 shall be
used as indicated and agreed many times now, both for keeping load low and
functionality high, and for keeping interoperability straightforward.

/Gunnar
========================================================================
2010/11/17 <[email-masked]>

> Dear All,
>
> Just a short update regarding if there are relay services with a track
> record based on RFC 4103 and if so if it is common in Europe.
>
> For me the question is not fully new. My authority has been searching and
> looking for a relay service that is in service and is based on RFC 4103.
> There is none to our knowledge. If we have missed any then please provide
> information about calls per month, etc. Tests with RFC 4103 are going on.
> Great, we support that! RFC 4103 is the way to secure interoperability. The
> technical specification (TS) will clearly confirm this. With IMS in place
> RFC 4103 is the very expected choice for everyone! For now the TS is a used
> and needed gap filler, securing interoperability with RFC 4103. Also the TS
> is used by two of three video telephone vendors in Sweden.
>
> Gunnar, Arnoud and Greg reason that RFC 4103 is the best way to send real
> time text. They base the real time text in the EU-financed project Reach 112
> on RFC 4103. We look forward to the results in the project. The project will
> help Europe to secure real time text interoperability because emergency
> calls are vital in all societies. Great job!
>
> Somehow others prefer to use the solution defined in the TS. Good, or bad,
> it is used by relay services in Sweden, Norway, Denmark, Finland and
> Germany. They handle the dimensioning of the equipment for the services in a
> way so that no loading problem occurs in real practice.
>
> Why is this important? It shows that this TS and RFC 4103 is not viewed as
> fully redundant by all. The two are different solutions and if the TS
> creates no harm for organizations choosing not to implement the standard
> then please let the organizations that what to use it continue to do that
> using this TS. If they can base it on a TS with requirements on
> interoperability with RFC 4103 it will actually strengthen the use of RFC
> 4103 which will be the choice in IMS. No harm with the loads have been
> experienced. It is just a matter of dimensioning and it is up to the service
> providers to do that. No negative effect with load, as a user.
>
> The solution is used and it is used even without a formal standard. Let it
> be standardized and it will strongly support the broad introduction of RFC
> 4103 and possibly even influence when IMS will be introduced in a positive
> way.
>
> Best regards
>
> Robert
>
>
>
> Robert Hecht
> Senior Officer
>
> I would prefer that the representatives aware of established national relay
> services in Europe using RFC 4103 could list them for everyone to see in
> this forum. Please state contact points as well with contact information. I
> will definitely contact them and report back to this forum if the
> information would be wrong. Only the relay services up and running with a
> track record and accessibility requirements are interesting at this point in
> time. Please if possible also include number of calls per month so we can
> see the scale of the services.
>
> The reason for this is that I have tried to find these relay services
> without luck. As a procurer we procure services now. It is important that
> the solution is transparent and this is a main reason why the TS is being
> standardized. With the requirements in the TS regarding that
> interoperability SHALL be secured by RFC 4103 it could influence procurers
> to demand interoperability with RFC 4103.
>
> In Sweden two of three of the major video telephone vendors base real time
> text on the TS solution. I do believe that a TS with requirements on
> interoperability with RFC 4103 will help reaching global interoperability
> quicker than without the TS. The TS is as I stated earlier already used and
> for some reason it is the way to set up relay services presently in Sweden,
> Norway, Denmark, Finland and Germany. For some reason it has become the
> preferred way of handling real time text in a number of relay services. As
> long as it is set up with interoperability with RFC 4103 I see no risk with
> this.
>
> Hadriel comments why anyone would like to see fragmentation. I agree. Also
> I already see fragmentation. No one wants to repeat the fragmentation of the
> analogue era. RFC 2793 came in 2000 and the updated RFC 4103 has not caught
> the relay service market yet, as far as I know. When IMS is implemented it
> will for sure mean that RFC 4103 will be widely spread, but as Hadriel says
> IMS is not implemented in the Nordic countries and other places yet. This
> gap filler will lose its importance when IMS is implemented in wide parts of
> Europe.
>
> I cannot comment on the more technical points Hadriel made. I would
> encourage people who knows more to comment on it. Especially the service
> providers offering services based on the TS. Today I am not aware of any
> problems with international calls based on the TS solution.
>
> In my e-mail on Friday last week I brought up four areas (A, B, C, D). I
> would welcome comments on the four areas.
>
> Best regards,
>
> Robert
>
>
> Robert Hecht
> Senior Officer
>
> URL: <
> http://www.ietf.org/mail-archive/web/simple/attachments/20101115/4745f9fe/attachment.htm
> >
>

---

From: Bruno von Niman <[email-masked]>
Date: Thu, 18 Nov 2010 14:08:26 +0100

Being a user experience (and less of a  even if I speak some - ³technical²)
expert, I¹d state that the below estimates apply to the extreme and
theoretically perfect model and the non-existing human user (rather than the
way human interaction with technology works).
The working assumptions (1000 simultaneous calls at peaks, with a perfectly
continuous text flow, without any interruptions (providing exactly three
characters a second, on the spot, without any connection and text flow
initiation times)...sound to me as rather theoretical, aren¹t they?

Therefore, I¹d be very interested to hear about the practical experiences -
why in reality, based on deployed systems and real-life communication flows,
this does not seem to cause capacity issues in the five-six countries where
the accessibility service is up and running (based on empirical evidence)?

Careful system and server dimensioning can probably solve the issue. Would
there still be serious capacity issues, the loads can always be reduced
considerably (30% to 800%), temporarily or permanently, if applying
assistive text prediction methods (meaning that characters are not sent
before they have formed a word accepted by the end user, as implemented in
most communication devices (and controlled through the user interface of the
device, or as a service feature)).
Regards, 
Bruno

On 17/11/10 21:38, "Gunnar Hellstrom" <[email-masked]> wrote:

> Hi,
>  
> I made a calculation to really check what load effects we are talking about if
> we would use SIP Messages for real-time text, transmitted with 300 ms
> intervals. 
> 
> below, the SIP Message based real-time text solution causes 12000 SIP protocol
> messages per second, while with the RFC 4103 transport for text, the solution
> will be loaded by 50 SIP protocol messages per second. A quite normal SIP
> server capacity is 500 SIP protocol messages per second. This load will thus
> require 24 SIP servers when SIP Message is used vs one SIP server when RFC
> 4103 is used for this load.
> Assume that only 50% are attracted to use text telephony from one operator. =
> 50 000 
> SIP Message sent 3 times per second causes 3000 SIP Messages per second in the
> 1000 simultaneous calls.
> SIP servers have of course widely varying capacity. A quite common figure for
> medium sized servers seems to be 500 SIP protocol messages per second.
> 
> With RFC 4103 only call setup and disconnect is loading the central SIP server
> with SIP transactions. It is about 7 SIP protocol messages per side of the
> server per call, and calls have approximately 7 minutes mean duration, or one
> message per minute, to be compared with 360 per minute per call per side for
> the SIP Message solution. That causes about a factor of 360 lower number of
> SIP protocol messages per second. = 12000/260 = 50 SIP protocol messages per
> second, easily handled by nearly any SIP server.
> 
> In a disaster situation, users tend to call much more than the above figures.
> If the infrastructure is shared between text telephony users and regular VoIP
> voice users, it is an apparent risk that text telephony usage with the SIP
> Message based solution will cause problems for regular voice calls.
> 
> If text calls are kept separate from voice calls at the server side, there is
> still a risk for congestion in various points in the networks from the SIP
> Message load, e.g. in the disaster situation and if a group of users is
> If the population using the service is reduced by a factor 10, to handle only
> the traditional textphone users without any extended user groups, the load
> will be 100 simultaneous calls, 1200 SIP protocol messages per second with the
> SIP Message based solution, and 5 SIP protocol messages per second for the rfc
> 4103 based method. That is 3 servers vs 1 with the assumed size of servers.
> 
> -----
> 
> service. Robert's questions ask about relay services. They have a much lighter
> load than the communication service.
> during a signed call usually requires text transmission. The load concerns are
> much lower in the sign relay service case.
> 
> the SIP servers compared to voice calls and calls using RFC 4103 for real-time
> text (240 times more). The SIP Message based method should therefore be
> avoided. The best way to avoid the load is to use RFC 4103.
> 
> SIMPLE list a few years ago, that discussion also resulted in a judgement that
> it was unfavourable because of the load. An increased transmission interval
> from 300 ms to one second was discussed and also regarded to be not suitable. 
> It could be discussed again, but it is hard to imagine a pattern of use of SIP
> Message that would combine acceptable load and acceptable real-time
> characteristics.
>   
> For interoperability with other operators and services, RFC 4103 shall be used
> as indicated and agreed many times now, both for keeping load low and
>> Just a short update regarding if there are relay services with a track record
>> based on RFC 4103 and if so if it is common in Europe.
>> 
>> technical specification (TS) will clearly confirm this. With IMS in place RFC
>> 4103 is the very expected choice for everyone! For now the TS is a used and
>> needed gap filler, securing interoperability with RFC 4103. Also the TS is
>> used by two of three video telephone vendors in Sweden.
>> 
>> help Europe to secure real time text interoperability because emergency calls
>> are vital in all societies. Great job!
>> 
>> Somehow others prefer to use the solution defined in the TS. Good, or bad, it
>> is used by relay services in Sweden, Norway, Denmark, Finland and Germany.
>> They handle the dimensioning of the equipment for the services in a way so
>> that no loading problem occurs in real practice.
>> 
>> fully redundant by all. The two are different solutions and if the TS creates
>> no harm for organizations choosing not to implement the standard then please
>> let the organizations that what to use it continue to do that using this TS.
>> If they can base it on a TS with requirements on interoperability with RFC
>> 4103 it will actually strengthen the use of RFC 4103 which will be the choice
>> in IMS. No harm with the loads have been experienced. It is just a matter of
>> dimensioning and it is up to the service providers to do that. No negative
>> effect with load, as a user.
>> 
>> The solution is used and it is used even without a formal standard. Let it be
>> standardized and it will strongly support the broad introduction of RFC 4103
>> and possibly even influence when IMS will be introduced in a positive way.
>> 
>> Best regards
>> 
>> Robert
>> 
>> 
>> 
>> Robert Hecht
>> Senior Officer
>> 
>> www.pts.se <http://www.pts.se/>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> services in Europe using RFC 4103 could list them for everyone to see in this
>> forum. Please state contact points as well with contact information. I will
>> definitely contact them and report back to this forum if the information
>> would be wrong. Only the relay services up and running with a track record
>> and accessibility requirements are interesting at this point in time. Please
>> if possible also include number of calls per month so we can see the scale of
>> the services.
>> 
>> The reason for this is that I have tried to find these relay services without
>> luck. As a procurer we procure services now. It is important that the
>> solution is transparent and this is a main reason why the TS is being
>> standardized. With the requirements in the TS regarding that interoperability
>> SHALL be secured by RFC 4103 it could influence procurers to demand
>> interoperability with RFC 4103.
>> 
>> Hadriel comments why anyone would like to see fragmentation. I agree. Also I
>> already see fragmentation. No one wants to repeat the fragmentation of the
>> IMS is not implemented in the Nordic countries and other places yet. This gap
>> filler will lose its importance when IMS is implemented in wide parts of
>> Europe.
>> 
>> I cannot comment on the more technical points Hadriel made. I would encourage
>> people who knows more to comment on it. Especially the service providers
>> offering services based on the TS. Today I am not aware of any problems with
>> international calls based on the TS solution.
>> 
>> www.pts.se <http://www.pts.se/> <http://www.pts.se/>
>> 
>> URL: 
>> <http://www.ietf.org/mail-archive/web/simple/attachments/20101115/4745f9fe/at
>> tachment.htm>
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Nov 2010 13:19:02 -0500

On Nov 18, 2010, at 8:08 AM, Bruno von Niman wrote:

Therefore, I’d be very interested to hear about the practical experiences - why in reality, based on deployed systems and real-life communication flows, this does not seem to cause capacity issues in the five-six countries where the accessibility service is up and running (based on empirical evidence)?

1) Because other than Germany, the other countries aren't that populous frankly.
2) Because of Metcalf's law, such that the larger the population of users gets with the ability to se this, the more useful (and used) it becomes.
3) Because you're assuming this gets restricted to hearing-impaired users only.  That may indeed be what ends up happening, but we can't assume that forever (and it would be a shame if it were to be the case).
4) Because I'm guessing that within the population of these 5-6 countries you don't actually have every single hearing-impaired human using this technology already?

Careful system and server dimensioning can probably solve the issue. Would there still be serious capacity issues, the loads can always be reduced considerably (30% to 800%), temporarily or permanently, if applying assistive text prediction methods (meaning that characters are not sent before they have formed a word accepted by the end user, as implemented in most communication devices (and controlled through the user interface of the device, or as a service feature)).

You think you can get the client's code to do predictive texting in order to reduce the infrastructure costs of the provider??  That's a strange form of market force.  Maybe if it cost the user per message sent, then there would be a market force to give incentive to client software to do predictive text - otherwise there's no market driver for the client software to do it beyond the advantage of having predictive text for its own sake (which is to help reduce typing for the human).

Regardless, even if you're sending whole words instead of characters, it' still not a scalable solution.  And no, "careful system and server dimensioning" cannot *solve* the issue.  What you're basically saying is the service providers can buy bigger systems to handle bigger load.  Obviously that's true.  The question is why they have to.  Naturally the system vendors wouldn't mind selling bigger systems to handle bigger load, so I can understand their motivation.  What I don't understand is ETSI's motivation to rubber-stamp a proprietary vendor solution which will cost its service provider operators more money in the long run.
(and I don't mean that as an attack/blame thing - I'm really just baffled why ETSI would go this way - is ETSI controlled/influenced by system vendors more than operators?)

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Nov 2010 12:53:39 -0600

On Nov 18, 2010, at 12:19 PM, Hadriel Kaplan wrote:

> I'm really just baffled why ETSI would go this way...

My understanding is that the MESSAGE approach is in an annex to the ETSI TS under question.  Bruno--does the annex describe the primary solution, or an alternate one?