Subject: [Simple] Fwd: Liaison statement from ETSI Human Factors

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 03 Sep 2010 10:40:47 +0300

Folks,

we have received an LS from ETSI HF that relates to the use of MESSAGE
requests in their systems (see email below). We would like to get your
input on this.

Cheers,

Gonzalo

-------- Original Message --------
Subject: Liaison statement from ETSI Human Factors
Date: Fri, 03 Sep 2010 10:39:25 +0300
From: Gonzalo Camarillo <[email-masked]>
To: DISPATCH <[email-masked]>
CC: Robert Sparks <[email-masked]>

Folks,

FYI: we have received the following LS from ETSI HF:

https://datatracker.ietf.org/documents/LIAISON/file1085.doc

As you can see, it relates to the registration of two SIP header fields
and the use of MESSAGE requests. Per RFC 5727, the registration of the
header fields will require an expert review. The use of the MESSAGE
request will be discussed in the SIMPLE WG mailing list. We will return
a response to this LS once we have gotten input from the SIMPLE community.

Cheers,

Gonzalo

---

From: Adam Roach <[email-masked]>
Date: Fri, 03 Sep 2010 10:43:19 -0500

As input to whoever performs expert review on this document: I want to 
point out that the networks they're talking about are processing between 
0.0019 and 0.0063 calls per second. I don't think it's safe to 
extrapolate how well the approach will scale to larger networks from 
these kinds of traffic volumes.

In particular, the liaison statement claims that the normative 
statements in RFC 3428 can be safely ignored based on these trials: 
"Empirical evidence from all market deployments studied does not 
indicate any issues with overloaded SIP servers."

I don't think one can reasonably discard the recommendations of RFC 3428 
based on networks that process only 550 calls per day.

/a

On 9/3/10 2:40 AM, Gonzalo Camarillo wrote:
> From: Gonzalo Camarillo<[email-masked]>
> To: DISPATCH<[email-masked]>
> CC: Robert Sparks<[email-masked]>
>
> Folks,
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Sep 2010 12:06:33 -0500

On Sep 3, 2010, at 10:43 AM, Adam Roach <[email-masked]> wrote:

> As input to whoever performs expert review on this document: I want to point out that the networks they're talking about are processing between 0.0019 and 0.0063 calls per second. I don't think it's safe to extrapolate how well the approach will scale to larger networks from these kinds of traffic volumes.
> 
> In particular, the liaison statement claims that the normative statements in RFC 3428 can be safely ignored based on these trials: "Empirical evidence from all market deployments studied does not indicate any issues with overloaded SIP servers."
> 
> I don't think one can reasonably discard the recommendations of RFC 3428 based on networks that process only 550 calls per day.

Yes, and the calls they do have will involve up to 3 mid-dialog SIP requests a second. I assume this is in each direction, so for a worst case you could double it. Of course, in a real world scenario, it's unlikely both parties will continuously type at full speed.

Does anyone have insight on why they didn't look at Text over IP for this purpose? We've had a number of presentations on doing real-time text over MSRP, and we've recommended against it due to the high overhead of sending lots of extremely short messages, and due to the non-deterministic timing of delivery. We recommended ToIP instead. I think doing it over SIP MESSAGE is even worse than using MSRP.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 3 Sep 2010 14:44:29 -0400

> Does anyone have insight on why they didn't look at Text over IP for this purpose? We've had a number of presentations on doing real-time text over MSRP, and we've recommended against it due to the…
Right at the moment, I agree with this.  It seems like an inappropriate use of MESSAGE.  I'll ask the usual suspects on real time text, and see what they say (if they aren't already monitoring this list).

Brian

---

From: Adam Roach <[email-masked]>
Date: Fri, 03 Sep 2010 16:05:55 -0500

> Right at the moment, I agree with this.  It seems like an inappropriate use of MESSAGE.  I'll ask the usual suspects on real time text, and see what they say (if they aren't already monitoring this…

The two experts I'm aware of are Arnoud and Guido. I would think RFC 
5194 should be a rather concise summary of their thoughts on how to do 
this kind of thing -- with the short answer being "send T.140 text over 
RTP as described in RFC 4103".

But, yes, it would be nice to have them weigh in specifically on the 
technique cited by the liaison statement.

/a

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 3 Sep 2010 23:08:39 +0200

Hi,
I guess I am among the "usual suspects on real time text", so I feel
challenged to answer.
I have also commented on this work while it has been going on in ETSI and
recommended to turn to IETF for these issues.

The RTP based real-time text transport RFC 4103 already exists and is mature
and commonly referenced. 

The discussions behind it ending up as an RTP based transport dates back to
around 1999. There was then discussion in ITU about how to add real-time
text to H.323. Some voices were for using some call-control-info-type of
mechanism, while others claimed that it would be structurally wrong to pull
media through the call control channel.
So it was decided to take the media path and go to IETF to create the
transport.

Some manufacturers were very strict about the control / media separation.
Having media mixed in the call control path would cause major architectural
problems in large systems. 

The transport was created to use RTP, and thereby be usable in both H.323
and SIP. ( first as RFC 2793 and then refined into RFC 4103 )

By use of RTP it is scalable and can be used without problems in network to
network interfaces, large switches and gateways. Nothing special, just a
little extension on the multimedia concept. I think the concept of contrl /
media separation is still very valid.

-

That was history and the basic motivations behind ToIP based on RTP.

It is true that I have also been behind discussions about use of MSRP for
real-time text, in an effort to go with protocols that seemed to become
widely implemented. But the warnings around load made me withdraw the
proposals. I think that the comments were right.

Now we have this proposal to use SIP Message. I cannot comment on why it is
proposed. It is there in the ETSI draft. Also RTP based RFC 4103 is included
and promoted as preferred for the same purpose in the same draft. I see no
clear indication of why a second method is proposed.

Some indications in the liaison statement point at historical reasons. There
are systems that are said to use a private variant of this SIP Message based
method. And there is a wish to document that in an SDO to make it open. 

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, September 03, 2010 8:44 PM
To: Ben Campbell
Cc: Adam Roach; [email-masked]
Subject: Re: [Simple] Fwd: Liaison statement from ETSI Human Factors

> Does anyone have insight on why they didn't look at Text over IP for this
purpose? We've had a number of presentations on doing real-time text over
MSRP, and we've recommended against it due to the high overhead of sending
lots of extremely short messages, and due to the non-deterministic timing of
delivery. We recommended ToIP instead. I think doing it over SIP MESSAGE is
even worse than using MSRP. 
Right at the moment, I agree with this.  It seems like an inappropriate use
of MESSAGE.  I'll ask the usual suspects on real time text, and see what
they say (if they aren't already monitoring this list).

Brian

__________ NOD32 5421 (20100903) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Sep 2010 19:06:01 -0400

> method. And there is a wish to document that in an SDO to make it open. 

That's not a very good reason, as you know.  There is a private variant which uses INFO for the same type of thing, so will they document that as well??  
All they'd be doing by having a second option of using MESSAGE is guaranteeing different people won't be able to converse in text, if they didn't implement the same option.

Besides, some carriers charge extra for MESSAGE requests, on a per message basis, because it's essentially SMS from their perspective.  Would you really like to learn later that your text call cost an arm and a leg, because it happened to use MESSAGE instead of RTP-text for that particular call?  That'll be fun to explain.

-hadriel
p.s., I realize you're not advocating it - just giving some feedback to whomever responds to ETSI.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Sep 2010 19:31:12 -0400

I haven't read their draft (since it's not publicly available and I lost my etsi-docbox password), but I assume they're operating under the assumption that this will only be used for hearing-impaired uses? And thus why there are so few calls per day?

If so, I would ask them how they intend to restrict and control such usage to only hearing-impaired uses; and if they're not going to, because they want it to be usable by all, then I'd ask them to look at what happened to SMS.  At first, it scaled ok, because there wasn't a ton of it.  Then it grew, and grew, and grew - not coincidentally with Metcalf's law, as more users got mobile phones and SMS crossed carriers.  Even ridiculously high pricing structures didn't keep it down, but at least it paid for capacity (and then some).  

Do they expect a similar pricing structure for real-time-text?  Because if not, and if it becomes successful and abused by many, certain boxes-which-shall-not-be-named will simply be configured to severely throttle or block the MESSAGE requests (which doesn't even require upgrading such boxes, because most vendors of such boxes can already do it today)... at which point users who really need RTT, namely hearing-imparied, will not be able to use it.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Sep 2010 19:45:20 -0400

1) One of the arguments for this is that it run without special gear.
2) I imagine that in a fair number of these calls, one of the users
    is not hearing impaired. This "seeds the market" with non-hearing
    impaired users ready to use this.
3) I'll bet a bunch of those kids out there that message continuously
    would leap at the chance to have it work in realtime.

To me that doesn't bode well for keeping it a low volume service.

On the bright side, this would be a new business opportunity for SBCs - 
to filter all this stuff out before it causes trouble.

	Thanks,
	Paul

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sat, 04 Sep 2010 14:23:47 -0500

A couple notes

Someone mentioned that SIP MESSAGE had the advantage of working with todays devices.  Actually that isn't true. If you send RTT using MESSAGE without re-engineering the client - you will get a few characters on each line - making it very hard to read.

Doing some quick calculations to explore this we came up with 
Bandwidth to send SENTENCES with SIP MESSAGE - 2 kbps
Bandwidth to send REAL-TIME TEXT with SIP MESSAGE - 33 kbps  - through call control server

Bandwidth to send REAL-TIME TEXT with RFC 4103  4 kbps - point to point

I agree with Hadriel's comments below.  This will cause a huge increase in costs at the server -especially when teens start using it.   
AND - because it is an accommodation for people who are deaf, providers would not be able to charge for it in some countries.
And of course there is no practical way to restrict usage to just people with disabilities -- nor do we want to. The more people that adopt real-time text in their daily communication, the more reliable it will be, and the better the functional equivalence will be since everyone will be used to communicating in text. 
It is essential to use a real-time text format that scales well to massive usage. SIP Message seems not to meet that requirement. 

I also agree with comment from another - that describing two ways of doing real-time text in the standard means there is no standard.  And if some manufacturers use one method and some use the other -- there is no interoperability.    

I don't think the REAL-TIME TEXT VARIANT of SIP MESSAGE is supported in the new emergency center  (e911) work  (though the SIP MESSAGE in its standard form to send messages is). 

I'm not religious about any of the formats being the chosen standard format. 
	But we need to settle on ONE that we all support or we won't have interoperability (unless of course we want to require everyone to support all of the methods for real-time text).     
	Since we need to choose one - RFC 4103 seem by far the superior.  And trying to use SIP MESSAGE for real-time text would require changes in SIP MESSAGE (so that sequential deliveries are concatenated on the same line) and would cause bandwidth and call control congestion - especially when youth get ahold of it. 

So it seems to make little sense (and could cause a lot of cost and problem) to have SIP MESSAGE, or some offshoot of it, included as a method for real-time text in the SIP MESSAGE standard doc.

Gregg
-----------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

---

From: Gregg Vanderheiden <[email-masked]>
Date: Fri, 03 Sep 2010 15:09:04 -0500

Agree
	We did a quick calculation of what happens with MESSAGE when used for real-time text just to get a ballpark idea. 

Here is what happens when you use SIP Message to send real-time text. 

And the traffic with MESSAGE is on the call control channel and goes through the server rather than point to point. 

Gregg
-----------------------
Gregg Vanderheiden Ph.D.

---

From: Dean Willis <[email-masked]>
Date: Sat, 11 Sep 2010 00:14:03 -0500

> requests in their systems (see email below). We would like to get your

I suppose real-time MSRP has been thrown out with the baby's bath?

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Sat, 11 Sep 2010 00:37:41 -0500

> I suppose real-time MSRP has been thrown out with the baby's bath?

We had a pretty clear consensus against it in Dublin. It's pretty much the most sub-optimal use case possible for MSRP. Almost as inefficient as doing it in MESSAGE. RFC 4103 really seems like the best approach for this sort of thing.